WireGuard বনাম Tailscale বনাম Headscale: VPS-এ কোনটি?

WireGuard বনাম Tailscale: সংক্ষিপ্ত উত্তর

WireGuard এবং Tailscale-এর মধ্যে তুলনা করা মানে দুটি ভিন্ন প্রোটোকলের মধ্যে বেছে নেওয়া নয়, কারণ Tailscale মূলত WireGuard-ই ব্যবহার করে। Tailscale একই এনক্রিপশন এবং একই টানেল ব্যবহার করে, তবে এর সাথে একটি কন্ট্রোল প্লেন যুক্ত করে: একটি কোঅর্ডিনেশন সার্ভার যা পাবলিক কি (public keys) আদান-প্রদান করে, IP অ্যাড্রেস প্রদান করে, NAT (network address translation) ভেদ করে সংযোগ স্থাপন করে এবং অ্যাক্সেস পলিসি প্রয়োগ করে। আপনি মূলত সিদ্ধান্ত নিচ্ছেন যে এই কোঅর্ডিনেশনের কতটুকু আপনি নিজে পরিচালনা করতে চান।

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

কন্ট্রোল প্লেন আসলে কী সুবিধা দেয়

Plain WireGuard-এ কোনো discovery ব্যবস্থা নেই। প্রতিটি peer হলো হাতে লেখা একটি text block: একটি public key, একটি AllowedIPs line এবং peer-টি reachable হলে একটি Endpoint। দশটি মেশিনের একটি network-এ একটি মেশিন যোগ করতে হলে দশটি config file সম্পাদনা করতে হয়, কারণ প্রতিটি পাশে অন্য পাশের key প্রয়োজন। এ কারণেই প্রায় সব self-hosted WireGuard setup hub-and-spoke হয়: একটি public IP-সহ server এবং এমন client, যেগুলো কেবল ওই server-এর সঙ্গেই যোগাযোগ করে।

একটি control plane এই editing-এর প্রয়োজন সরিয়ে দেয়। প্রতিটি node একবার register করে, 100.64.0.0/10 CGNAT (carrier grade NAT) range থেকে একটি address পায় এবং যেসব node-এ তার reach করার অনুমতি আছে, সেগুলোর public key পায়। Tunnel এখনও দুই peer-এর মধ্যে সরাসরি WireGuard connection, এবং আপনার traffic কখনও coordination server-এর মধ্য দিয়ে যায় না। Server যে metadata বহন করে তা হলো: কোন node বিদ্যমান, কোন key কার, এবং কে কার সঙ্গে যোগাযোগ করতে পারবে।

এতে তিনটি নির্দিষ্ট সুবিধা পাওয়া যায়।

NAT traversal। দুটি home router-এর পেছনে থাকা দুটি laptop-এর মধ্যে কোনো public IP থাকে না। Tailscale STUN (session traversal utilities for NAT) ব্যবহার করে দুই পাশের বাইরের address ও port শনাক্ত করে। এরপর দুই পাশ একই সময়ে packet পাঠায়, যাতে প্রতিটি router আগে একটি outgoing flow দেখে এবং reply গ্রহণ করে। এটি ব্যর্থ হলে traffic DERP relay-এ fallback করে। এটি Tailscale পরিচালিত একটি encrypted relay। Relay-এর মধ্য দিয়েও আপনার data end-to-end encrypted থাকে, কারণ relay কখনও key ধারণ করে না। tailscale status চালালে প্রতিটি peer line-এ direct অথবা relay দেখা যায়। কোন relay সবচেয়ে কাছে এবং আপনার network আদৌ UDP অনুমতি দেয় কি না দেখতে tailscale netcheck চালান।

Expiry-সহ key rotation। WireGuard key কখনও expire হয় না। তিন বছর আগে issue করা একটি key চিরকাল কাজ করবে, যদি না আপনি হাতে peer block মুছে ফেলেন। এর পরিবর্তে Tailscale node key expire করে। October 2026 অনুযায়ী, নতুন tailnet-এ default expiry period হলো 180 days। যে machine reauthenticate করেনি, সেটি আর connect করতে পারে না। যে server বা subnet router-এ login করার জন্য কেউ উপস্থিত থাকবে না, তার ক্ষেত্রে প্রতি device-এর জন্য expiry বন্ধ করতে পারেন।

