WireGuard বনাম Tailscale বনাম Headscale: কোনটি বেছে নেবেন?

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

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

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

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

সাধারণ WireGuard-এ কোনো discovery ব্যবস্থা নেই। প্রতিটি পিয়ার হলো হাতে লেখা একগুচ্ছ টেক্সট: একটি পাবলিক কি, একটি AllowedIPs লাইন এবং যদি পিয়ারটি reachable হয় তবে একটি Endpoint। দশটি মেশিনের নেটওয়ার্কে একটি নতুন মেশিন যোগ করার অর্থ হলো দশটি কনফিগারেশন ফাইল এডিট করা, কারণ প্রতিটি প্রান্তের অন্যটির কি (key) প্রয়োজন হয়। এই কারণেই প্রায় সব self-hosted WireGuard সেটআপ hub and spoke মডেলে চলে: একটি পাবলিক আইপি-সহ সার্ভার এবং ক্লায়েন্টরা যারা শুধুমাত্র সেই সার্ভারের সাথেই কথা বলে।

একটি কন্ট্রোল প্লেন এই এডিটিংয়ের ঝামেলা দূর করে। প্রতিটি নোড একবার রেজিস্টার করে, 100.64.0.0/10 CGNAT (carrier grade NAT) রেঞ্জ থেকে একটি অ্যাড্রেস পায় এবং তাকে জানানো হয় কোন কোন নোডের সাথে সে যোগাযোগ করতে পারবে। টানেলটি এখনও দুটি পিয়ারের মধ্যে সরাসরি WireGuard সংযোগ হিসেবেই থাকে এবং আপনার ট্রাফিক কখনোই কোঅর্ডিনেশন সার্ভারের মধ্য দিয়ে যায় না। সার্ভারটি যা বহন করে তা হলো মেটাডেটা: কারা বিদ্যমান, কার কি (key) কোনটি এবং কে কার সাথে কথা বলতে পারবে।

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

NAT traversal. দুটি হোম রাউটারের পেছনে থাকা দুটি ল্যাপটপের মধ্যে কোনো পাবলিক আইপি থাকে না। Tailscale প্রতিটি প্রান্তের বাইরের অ্যাড্রেস এবং পোর্ট খুঁজে বের করতে STUN (session traversal utilities for NAT) ব্যবহার করে। এরপর উভয় প্রান্ত একই সময়ে প্যাকেট পাঠায় যাতে প্রতিটি রাউটার প্রথমে একটি আউটগোয়িং ফ্লো দেখে এবং রিপ্লাই গ্রহণ করে। যখন এটি ব্যর্থ হয়, ট্রাফিক একটি DERP রিলে-তে চলে যায়, যা Tailscale দ্বারা পরিচালিত একটি এনক্রিপ্টেড রিলে। রিলে-র মধ্য দিয়ে যাওয়ার সময়ও আপনার ডেটা end-to-end এনক্রিপ্টেড থাকে, কারণ রিলে-র কাছে কোনো কি (key) থাকে না। tailscale status রান করলে প্রতিটি পিয়ার লাইনে direct অথবা relay দেখাবে। কোন রিলে সবচেয়ে কাছে এবং আপনার নেটওয়ার্ক UDP সমর্থন করে কি না তা দেখতে tailscale netcheck রান করুন।

মেয়াদসহ কি রোটেশন (Key rotation with an expiry). WireGuard কি (key)-এর কোনো মেয়াদ শেষ হয় না। তিন বছর আগে ইস্যু করা একটি কি চিরকাল কাজ করবে, যদি না আপনি হাতে পিয়ার ব্লকটি ডিলিট করেন। Tailscale এর পরিবর্তে নোড কি-এর মেয়াদ শেষ করে। জুলাই 2026 থেকে নতুন tailnet-এ ডিফল্ট মেয়াদ শেষ হওয়ার সময়কাল হলো 180 দিন। যে মেশিনটি পুনরায় অথেন্টিকেট করেনি সেটি সংযোগ বিচ্ছিন্ন করে দেয়। সার্ভার বা সাবনেট রাউটারের মতো ডিভাইসের ক্ষেত্রে, যেখানে লগইন করার জন্য কেউ থাকবে না, আপনি চাইলে প্রতি ডিভাইসের জন্য এই মেয়াদ শেষ হওয়ার সুবিধাটি বন্ধ রাখতে পারেন।

রাউটিংয়ের পরিবর্তে পলিসি। সাধারণ WireGuard-এ AllowedIPs একই সাথে রাউটিং টেবিল এবং অ্যাক্সেস কন্ট্রোল লিস্ট হিসেবে কাজ করে, তাই "alice ডাটাবেসে পৌঁছাতে পারবে" এই শর্তটি আইপি রেঞ্জ হিসেবে প্রকাশ করতে হয়। Tailscale একটি আলাদা পলিসি ফাইল রাখে যেখানে রুলগুলো ইউজার, গ্রুপ এবং ট্যাগ ব্যবহার করে তৈরি করা হয়। একটি রুলে বলা থাকতে পারে যে tag:laptop শুধুমাত্র 5432 পোর্টে tag:db-এ পৌঁছাতে পারবে এবং অন্য কিছুতে নয়। মেশিন নতুন অ্যাড্রেস পেলেও এই রুলটি কার্যকর থাকে।

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

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

