বিভিন্ন সাইট যুক্ত করা: VPN, Tailscale, NetBird না Cloudflare Mesh?

আমি প্রতিষ্ঠানের নেটওয়ার্ক সংযুক্ত করার কাজ অনেক করি। একই প্রশ্ন বারবার আসে: আমাদের সাইটগুলো যুক্ত করার সেরা সমাধান কী? পাবলিক IP ঠিকানা লাগবে? কতটা নিরাপদ? নতুন শাখা, অন্য ইন্টারনেট সংযোগ বা বাড়তি কর্মী এলে সমাধানটি তখনো উপযুক্ত থাকবে?

আমার উত্তর প্রতিষ্ঠানের বাস্তব চাহিদার ওপর নির্ভর করে। আগে থেকেই ফায়ারওয়াল থাকা দুটি স্থায়ী সাইটের অবস্থা, পরিবর্তনশীল সংযোগের কয়েকটি ছোট শাখার মতো নয়। টানেলের বাইরেও ভাবতে হয়, কে পরিচালনা করবে, কোথায় প্রবেশাধিকার নিয়ন্ত্রণ হবে এবং প্রতিষ্ঠান কোন নির্ভরতা বজায় রাখতে প্রস্তুত।

তাই পণ্য বাছার আগে আমি স্থাপত্য বুঝতে চাই। প্রচলিত site-to-site VPN উপযুক্ত হতে পারে। Tailscale বা NetBird ব্যবস্থাপনা ও সংযোগ স্থাপন সহজ করতে পারে। Cloudflare Mesh ডেটার পথ সেবাদাতার নেটওয়ার্কে নিয়ে যায়। এই পার্থক্যগুলো থেকেই আমার কাছে প্রতিটির উপযুক্ত ব্যবহার নির্ধারিত হয়।

এখানে মূল বিষয় সম্পূর্ণ সাইট নেটওয়ার্ক সংযুক্ত করা। বাড়ি থেকে কর্মীর একক ডিভাইসের সংযোগ পরে অতিরিক্ত রিমোট অ্যাক্সেস হিসেবে আলাদা আলোচনা করব।

আমাদের উদাহরণ: সংযুক্ত তিনটি সাইট নেটওয়ার্ক

প্রধান কার্যালয় 10.1.0.0/24, শাখা 10.2.0.0/24 এবং হোম ল্যাব 10.3.0.0/24 ব্যবহার করে। প্রতিটি সাইটে গেটওয়ে দূরের নেটওয়ার্কে পৌঁছানোর পথ দেয়। তার পেছনের প্রিন্টার ও NAS-এর নিজস্ব VPN ক্লায়েন্ট লাগে না। সব ব্যবস্থার উদ্দেশ্য এক: এই তিনটি নেটওয়ার্কের মধ্যে নিয়ন্ত্রিত যোগাযোগ।

এতে লেয়ার ৩-এ রাউট করা নেটওয়ার্ক তৈরি হয়। সাইটগুলো স্বয়ংক্রিয়ভাবে একই ব্রডকাস্ট ডোমেইনে আসে না, সব স্থানীয় অনুসন্ধান প্রোটোকলও সাইট পেরিয়ে কাজ শুরু করে না। DNS-কে অভ্যন্তরীণ নাম ঠিকমতো সমাধান করতে হবে এবং স্থানীয় রাউটারে দূরের নেটওয়ার্কের রুট থাকতে হবে।

কোন নেটওয়ার্কের কোন পরিষেবা দরকার, প্রথমে সেটি জানতে চাই। শাখার ফাইল সার্ভার দরকার হতে পারে, ল্যাবের প্রশাসনিক প্রবেশাধিকার নয়। ব্যাকআপ সার্ভারের দরকার গন্তব্য, অন্য সাইটের প্রতিটি যন্ত্র নয়। যেকোনো সমাধানেই এই সিদ্ধান্তগুলো জরুরি।

Site-to-site সংযোগ বোঝায়, টপোলজি নয়

Site-to-site মানে নেটওয়ার্ক থেকে নেটওয়ার্ক। এর অর্থ সব ট্র্যাফিক কেন্দ্রীয় ফায়ারওয়াল দিয়ে যেতেই হবে, এমন নয়। প্রধান কার্যালয়কে কেন্দ্র করা hub-and-spoke প্রচলিত; দুটি সাইটের সরাসরি টানেলও site-to-site। Tailscale, NetBird বা Cloudflare Mesh-এর গেটওয়েও একই কাজ করতে পারে।