Routing-এর পরিবর্তে policy। Plain WireGuard-এ AllowedIPs একই সঙ্গে routing table এবং access control list। তাই "alice may reach the database" কথাটি একটি IP range হিসেবে প্রকাশ করতে হয়। Tailscale একটি আলাদা policy file রাখে, যেখানে rule-এ user, group এবং tag-এর নাম ব্যবহার করা যায়। একটি rule-এ বলা যেতে পারে যে tag:laptop port 5432-এ tag:db-এ reach করতে পারবে, অন্য কোথাও নয়। কোনো machine নতুন address পেলেও সেই rule কার্যকর থাকে।

কন্ট্রোল প্লেনের খরচ

Coordination server আপনার network সম্পর্কে জানে। এতে প্রতিটি node-এর public key, প্রতিটি node-এর নাম, বরাদ্দ করা প্রতিটি address এবং policy সংরক্ষিত থাকে। Hosted Tailscale ব্যবহার করলে এই server আপনার নিয়ন্ত্রণের বাইরের একটি কোম্পানি পরিচালনা করে। তারা আপনার packet পড়তে পারে না, কারণ WireGuard private key আপনার machine-এই থাকে। তবে আপনার network-এর কাঠামো তারা দেখতে পারে। আপনার connect করার সক্ষমতাও তাদের service চালু থাকা এবং আপনার account-এর good standing-এর ওপর নির্ভর করে। Compromised coordination server বা চুরি হওয়া identity account তার কাছে থাকা তথ্য দিয়ে বাস্তবে কী করতে পারে, তার ওপর নির্ভর করে এই ঝুঁকিকে কতটা গুরুত্ব দেবেন। এই কারণেই Tailscale-এর trust model সম্পূর্ণ পড়ে দেখা মূল্যবান।

আরেকটি খরচ সহজে চোখ এড়িয়ে যায়। Tailscale প্রতিটি machine-এ একটি daemon হিসেবে চলে। তাই এখন প্রতিটি machine-এ এই software-এর patch বজায় রাখতে হবে। Ubuntu 24.04-এ সাধারণ WireGuard distribution-এর সঙ্গে সরবরাহ করা একটি kernel module, যা kernel-এর সঙ্গে update হয়।

তৃতীয় খরচ হলো billing। October 2026 অনুযায়ী Personal plan বিনামূল্যে এবং এতে সর্বোচ্চ 6 জন user-এর জন্য unlimited user device রয়েছে। Standard-এর দাম প্রতি user প্রতি মাসে $8 এবং Premium-এর দাম প্রতি user প্রতি মাসে $18। একটি household বিনামূল্যেই থাকতে পারে। দশজনের একটি team পারে না। আপনি এই সীমা অতিক্রম করবেন কি না, তা মূলত device-এর বদলে seat-এর সংখ্যার ওপর নির্ভর করে। তবে একটি ব্যতিক্রম আছে: server এবং অন্যান্য tagged device-এর জন্য আলাদা allowance রয়েছে। প্রতিটি plan-এ 50টি tagged resource অন্তর্ভুক্ত থাকে। October 2026 অনুযায়ী pricing page-এ এর বেশি প্রতিটির জন্য প্রতি মাসে $1 মূল্য তালিকাভুক্ত আছে। সপ্তম user-কে invite করা বা পঞ্চাশতম server tag করার আগে free plan আসলে কী কী কভার করে তা পড়ে দেখা মূল্যবান।

যখন সরাসরি WireGuard-ই সঠিক পছন্দ

Topology প্রকৃতপক্ষে hub-and-spoke হলে সরাসরি WireGuard বেছে নিন। একটি public IP-সহ VPS থাকবে, তিন বা চারটি device সেটিতে সংযোগ করবে, এবং ওই device-গুলোর একে অপরের কাছে পৌঁছানোর প্রয়োজন থাকবে না। Configuration একটি screen-এ রাখা যায়। কোনো daemon update করার দরকার হয় না, হারানোর মতো কোনো account থাকে না, এবং আপনার ও server-এর মাঝখানে কোনো বাইরের service থাকে না।

আপনি যদি বুঝতে চান অন্য সবকিছু কোন layer-এর ওপর তৈরি, তাহলেও এটি সঠিক পছন্দ। VPS-এ WireGuard VPN self-host করা-এ key generation, wg0.conf, IP forwarding, NAT এবং handshake failure-এর প্রক্রিয়া দেখানো হয়েছে। প্রতিটি tailnet-এর নিচে এখনও key এবং handshake কাজ করে। কোনো tailnet node subnet router বা exit node হিসেবে কাজ করলেই IP forwarding আবার প্রয়োজন হয়। আপনি যদি পুরোনো বিকল্পটি এখনও বিবেচনা করেন, WireGuard বনাম OpenVPN-এ সেই চারটি পরিস্থিতি ব্যাখ্যা করা হয়েছে যেখানে OpenVPN এখনও সুবিধা ধরে রাখে।