দ্বিতীয় একটি খরচ আছে যা সহজে এড়িয়ে যাওয়া যায়। Tailscale প্রতিটি মেশিনে একটি ডেমোন হিসেবে চলে, তাই প্রতিটি মেশিনে এই সফটওয়্যারটি আপনাকে আপডেট রাখতে হবে। Ubuntu 24.04-এ সাধারণ WireGuard একটি কার্নেল মডিউল হিসেবে থাকে, যা ডিস্ট্রিবিউশনের সাথে আসে এবং কার্নেলের সাথেই আপডেট হয়।

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

কখন সাধারণ WireGuard ব্যবহার করা সঠিক সিদ্ধান্ত

যখন টপোলজিটি মূলত হাব-অ্যান্ড-স্পোক (hub and spoke) প্রকৃতির হয়, তখন সাধারণ WireGuard বেছে নিন। একটি পাবলিক IP-সহ একটি VPS, তার সাথে সংযুক্ত তিন বা চারটি ডিভাইস এবং ডিভাইসগুলোর একে অপরের সাথে যোগাযোগের কোনো প্রয়োজন নেই—এমন ক্ষেত্রে এটি আদর্শ। এর কনফিগারেশন একটি স্ক্রিনেই ধরে যায়, আপডেট করার জন্য কোনো ডেমন নেই, হারানোর মতো কোনো অ্যাকাউন্ট নেই এবং আপনার ও আপনার সার্ভারের মাঝে কোনো তৃতীয় পক্ষীয় পরিষেবা নেই।

আপনি যখন বুঝতে চান যে অন্য সব কিছু কোন স্তরের ওপর ভিত্তি করে তৈরি, তখনও এটি সঠিক সিদ্ধান্ত। VPS-এ WireGuard VPN সেলফ-হোস্ট করা নিবন্ধে কি জেনারেশন (key generation), wg0.conf, IP ফরোয়ার্ডিং, NAT এবং হ্যান্ডশেক ফেইলিয়র নিয়ে আলোচনা করা হয়েছে, এবং এই প্রতিটি মেকানিজম একটি টেলনেট (tailnet)-এর নিচেও একইভাবে কাজ করে। আপনি যদি এখনও পুরনো বিকল্পটি বিবেচনা করেন, তবে WireGuard বনাম OpenVPN নিবন্ধটি দেখুন, যেখানে চারটি ক্ষেত্রে OpenVPN-এর সুবিধাগুলো তুলে ধরা হয়েছে।

ইনস্টলেশন প্রক্রিয়াটি সংক্ষিপ্ত:

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

সাধারণ WireGuard ব্যবহার করা তখনই অসুবিধাজনক হয়ে ওঠে যখন প্রতিটি ডিভাইসকে অন্য সব ডিভাইসের সাথে যোগাযোগ করতে হয়। N সংখ্যক নোডের একটি ফুল মেশ (full mesh) নেটওয়ার্কে N গুণ N বিয়োগ এক সংখ্যক পিয়ার ব্লক প্রয়োজন। ছয়টি ডিভাইসের ক্ষেত্রে এটি ত্রিশটি ব্লকের সমান, যা হাতে ম্যানুয়ালি সিঙ্ক রাখতে হয়। এছাড়া, একটি ডুপ্লিকেট AllowedIPs এন্ট্রি থাকলে তা নীরবে প্রথম পিয়ারের ট্রাফিক চুরি করে নেয়, অথচ কোথাও কোনো এরর মেসেজ প্রদর্শিত হয় না।

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

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

অফিসিয়াল ইনস্টলার থেকে একটি কমান্ডের মাধ্যমেই ক্লায়েন্ট ইনস্টল করা যায়:

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

tailscale up একটি URL প্রদর্শন করবে। সেটি ওপেন করুন, লগ ইন করুন এবং মেশিনটি যুক্ত হয়ে যাবে। এখানে কপি করার মতো কোনো কি (key) নেই এবং কোনো ইনবাউন্ড পোর্ট খোলার প্রয়োজন নেই, কারণ ডেমোনটি কোঅর্ডিনেশন সার্ভারের সাথে একটি আউটবাউন্ড কানেকশন তৈরি করে এবং তা সচল রাখে। এই কারণেই Tailscale নোড এমন নেটওয়ার্কেও কাজ করে যেখানে আপনার কোনো ফায়ারওয়াল নিয়ন্ত্রণ নেই।

এরপরে দুটি সেটিংস বেশিরভাগ প্রয়োজনীয় কাজ সম্পন্ন করে। একটি সাবনেট রাউটার পুরো LAN-কে নেটওয়ার্কের অন্তর্ভুক্ত করে, ফলে প্রতিটি ডিভাইসে ক্লায়েন্ট ইনস্টল করার প্রয়োজন হয় না:

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