নিবন্ধন ও সমন্বয় কেন্দ্রীয় হলেও Tailscale ও NetBird যথাসম্ভব সরাসরি ডেটাপথ চায়। Cloudflare-এর নেটওয়ার্ক ভৌগোলিকভাবে ছড়ানো, কিন্তু সাইটের ট্র্যাফিক Cloudflare দিয়েই যায়। এটি সাইটগুলোর সরাসরি peer-to-peer সংযোগ নয়। নিজস্ব কেন্দ্রীয় ফায়ারওয়ালের বদলে সেবাদাতার নেটওয়ার্ক ট্রানজিট পয়েন্ট হয়।

পাবলিক IP এবং বদলানো চাহিদা

পাবলিক IP-এর প্রশ্ন দ্রুত ওঠে। আমি বাইরে থেকে পৌঁছানো যায় কি না এবং ঠিকানা স্থায়ী থাকে কি না, এই দুটি বিষয় আলাদা করি। স্থায়ী পাবলিক ঠিকানা সহজে পৌঁছানো যায় এমন VPN endpoint পরিকল্পনা সহজ করে। তবে প্রতিটি সাইটে এটি দরকার নেই। শাখা থেকে পৌঁছানো যায় এমন কেন্দ্রীয় গেটওয়ের দিকে আউটবাউন্ড টানেল তৈরি করা যায়। নকশা অনুযায়ী dynamic DNS বদলানো ঠিকানাতেও সাহায্য করতে পারে।

উভয় প্রান্ত কঠোর carrier-grade NAT-এর পেছনে এবং সরাসরি পৌঁছানো যায় এমন endpoint না থাকলে কঠিন হয়। বিশেষ করে মোবাইল ইন্টারনেটে অপারেটর আসলে কী ঠিকানা ও ইনবাউন্ড সংযোগ দেয়, তা যাচাই করা দরকার। Tailscale ও NetBird NAT পেরিয়ে সরাসরি সংযোগ চেষ্টা করে, প্রয়োজনে relay ব্যবহার করে। Cloudflare Mesh সেবাদাতার নেটওয়ার্কে আউটবাউন্ড সংযোগ করে।

পরের পরিবর্তনটিও যেন সামলানো যায়, সেটি চাই। নতুন সাইট, অপারেটর বদল বা ইনবাউন্ড পৌঁছানোর সুবিধাহীন সংযোগ ছোট কনফিগারেশনকে অন্য কাজে পরিণত করতে পারে। আগেভাগে সচল ব্যবস্থা বদলানো জরুরি নয়, কিন্তু টপোলজি স্থির করার আগে সম্ভাবনাগুলো বিবেচনা করা উচিত।

প্রচলিত site-to-site VPN: গেটওয়ে দায়িত্ব নেয়

দুটি ফায়ারওয়াল বা রাউটার এনক্রিপ্ট করা টানেল তৈরি করে, সাধারণত IPsec বা হাতে কনফিগার করা WireGuard দিয়ে। স্থানীয় রাউটিং দূরের নেটওয়ার্কের ট্র্যাফিক টানেলে পাঠায়। অন্য গেটওয়ে ডিক্রিপ্ট করে গন্তব্য নেটওয়ার্কে এগিয়ে দেয়।

তিনটি সাইটে প্রধান কার্যালয় hub হতে পারে। শাখা ও ল্যাব সেখানে যুক্ত হয়। কাঠামো সহজ হয়, তবে তাদের পারস্পরিক ডেটা প্রধান কার্যালয় দিয়ে যায়। Full mesh প্রতিটি জোড়াকে সরাসরি যুক্ত করে। n সাইটে n × (n − 1) / 2 সংযোগ লাগে: তিন সাইটে তিনটি, দশটিতে 45টি। Controller ও গতিশীল পদ্ধতি কাজ কমায়; প্রচলিত VPN কেবল হাতে তৈরি hub নেটওয়ার্কেই সীমাবদ্ধ নয়।