Install সংক্ষিপ্ত:

sudo apt update && sudo apt install -y wireguard
sudo modprobe wireguard && echo ok

প্রতিটি device-কে অন্য প্রতিটি device-এ পৌঁছাতে হলে সরাসরি WireGuard ব্যবহার করা আর সুবিধাজনক থাকে না। Nটি node-এর একটি full mesh-এ N times N minus oneটি peer block প্রয়োজন। ছয়টি device হলে হাতে sync করে রাখতে হয় ত্রিশটি block। কোনো AllowedIPs entry duplicate হলে সেটি নীরবে আগে থাকা peer-এর traffic নিজের দিকে নিয়ে নেয়। কোথাও কোনো error দেখানো হয় না।

Tailscale কখন সঠিক পছন্দ

মেশিনগুলো যখন বিভিন্ন নেটওয়ার্কে চলাচল করে, তখন Tailscale বেছে নিন। হোটেলের নেটওয়ার্কে থাকা ল্যাপটপ, mobile data ব্যবহার করা ফোন, অথবা এমন router-এর পেছনে থাকা home server যেটি আপনি নিয়ন্ত্রণ করেন না—এসব ক্ষেত্রেই সাধারণ WireGuard ভালোভাবে কাজ করে না। কারণ Endpoint-এ দেওয়ার মতো কোনো পক্ষেরই স্থায়ী public endpoint থাকে না।

Official installer থেকে client install করতে একটি command-ই যথেষ্ট:

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up
tailscale status

tailscale up একটি URL দেখায়। সেটি খুলে log in করুন, তারপর মেশিনটি network-এ যুক্ত হবে। কোনো key copy করতে হয় না এবং inbound port খুলতে হয় না, কারণ daemon coordination server-এর সঙ্গে outbound connection তৈরি করে সেটি চালু রাখে। এ কারণেই এমন network-এও Tailscale node কাজ করে, যেখানে আপনি কোনো firewall নিয়ন্ত্রণ করেন না।

এরপর দুটি setting বেশিরভাগ প্রয়োজনীয় কাজ সম্পন্ন করে। একটি subnet router পুরো LAN-কে network-এ advertise করে, তাই প্রতিটি device-এ client install করতে হয় না:

echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
sudo sysctl -p /etc/sysctl.d/99-tailscale.conf
sudo tailscale set --advertise-routes=192.0.2.0/24

Admin console-এ অনুমোদন না করা পর্যন্ত route-টি inactive থাকে। এটি ইচ্ছাকৃত আচরণ: কোনো node নিজে থেকে আপনার network-এ route inject করতে পারে না। Linux client-এরও sudo tailscale set --accept-routes প্রয়োজন, কারণ Linux default হিসেবে advertised route গ্রহণ করে না। তাই server side-এ অনুমোদিত দেখালেও sudo tailscale set --accept-routes সেট না করা পর্যন্ত Linux laptop-এ route-টি কোনো কাজ করবে না। এই ধরনের configuration চাইলে VPS-এ subnet router চালানো approval ধাপ এবং forwarding setting এমন ক্রমে দেখায়, যাতে route অর্ধেক configured অবস্থায় না থাকে।

একটি exit node client-এর সাধারণ internet traffic—অর্থাৎ অন্য tailnet device বা অনুমোদিত subnet route-এর দিকে আগে থেকেই না যাওয়া সব traffic—একটি মেশিনের মাধ্যমে পাঠায়। এটিই সেই full tunnel আচরণ, যাকে সাধারণত “VPN” বলা হয়। এটি advertise করার আগে Linux-এ উপরে দেখানো একই IP forwarding setting প্রয়োজন:

sudo tailscale set --advertise-exit-node

Flag-টি সহজ অংশ। এর পরের ধাপগুলো VPS-কে exit node-এ রূপান্তর করা-তে দেখানো হয়েছে: admin console-এ route অনুমোদন করা, তারপর DNS এবং IPv6-এর আচরণ ঠিক করা, যাতে traffic ভুল পথে বাইরে না যায়। আপনি যদি পুরো network-এর বদলে একটি web service-এ পৌঁছাতে চান, তাহলে serve এবং funnel ব্যবহার করে একটি নির্দিষ্ট local port-এর সামনে HTTPS বসান। এটি শুধু tailnet-এর জন্য রাখা যায়, অথবা public internet-এর জন্য উন্মুক্ত করা যায়।