অ্যাডমিন কনসোলে অনুমোদন না দেওয়া পর্যন্ত রুটটি নিষ্ক্রিয় থাকে, যা ইচ্ছাকৃতভাবেই করা হয়েছে: একটি নোড নিজে থেকে আপনার নেটওয়ার্কে কোনো রুট ইনজেক্ট করতে পারে না। লিনাক্স ক্লায়েন্টদের জন্য sudo tailscale set --accept-routes প্রয়োজন, কারণ লিনাক্স ডিফল্টভাবে বিজ্ঞাপিত রুট গ্রহণ করে না। তাই সার্ভার সাইডে রুট অনুমোদিত দেখালেও, আপনি সেটি সেট না করা পর্যন্ত লিনাক্স ল্যাপটপে তা কাজ করবে না। আপনি যদি এই পদ্ধতিটি অনুসরণ করতে চান, তবে running a subnet router on a VPS নির্দেশিকাটি দেখুন; এটি অনুমোদন প্রক্রিয়া এবং ফরওয়ার্ডিং সেটিংস এমনভাবে সম্পন্ন করে যাতে রুটটি আংশিক কার্যকর না হয়ে পুরোপুরি কাজ করে।

একটি এক্সিট নোড ক্লায়েন্টের সমস্ত ট্রাফিক একটি নির্দিষ্ট মেশিনের মধ্য দিয়ে পাঠায়, যা মূলত সেই পূর্ণ টানেল আচরণ যা মানুষ সাধারণত "VPN" বলতে বোঝায়:

sudo tailscale set --advertise-exit-node

এই ফ্ল্যাগটি সেট করা সহজ অংশ, এবং turning a VPS into an exit node নির্দেশিকাটি এর পরবর্তী ধাপগুলো কভার করে: অ্যাডমিন কনসোলে রুট অনুমোদন করা, এবং তারপর DNS ও IPv6 আচরণ ঠিক করা, যা অন্যথায় ট্রাফিককে ভুল পথে পাঠিয়ে দেয়। আপনি যদি পুরো নেটওয়ার্কের পরিবর্তে কেবল একটি ওয়েব সার্ভিস অ্যাক্সেস করতে চান, তবে serve and funnel ব্যবহার করে একটি সিঙ্গেল লোকাল পোর্টের সামনে HTTPS বসাতে পারেন, যা কেবল tailnet-এর জন্য অথবা পাবলিক ইন্টারনেটের জন্য উন্মুক্ত রাখা সম্ভব।

কখন 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-এর গ্লোবাল রিলে নেটওয়ার্ক থাকে না। যেখানে দুটি পিয়ার সরাসরি সংযোগ করতে পারে না, সেখানে আপনাকে হয় আপনার নিজস্ব সার্ভারে এমবেডেড রিলে চালু করতে হবে অথবা কনফিগারেশন অন্য কোনো সার্ভারের দিকে নির্দেশ করতে হবে, এবং সেই রিলেটি বিশ্বব্যাপী ফ্লিটের পরিবর্তে একটি নির্দিষ্ট অঞ্চলের একটি মাত্র বক্স। পৃথিবীর বিপরীত প্রান্তে থাকা পিয়াররা সেই পার্থক্য অনুভব করবে। আপনি যদি নিজে এই অংশটি তৈরি করতে না চান, তবে NetBird সেলফ-হোস্টিং হলো কন্ট্রোল প্লেন নিজের কাছে রাখার অন্য একটি উপায়, কারণ এর কুইকস্টার্ট ম্যানেজমেন্ট, সিগন্যাল এবং রিলে সার্ভিসগুলোকে একটি VPS-এ একসাথে চালু করে দেয়।

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

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

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

আপনার নেটওয়ার্কের গঠন সম্পর্কে কাদের জানার অনুমতি আছে তা নির্ধারণ করুন। যদি বাইরের কোনো কোম্পানিকে বাদ দিতে হয়, অথবা ব্যবহারকারীর সংখ্যার কারণে per seat billing ব্যয়বহুল মনে হয়, তবে Headscale চালান এবং মেনে নিন যে এখন থেকে আপনি নিজেই control server পরিচালনা করবেন। যদি billing-এর কারণেই এই পরিবর্তনের চিন্তা করেন, তবে চূড়ান্ত সিদ্ধান্তের আগে হিসাব করে দেখুন। কারণ আপনার দলের আকারের জন্য প্রকৃত খরচ কত হবে তা নির্ভর করে কতজন ব্যবহারকারীর অ্যাকাউন্ট আছে তার ওপর, কতগুলো মেশিন চলছে তার ওপর নয়; আর এই দুটি সংখ্যা সাধারণত কাছাকাছি থাকে না।

আপনি খুব সহজেই আপনার সিদ্ধান্ত পরিবর্তন করতে পারেন। যেহেতু এই তিনটির ক্ষেত্রেই data plane একই protocol ব্যবহার করে, তাই plain WireGuard থেকে coordinated mesh-এ যাওয়া মানে কেবল একটি client install করা, কোনো redesign নয়। একইভাবে, 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 অমিল যা কন্ট্রোল প্লেন থাকুক বা না থাকুক একইভাবে কাজ করে।