সুবিধা: বিদ্যমান ফায়ারওয়াল ও স্পষ্ট সাইটসীমার সঙ্গে মানায়। টানেলের প্রান্ত নিজের নিয়ন্ত্রণে। ডেটাপথে বাড়তি mesh সেবাদাতা নেই; নিয়ম, রুটিং ও লগ আগের প্রশাসনে রাখা যায়।

অসুবিধা: সাইট বাড়লে রুটিং, চাবি ও পরিচালনার কাজ বাড়ে। NAT, পরিবর্তনশীল ঠিকানা ও ভিন্ন নির্মাতা সমস্যা নির্ণয় জটিল করে। চলমান ব্যবহারকারীদের জন্য প্রায়ই আলাদা রিমোট অ্যাক্সেস লাগে।

প্রতিটি সাইটে স্থায়ী পাবলিক IP সর্বজনীন শর্ত নয়। বহু ব্যবস্থায় পৌঁছানো যায় এমন hub এবং শাখা থেকে আউটবাউন্ড টানেলই যথেষ্ট। Dynamic DNS ও NAT traversal সাহায্য করে। তবে দুই প্রান্তে কঠোর CGNAT থাকলে পৌঁছানো যায় এমন endpoint বা মধ্যস্থতা ছাড়া সরাসরি যোগাযোগ কঠিন।

উপযুক্ত ফায়ারওয়ালসহ দুটি স্থিতিশীল সাইটে এটি এখনো যুক্তিযুক্ত। অন্য পণ্যে কম সেটিং দেখায় বলেই সচল VPN বদলানোর প্রয়োজন নেই।

Tailscale: সরাসরি সংযোগ, কেন্দ্রীয় সমন্বয়

Tailscale, WireGuard-এর সঙ্গে ডিভাইস নিবন্ধন, সমন্বয় ও অ্যাক্সেস নীতি যোগ করে। নিয়ন্ত্রণ পরিষেবা অংশগ্রহণকারীদের পরস্পর খুঁজে পেতে সাহায্য করে। সম্ভব হলে ডেটা সরাসরি peer-এর মধ্যে যায়। NAT বা ফায়ারওয়াল বাধা দিলে relay বিকল্প পথ দেয়। DERP দিয়েও Tailscale peer-এর মধ্যে ট্র্যাফিক এনক্রিপ্ট করা থাকে।

Subnet router পুরো LAN-কে tailnet-এ আনে। Tailscale-এর নথিভুক্ত site-to-site উদাহরণে উভয় প্রান্তে Linux থাকে। পেছনের যন্ত্রে agent লাগে না, তবে সঠিক রুট প্রয়োজন। মূল উৎস ঠিকানা রাখতে source NAT বন্ধ করলে ফেরার পথ বিশেষভাবে পরিকল্পনা করতে হয়।

সুবিধা: বিদ্যমান LAN যন্ত্র subnet router দিয়ে যুক্ত হয়। গেটওয়ের সরাসরি সংযোগ কেন্দ্রীয় সাইট ঘুরে যাওয়ার বাধ্যবাধকতা এড়ায়। একই প্ল্যাটফর্মে একক ব্যবহারকারীর যন্ত্রও যোগ করা যায়।

অসুবিধা: সরাসরি পথ নিশ্চিত নয়। Relay ব্যবহারে latency ও throughput আলাদা হতে পারে। হোস্ট করা সমন্বয় পরিষেবার ওপর পরিচালনাগত নির্ভরতা থাকে; প্ল্যান ও ফিচার স্থাপনার উপযোগী হতে হবে।

WireGuard এনক্রিপশন peer-এ শেষ হয়। সেটি subnet router হলে পরের LAN অংশ টানেলের বাইরে। তাই ব্যক্তিগত নেটওয়ার্কেও HTTPS ও SSH উপকারী।

NetBird: একই ধরনের mesh, নিজে হোস্ট করার সুযোগ

NetBird-ও WireGuard ব্যবহার করে, সরাসরি সংযোগ চেষ্টা করে এবং প্রয়োজনে relay নেয়। Routing peer সেই নেটওয়ার্কগুলো যুক্ত করে যাদের যন্ত্র ক্লায়েন্ট চালায় না। বর্তমান site-to-site নির্দেশনায় Networks, Resources এবং সংশ্লিষ্ট অ্যাক্সেস নীতি আছে।