কখন Headscale সঠিক সমাধান

Headscale হলো coordination server-এর একটি ওপেন সোর্স ইমপ্লিমেন্টেশন, যা আপনার নিজস্ব VPS-এ চলে। অফিসিয়াল Tailscale ক্লায়েন্টগুলো হোস্ট করা সার্ভিসের পরিবর্তে এটির দিকে নির্দেশ করে:

sudo tailscale up --login-server https://headscale.example.com

ডেটা পাথের সবকিছু অপরিবর্তিত থাকে। এটি এখনও WireGuard, এবং নেটওয়ার্ক অনুমতি দিলে পিয়ারগুলোর মধ্যে সরাসরি সংযোগ বজায় থাকে। যা পরিবর্তিত হয় তা হলো নোড লিস্ট, কি (keys) এবং পলিসি—এগুলো আপনার নিজস্ব ডিস্কে থাকা একটি SQLite ফাইলে থাকে। বাইরের কেউ আপনার নেটওয়ার্কের গঠন দেখতে পারে না, আপনার অ্যাকাউন্ট নিষ্ক্রিয় করতে পারে না বা ব্যবহারকারী প্রতি বিল করতে পারে না।

এর বিনিময়ে আপনাকে বাস্তব কিছু কাজ করতে হবে। আপনি এখন একটি পাবলিক HTTPS সার্ভিস চালাচ্ছেন, যার অর্থ হলো একটি DNS নাম, একটি সার্টিফিকেট এবং একটি রিভার্স প্রক্সি যা WebSocket আপগ্রেডগুলোকে সঠিকভাবে পাস করে। এর আপটাইম আপনার দায়িত্ব, এবং একটি coordination server ডাউন থাকলে নতুন নোড রেজিস্টার হতে পারে না এবং বিদ্যমান নোডগুলো কোনো পরিবর্তন সম্পর্কে জানতে পারে না। Headscale এখনও 1.0 ভার্সনের নিচে এবং এর মাইনর রিলিজগুলোতে অনেক সময় ব্রেকিং চেঞ্জ থাকে, তাই প্রতিটি আপগ্রেডের আগে চেঞ্জলগ পড়ে নিন। আপনার নিজস্ব Tailscale কন্ট্রোল সার্ভার হিসেবে Headscale চালানো অংশে ইনস্টলেশন, config.yaml, প্রি-অথ কি (preauth keys) এবং যে পোর্টগুলো ওপেন করতে হবে তা আলোচনা করা হয়েছে।

একটি গুরুত্বপূর্ণ সীমাবদ্ধতা অনেকেই দেরিতে বুঝতে পারেন। Headscale-এর সঙ্গে Tailscale-এর বৈশ্বিক relay network থাকে না। দুই peer সরাসরি সংযোগ করতে না পারলে আপনাকে নিজের server-এ embedded relay চালু করতে হবে, অথবা configuration-এ অন্য একটি relay নির্দিষ্ট করতে হবে। সেই relay একটি region-এ থাকা একটি মাত্র box; এটি বিশ্বজুড়ে বিস্তৃত fleet নয়। পৃথিবীর অন্য প্রান্তে থাকা peer-গুলো এই পার্থক্য স্পষ্টভাবে অনুভব করে। আপনি যদি এই অংশটি নিজে তৈরি করতে না চান, তাহলে NetBird self-hosting হলো control plane নিজের infrastructure-এর মধ্যে রাখার আরেকটি উপায়। এর quickstart একই VPS-এ management, signal এবং relay service একসঙ্গে চালু করে। তবে Headscale-এর মতো NetBird সরাসরি ব্যবহারযোগ্য Tailscale server নয়। NetBird-এর নিজস্ব client এবং নিজস্ব policy model আছে। তাই Headscale-এর পরিবর্তে এটি বেছে নেওয়ার আগে access rule এবং relay-এর ক্ষেত্রে NetBird ও Tailscale-এর পার্থক্য পড়ুন।

একবারেই সিদ্ধান্ত নেওয়ার পদ্ধতি

কতগুলো মেশিনকে একে অপরের সঙ্গে যোগাযোগ করতে হবে, তা নির্ধারণ করুন। যদি সব মেশিনের শুধু server-এর সঙ্গে যোগাযোগের প্রয়োজন হয়, তাহলে একই ফলাফলের জন্য plain WireGuard-এ কম software লাগে।

মেশিনগুলোর stable public address আছে কি না, তা যাচাই করুন। বেশিরভাগ মেশিন যদি আপনার নিয়ন্ত্রণের বাইরে থাকা NAT-এর পেছনে থাকে, তাহলে আপনার একটি control plane প্রয়োজন। কারণ hole punching-ই কঠিন অংশ, আর এটি নতুন করে তৈরি করা সাধারণত যুক্তিসঙ্গত নয়।

আপনার network-এর কাঠামো কে জানতে পারবে, তা বিবেচনা করুন। উত্তরটি যদি বাইরের company-গুলোকে বাদ দেয়, অথবা user-এর সংখ্যা per-seat billing-কে ব্যয়বহুল করে তোলে, তাহলে Headscale চালান এবং মনে রাখুন যে এখন আপনাকেই control server পরিচালনা করতে হবে। billing যদি migration-এর প্রধান কারণ হয়, commit করার আগে হিসাব করুন। কারণ আপনার team-এর আকার অনুযায়ী প্রকৃত খরচ মূলত কতজনের account আছে তার ওপর নির্ভর করে, আপনি কতগুলো machine চালান তার ওপর নয়—যতক্ষণ না আপনার tagged server-এর সংখ্যা প্রতিটি plan-এ অন্তর্ভুক্ত 50 অতিক্রম করছে। এই দুটি সংখ্যা খুব কমই কাছাকাছি হয়।

আপনি কম খরচে সিদ্ধান্ত পরিবর্তন করতে পারেন। তিন ক্ষেত্রেই data plane একই protocol ব্যবহার করে। তাই plain WireGuard থেকে coordinated mesh-এ যেতে client install করলেই হয়, নতুন করে architecture নকশা করতে হয় না। Tailscale থেকে Headscale-এ যেতে প্রতিটি node-কে ভিন্ন login server-এর বিরুদ্ধে পুনরায় register করলেই হয়।

এই তিনটির কোনোটিই আপনাকে যা দেয় না

এগুলোর কোনোটিই firewall নয়। একটি tunnel নির্ধারণ করে কোন প্যাকেটগুলো পরিবাহিত হবে, কোন service listen করবে তা নয়। tunnel-এর মাধ্যমে reachable একটি server ইন্টারনেটে উন্মুক্ত থাকা যেকোনো port থেকে এখনো reachable থাকতে পারে, তাই VPS-এ UFW firewall rules তাদের কাজ চালিয়ে যাচ্ছে কি না তা নিশ্চিত করুন। Tailscale-এর policy file শুধুমাত্র অন্যান্য node কী কী access করতে পারবে তা সীমিত করে, কিন্তু public interface-এর ক্ষেত্রে এটি কোনো কাজ করে না।

এগুলোর কোনোটিই per-service authentication প্রদান করে না এবং কোনোটিই ব্যবহারকারী connect হওয়ার পর কী কী কাজ করেছেন তার audit trail রাখে না। এই তিনটিকে শুধুমাত্র transport হিসেবে বিবেচনা করুন এবং application-এর ভেতরেই login check-এর ব্যবস্থা রাখুন।

FAQ

Tailscale কি কেবল অতিরিক্ত ধাপসহ WireGuard?

Tailscale ডেটা পাথের জন্য WireGuard প্রোটোকল ব্যবহার করে, তাই এনক্রিপশন এবং টানেল একই থাকে। এটি যা যোগ করে তা হলো কোঅর্ডিনেশন: কি এক্সচেঞ্জ (key exchange), অ্যাড্রেস অ্যাসাইনমেন্ট, STUN এবং DERP রিলে ব্যবহার করে NAT ট্রাভার্সাল, কি এক্সপায়ারি (key expiry), এবং এমন একটি পলিসি ফাইল যা IP রেঞ্জের পরিবর্তে ব্যবহারকারীর নাম ব্যবহার করে। সাধারণ WireGuard-এ এই অংশগুলো আপনাকে নিজে সামলাতে হয়, এবং মেশিনগুলো যখন বিভিন্ন নেটওয়ার্কের মধ্যে চলাচল করে তখন এই কাজগুলোই জটিল হয়ে পড়ে।

আমার ট্রাফিক কি Tailscale-এর সার্ভারের মধ্য দিয়ে যায়?