সুবিধা: ওপেন-সোর্স প্রকল্পটি cloud পরিষেবার বিকল্প হিসেবে নিজে হোস্ট করার সুযোগ দেয়। অবকাঠামো ও ব্যবস্থাপনা নিজের দায়িত্বে রাখতে হলে এটি গুরুত্বপূর্ণ। গ্রুপ ও নীতি দিয়ে অ্যাক্সেস সীমিত করা যায়।

অসুবিধা: নিজস্ব হোস্টিংয়ে আপডেট, ব্যাকআপ, পর্যবেক্ষণ এবং সমন্বয় ও relay-এর প্রাপ্যতা নিজের দায়িত্ব। দ্রুত ইনস্টলেশন এই কাজ সরায় না। নথিভুক্ত Networks site-to-site নকশায় masquerading চালু থাকে, ফলে গন্তব্য সরাসরি আসল উৎস ঠিকানা দেখে না। অন্য routing পদ্ধতি আলাদাভাবে পরিকল্পনা করতে হয়।

Tailscale ও NetBird কাছাকাছি হলেও কনফিগারেশন অদলবদল করা যায় না। প্রয়োজনীয় রাউটিং ও পরিচয় মডেল অনুযায়ী দুটো দেখব। ওপেন সোর্স মানেই প্রতিটি ফিচারের সীমাহীন ব্যবহার নয়; পরিকল্পিত স্থাপনার লাইসেন্স ও ফিচার যাচাই করতে হবে।

Cloudflare Mesh: সেবাদাতার নেটওয়ার্কই পথ

অংশগ্রহণকারীরা Cloudflare-এ আউটবাউন্ড সংযোগ করে। সাইটের ট্র্যাফিক তার নেটওয়ার্ক দিয়ে যায়। প্রতিটি সাইটকে অন্য সব সাইটের সঙ্গে সরাসরি যুক্ত করা বা নিজস্ব কেন্দ্রীয় VPN hub চালানো লাগে না। তবে বিশ্বাসের সীমা ও ডেটাপথ সরাসরি WireGuard mesh থেকে আলাদা।

সুবিধা: সংযোগ ও কেন্দ্রীয় Gateway নীতি একত্র হয়। আগে থেকে Cloudflare One থাকলে বিশেষভাবে উপযুক্ত হতে পারে। NAT-এর পেছনের সাইট ও মোবাইল ক্লায়েন্ট আউটবাউন্ড সংযোগে যুক্ত হয়।

অসুবিধা: পরিচালনা ও পথ সেবাদাতার ওপর নির্ভর করে। সংবেদনশীল ডেটার প্রক্রিয়াকরণ বিশ্বাস ও গোপনীয়তার চাহিদা পূরণ করতে হবে। অ্যাপের TLS বা SSH উপকারী থাকে। নির্দিষ্ট অ্যাপে পথের সুবিধা আছে কি না মেপে দেখতে হয়; বিশ্বব্যাপী backbone সব জায়গায় বেশি গতি প্রমাণ করে না।

নতুন স্থাপনায় আমি বর্তমান নথির ক্লায়েন্ট পদ্ধতি অনুসরণ করব। Cloudflare Mesh-কে beta বলে এবং নোডের device profile-এ MASQUE চায়। WireGuard-এ high availability, IPv6 ও hostname route-এর সীমা নথিভুক্ত আছে। তাই শুধু রাউটারে WireGuard সমর্থন থাকলেই সেটি সমতুল্য Mesh node নয়।

নির্দিষ্ট অ্যাপের cloudflared টানেল থেকেও Mesh-কে আলাদা বুঝতে হবে। এখানে অংশগ্রহণকারী ও রাউট করা নেটওয়ার্কের মধ্যে দ্বিমুখী ব্যক্তিগত IP সংযোগ নিয়ে আলোচনা।

পার্থক্য এক নজরে

বাছার সময় প্রথমে এই পার্থক্য দেখি। প্রয়োজনীয় subscription ও প্রকৃত পথ নির্দিষ্ট পরিবেশে যাচাই করতে হয়।

নিরাপদ সাইট সংযোগে আমার প্রত্যাশা