সাধারণত না। কোঅর্ডিনেশন সার্ভার একবার পিয়ারদের পরিচয় করিয়ে দিলে তারা সরাসরি একে অপরের সাথে সংযুক্ত হয় এবং tailscale status-এ সেই পিয়ার লাইনগুলোতে direct দেখায়। যখন সরাসরি পথ তৈরি করা সম্ভব হয় না, তখন ট্রাফিক DERP রিলে-তে ফিরে যায় এবং লাইনটিতে relay লেখা দেখায়। এমনকি তখনও রিলে এনক্রিপ্ট করা প্যাকেট বহন করে এবং আপনার WireGuard প্রাইভেট কি (private keys) তাদের কাছে থাকে না, তাই তারা বিষয়বস্তু পড়তে পারে না। সরাসরি সংযোগের জন্য প্রয়োজনীয় UDP আপনার নেটওয়ার্ক ব্লক করছে কিনা তা দেখতে tailscale netcheck চালান।

আমি কি অফিসিয়াল Tailscale অ্যাপের সাথে Headscale ব্যবহার করতে পারি?

হ্যাঁ। Headscale একই কন্ট্রোল প্রোটোকল ব্যবহার করে, তাই অফিসিয়াল ক্লায়েন্টরা sudo tailscale up --login-server https://headscale.example.com দিয়ে যুক্ত হয়। ডেস্কটপ এবং মোবাইল অ্যাপগুলোকেও একটি কাস্টম লগইন সার্ভারের দিকে নির্দেশ করা যায়, যদিও প্রতিটি প্ল্যাটফর্মে এই সেটিংটি ভিন্ন জায়গায় থাকে এবং মোবাইল অ্যাপগুলোর ক্ষেত্রে নির্দিষ্ট ভার্সনের প্রয়োজন হওয়ার সম্ভাবনা সবচেয়ে বেশি। পুরো নেটওয়ার্ক মাইগ্রেট করার আগে একটি ফোনে পরীক্ষা করে নিন।

Tailscale বা Headscale-এর জন্য আমার কি এখনও পোর্ট খোলা রাখতে হবে?

Tailscale ক্লায়েন্টের কোনো ইনবাউন্ড পোর্টের প্রয়োজন নেই, কারণ এটি কোঅর্ডিনেশন সার্ভারের সাথে ডায়াল আউট করে এবং সেই সংযোগটি খোলা রাখে। একটি সেলফ-হোস্টেড Headscale সার্ভারের ইনবাউন্ড পোর্টের প্রয়োজন হয়: কন্ট্রোল প্রোটোকলের জন্য 443, আপনি যদি HTTP-01 সার্টিফিকেট চ্যালেঞ্জ ব্যবহার করেন তবে 80, এবং শুধুমাত্র যখন আপনি এমবেডেড রিলে সক্রিয় করবেন তখন 3478/udp। সাধারণ WireGuard-এর জন্য এর UDP লিসেন পোর্ট, সাধারণত 51820, সার্ভারে এবং আপনার প্রোভাইডারের চালানো যেকোনো আলাদা নেটওয়ার্ক ফায়ারওয়ালে খোলা থাকতে হবে।

তিনটির মধ্যে কোনটি সবচেয়ে দ্রুত?

থ্রুপুট একই, কারণ তিনটির ক্ষেত্রেই WireGuard দিয়ে প্যাকেট আদান-প্রদান হয়। পার্থক্য দেখা যায় সংযোগ স্থাপনের সময় এবং পথের গুণমানের ক্ষেত্রে। সঠিক Endpoint সহ সাধারণ WireGuard প্রতিবার সরাসরি সংযুক্ত হয়। Tailscale এবং Headscale বেশিরভাগ সময় সরাসরি সংযুক্ত হয় এবং নেটওয়ার্ক হোল পাঞ্চিং (hole punching) ব্লক করলে রিলে-তে ফিরে যায়, আর রিলে করা পথে ল্যাটেন্সি (latency) বেড়ে যায়। tailscale ping <node> দিয়ে আপনার নিজের পথের পরিমাপ করুন, যা রুটটি সরাসরি নাকি রিলে করা তা রিপোর্ট করে, অথবা টানেলের মাধ্যমে iperf3 ব্যবহার করুন। যদি সরাসরি পথে সেই সংখ্যাটি আপনার লাইন রেটের চেয়ে অনেক কম আসে, তবে এই তিনটির মধ্যে কোনটি বেছে নেবেন তা আপনার সমস্যার কারণ নয়, এবং সাধারণ কারণ হলো পাথ MTU অমিল যা কন্ট্রোল প্লেন থাকুক বা না থাকুক একইভাবে কাজ করে।