কোনটি সবচেয়ে নিরাপদ জানতে চাইলে প্রথমে অনুমোদিত সংযোগ ও অ্যাক্সেস ব্যবস্থাপনা দেখি। এনক্রিপ্ট করা টানেলও অতিরিক্ত অনুমতি দিতে পারে। কোন নেটওয়ার্ক কোন পরিষেবা পাবে, প্রশাসক কীভাবে সুরক্ষিত হবেন এবং অ্যাক্সেস কীভাবে প্রত্যাহার হবে, তা নির্ধারণ করতে চাই। প্রশাসন ও ব্যক্তিগতভাবে নিবন্ধিত ব্যবহারকারীর MFA, সীমিত অনুমতি এবং রক্ষণাবেক্ষণ করা গেটওয়ে এই মূল্যায়নে পড়ে।

এনক্রিপশনের সীমাও আলাদা। প্রচলিত VPN গেটওয়েতে শেষ হয়। Tailscale ও NetBird peer-এর মধ্যে WireGuard চালায়, যা subnet router-ও হতে পারে। পরের LAN নিজে থেকে এনক্রিপ্ট হয় না। Cloudflare-এ সেবাদাতার নেটওয়ার্কে প্রক্রিয়াকরণও প্রতিষ্ঠানের চাহিদা মেটাতে হবে। অ্যাপের জন্য HTTPS বা SSH উপকারী থাকে।

আউটবাউন্ড সংযোগ ইনস্টল সহজ করে এবং শাখায় পাবলিক VPN পরিষেবা খোলা এড়াতে পারে। এটি অ্যাক্সেস নীতির বিকল্প নয়। পাবলিক IP-ও নিজে থেকে ফায়ারওয়ালকে অনিরাপদ করে না। ঝুঁকি নির্ভর করে প্রকৃত উন্মুক্ত পরিষেবা, সুরক্ষা ও চলমান পরিচালনায়। পণ্যের নাম থেকে নিরাপত্তার ক্রম করি না।

গ্রহণের আগে যা যাচাই করতে চাই

যাওয়া ও ফেরার পথ দুটোই কাজ করতে হবে। 10.2.0.0/24 রুট দায়িত্বপ্রাপ্ত রাউটার বা ক্লায়েন্টে থাকতে হবে। গন্তব্য অন্য default gateway দিয়ে উত্তর দিলে ফেরার উপযুক্ত রুট চাই। SNAT উত্তর সহজ করে, কিন্তু দৃশ্যমান ঠিকানা বদলায় এবং লগ ও নিয়মে প্রভাব ফেলে। এটি সচেতন নকশাগত সিদ্ধান্ত হওয়া উচিত।

High availability-এর জন্য দুটি overlay node যথেষ্ট নয়। ব্যর্থতার পরও LAN যন্ত্র যেন পরের গেটওয়েতে পৌঁছায়। Keepalived ও VRRP যেমন ভার্চুয়াল গেটওয়ে ঠিকানা দিতে পারে। দূরের রুটও সুস্থ নোড বেছে নেবে। গেটওয়ে বা টানেল বন্ধ হলে নতুন ও বিদ্যমান TCP সেশনের কী হয়, গ্রহণের সময় দেখতে চাই। চালু প্রক্রিয়া আর সফল ping কেবল আংশিক উত্তর।

কার্যকারিতা পরীক্ষায় ইচ্ছাকৃতভাবে নিষিদ্ধ সংযোগও থাকতে হবে। SSH অনুমোদিত আর অন্য অ্যাপ নিষিদ্ধ হলে সেই আচরণ যাচাই করতে হবে। ICMP সফল হওয়া TCP নিয়মের প্রমাণ নয়। নিবন্ধন, নীতি ও গন্তব্য ফায়ারওয়াল মিলতে হবে।

তারপর আছে কম চোখে পড়া বিষয়, যা দৈনন্দিন ব্যবহার নির্ধারণ করে: আলাদা prefix, অভ্যন্তরীণ নাম সমাধান এবং সঠিক MTU। 192.168.x.x বা 10.x.x.x কোনোটিই সংঘাতহীনতার নিশ্চয়তা নয়। ছোট ping চলে কিন্তু বড় স্থানান্তর আটকে গেলে আমি সংযোগ শেষ মনে করি না।

অর্থপূর্ণ গতি তুলনায় আসল লাইনে একই ফাইল স্থানান্তর ও interactive অ্যাপ দরকার। সরাসরি না relay পথ, CPU চাপ এবং ইন্টারনেট বদলের পর আচরণ নথিবদ্ধ করতে হয়। এখানে আমার মূল্যায়ন স্থাপত্য ও পরিচালনার পার্থক্য নিয়ে; পণ্যগুলোর মাপা গতির র‍্যাঙ্কিং নয়।

রিমোট অ্যাক্সেস: ব্যক্তিগত ডিভাইস যোগ করা

বাড়ি থেকে কর্মীর ল্যাপটপ কোম্পানি নেটওয়ার্কে যুক্ত হলে সেটি remote access বা client-to-site। ক্লায়েন্ট ল্যাপটপে চলে এবং পুরো ঘরের নেটওয়ার্ক নিজে থেকে প্রধান কার্যালয়ে যুক্ত হয় না। কেন্দ্রীয় ফায়ারওয়ালের পরিষেবা বা এসব প্ল্যাটফর্মের ক্লায়েন্ট ব্যবহার করা যায়। ব্যক্তিগত নিবন্ধনে ব্যবহারকারী ও গ্রুপ অনুযায়ী অনুমতিও দেওয়া যায়।

হোম অফিস site-to-site অবস্থানও হতে পারে: গেটওয়ে অনুমোদিত নেটওয়ার্ক বা VLAN প্রধান কার্যালয়ে যুক্ত করে। পার্থক্য কাজের স্থান নয়, একটি যন্ত্র না একটি নেটওয়ার্ক যুক্ত হচ্ছে। একক ডিভাইসে রিমোট অ্যাক্সেসের পরিসর প্রায়ই বেশি উপযুক্ত। উদ্দেশ্য ছাড়া পুরো ব্যক্তিগত ঘরের নেটওয়ার্ক পৌঁছানোর উপযোগী করার কারণ নেই।

কোন পদ্ধতি কোথায় আমার কাছে উপযুক্ত

কয়েকটি স্থায়ী সাইটে বিদ্যমান ফায়ারওয়াল থাকলে প্রচলিত VPN দিয়ে শুরু করে hub-and-spoke বা সরাসরি টানেল বাছব। NAT-এর পেছনে সাইট, কেন্দ্রীয় ব্যবস্থাপনা ও যথাসম্ভব সরাসরি পথ চাইলে Tailscale ও NetBird তুলনা করব। সমন্বয় নিজে চালানো বাধ্যতামূলক হলে NetBird আগে মূল্যায়নে আসে। Cloudflare One নীতি থাকলে Mesh, beta অবস্থা ও সেবাদাতার নেটওয়ার্কে প্রক্রিয়াকরণ দেখব। অতিরিক্ত রিমোট অ্যাক্সেস আলাদা মানদণ্ড।

Headscale আরেকটি বিকল্প: Tailscale সমন্বয় সার্ভারের নিজস্ব হোস্টিং বাস্তবায়ন। এটি নিজস্ব ফিচারসীমার আলাদা প্রকল্প, হোস্ট করা পরিষেবার সব ক্ষমতার পূর্ণ বিকল্প নয়। হাতে পরিচালিত WireGuard আগেই প্রচলিত মডেলের অংশ এবং কয়েকটি টানেল অতিরিক্ত ব্যবস্থাপনা স্তর ছাড়া যথেষ্ট হলে মানানসই।

সেরা সমাধান জানতে চাইলে আমি প্রতিষ্ঠান ও তার পরের পরিবর্তনের সঙ্গে মানানসই সুপারিশ দিতে চাই। বিদ্যমান ফায়ারওয়ালসহ ছোট স্থাপনায় প্রচলিত VPN-ই উপযুক্ত থাকতে পারে। অন্য সংযোগ বা ব্যবস্থাপনার চাহিদা mesh বিবেচনার কারণ হয়। প্রয়োজনীয় সংযোগ নিরাপদে চালানো, বোঝা এবং ব্যর্থতার পর ফিরিয়ে আনা সম্ভব কি না, তার ভিত্তিতে সিদ্ধান্ত নেব।

পরেরবার দেখা হবে,
Joe