WireGuard، Tailscale یا Headscale: VPS کے لیے کون؟

WireGuard بمقابلہ Tailscale: مختصر جواب

WireGuard بمقابلہ Tailscale دو protocols کے درمیان انتخاب نہیں ہے، کیونکہ Tailscale خود WireGuard ہے۔ Tailscale وہی encryption اور وہی tunnel استعمال کرتا ہے، پھر اس میں ایک control plane شامل کرتا ہے: ایسا coordination server جو public keys کا تبادلہ کرتا ہے، addresses جاری کرتا ہے، NAT (network address translation) کے ذریعے رکاوٹیں عبور کرتا ہے، اور access policy نافذ کرتا ہے۔ آپ یہ طے کر رہے ہوتے ہیں کہ اس coordination کا کتنا حصہ خود چلانا ہے۔

اس کے تین واضح جواب ہیں۔ Plain WireGuard اس وقت چلائیں جب آپ کے پاس ایک server اور چند clients ہوں جو سب اسی سے connect ہوتے ہوں۔ Tailscale اس وقت چلائیں جب آپ چاہتے ہوں کہ ہر machine کسی configuration file کو maintain کیے بغیر ہر دوسری machine تک پہنچ سکے۔ Headscale اس وقت چلائیں جب آپ ایسا mesh چاہتے ہوں، لیکن یہ نہیں چاہتے کہ کسی third party کے پاس node list ہو۔

کنٹرول plane دراصل آپ کو کیا فراہم کرتا ہے

Plain WireGuard میں discovery موجود نہیں ہوتی۔ ہر peer متن کا ایک block ہوتا ہے جسے آپ دستی طور پر لکھتے ہیں: ایک public key، ایک AllowedIPs line، اور اگر وہ peer reachable ہو تو ایک Endpoint۔ دس machines والے network میں ایک machine شامل کرنے کا مطلب دس config files میں ترمیم کرنا ہے، کیونکہ ہر side کو دوسری side کی key درکار ہوتی ہے۔ اسی لیے تقریباً ہر self-hosted WireGuard setup hub and spoke ہوتا ہے: ایک public IP والا server، اور ایسے clients جو صرف اسی سے بات کرتے ہیں۔

Control plane اس manual editing کو ختم کرتا ہے۔ ہر node ایک بار register ہوتا ہے، 100.64.0.0/10 CGNAT (carrier grade NAT) range سے ایک address حاصل کرتا ہے، اور اسے ان nodes کی public keys دی جاتی ہیں جن تک اسے پہنچنے کی اجازت ہے۔ Tunnel اب بھی دو peers کے درمیان براہِ راست WireGuard ہوتا ہے، اور آپ کا traffic coordination server سے نہیں گزرتا۔ Server جو چیز منتقل کرتا ہے وہ metadata ہے: کون موجود ہے، کس کی key کون سی ہے، اور کون کس سے بات کر سکتا ہے۔

اس سے تین عملی فوائد حاصل ہوتے ہیں۔

NAT traversal

دو home routers کے پیچھے موجود دو laptops کے درمیان کوئی public IP نہیں ہوتا۔ Tailscale STUN (session traversal utilities for NAT) استعمال کرتا ہے تاکہ دونوں sides کا بیرونی address اور port معلوم کیا جا سکے۔ پھر دونوں sides ایک ہی وقت میں packets بھیجتی ہیں، تاکہ ہر router پہلے outgoing flow دیکھے اور reply قبول کرے۔ اگر یہ طریقہ ناکام ہو جائے تو traffic DERP relay پر منتقل ہو جاتا ہے، جو Tailscale کے زیر انتظام encrypted relay ہے۔ Relay کے ذریعے بھی آپ کا data end-to-end encrypted رہتا ہے، کیونکہ relay کے پاس keys نہیں ہوتیں۔ tailscale status چلائیں، اور ہر peer line میں direct یا relay لکھا ہوگا۔ tailscale netcheck چلانے سے معلوم ہوتا ہے کہ کون سا relay قریب ترین ہے اور آیا آپ کا network UDP کی اجازت دیتا ہے یا نہیں۔

Expiry کے ساتھ key rotation

WireGuard keys کبھی expire نہیں ہوتیں۔ تین سال پہلے جاری کی گئی key ہمیشہ کام کرتی رہے گی، جب تک آپ peer block کو دستی طور پر delete نہ کریں۔ اس کے برعکس Tailscale node keys کو expire کرتا ہے، اور October 2026 تک نئے tailnet میں default expiry period 180 days ہے۔ جو machine دوبارہ authenticate نہیں کرتی، وہ connect ہونا بند کر دیتی ہے۔ آپ کسی server یا subnet router کے لیے فی device expiry بند کر سکتے ہیں، جہاں login کرنے کے لیے کوئی موجود نہیں ہوگا۔

Routing کے بجائے policy

Plain WireGuard میں AllowedIPs routing table اور access control list دونوں کا کام کرتا ہے۔ اس لیے "alice may reach the database" کو IP range کے طور پر بیان کرنا پڑتا ہے۔ Tailscale ایک الگ policy file رکھتا ہے، جہاں rules users، groups اور tags کے نام استعمال کرتے ہیں۔ کوئی rule یہ کہہ سکتا ہے کہ tag:laptop کو tag:db تک port 5432 پر رسائی حاصل ہو، اور tag:db پر کسی دوسرے port تک نہیں، اور machine کو نیا address ملنے کے بعد بھی یہ rule برقرار رہتا ہے۔

آپ کے لیے control plane کی لاگت

Coordination server آپ کے network کو جانتا ہے۔ اس میں ہر node کی public key، ہر node کا نام، تفویض کیے گئے تمام addresses اور policy موجود ہوتی ہے۔ Hosted Tailscale میں یہ آپ کے control سے باہر ایک کمپنی کے پاس ہوتا ہے۔ وہ آپ کے packets کو پڑھ نہیں سکتی، کیونکہ WireGuard کی private keys آپ کی اپنی machines پر رہتی ہیں۔ لیکن آپ کے network کا نقشہ اسے نظر آتا ہے۔ مزید یہ کہ آپ کا connect ہونا اس service کے دستیاب ہونے اور آپ کے account کے درست حالت میں رہنے پر منحصر ہوتا ہے۔ اس بات کی اہمیت کا انحصار اس پر ہے کہ compromised coordination server یا چوری شدہ identity account، اپنے پاس موجود معلومات سے حقیقتاً کیا کر سکتا ہے۔ اسی لیے Tailscale کے trust model کی مکمل تفصیل پڑھنا مفید ہے۔

ایک دوسری لاگت بھی ہے جسے نظرانداز کرنا آسان ہے۔ Tailscale ہر machine پر ایک daemon ہے، اس لیے اب آپ کو ہر machine پر اس software کو patched رکھنا ہوگا۔ Ubuntu 24.04 پر plain WireGuard ایک kernel module ہے جو distribution کے ساتھ شامل ہوتا ہے اور kernel کے ساتھ update ہوتا ہے۔

تیسری لاگت billing ہے۔ October 2026 تک Personal plan، 6 users تک unlimited user devices کے ساتھ free ہے؛ Standard کی قیمت $8 فی user فی ماہ ہے؛ اور Premium کی قیمت $18 فی user فی ماہ ہے۔ ایک household free رہتا ہے۔ دس افراد کی team free نہیں رہتی۔ آپ اس حد سے آگے بڑھتے ہیں یا نہیں، یہ زیادہ تر seats کے بجائے devices کی تعداد کا سوال ہے، تاہم ایک استثنا موجود ہے: servers اور دیگر tagged devices کے لیے الگ allowance ہوتا ہے۔ ہر plan میں 50 tagged resources شامل ہیں، اور October 2026 تک pricing page ہر اضافی resource کے لیے $1 فی ماہ درج کرتی ہے۔ ساتویں user کو invite کرنے یا اکاون پچاسویں server کو tag کرنے سے پہلے free plan میں حقیقتاً کیا شامل ہے پڑھ لینا مفید ہے۔

جب plain WireGuard درست انتخاب ہو

plain WireGuard اس وقت منتخب کریں جب topology واقعی hub and spoke ہو۔ ایک VPS جس کے پاس public IP ہو، تین یا چار devices جو اس سے connect ہوں، اور ان devices کے درمیان باہمی رسائی کی ضرورت نہ ہو۔ configuration ایک screen پر آ جاتی ہے، update کرنے کے لیے کوئی daemon نہیں ہوتا، کھونے کے لیے کوئی account نہیں ہوتا، اور آپ کے server اور بیرونی service کے درمیان کوئی واسطہ نہیں ہوتا۔

یہ اس وقت بھی درست انتخاب ہے جب آپ اس بنیادی layer کو سمجھنا چاہتے ہوں جس پر باقی سب کچھ قائم ہے۔ VPS پر WireGuard VPN کی self-hosting میں key generation، wg0.conf، IP forwarding، NAT اور handshake failures کی وضاحت کی گئی ہے۔ ہر tailnet کے نیچے بھی keys اور handshake ہی کام کر رہے ہوتے ہیں، اور جب tailnet node subnet router یا exit node کا کردار ادا کرتا ہے تو IP forwarding دوبارہ اہم ہو جاتی ہے۔ اگر آپ اب بھی پرانے اختیار پر غور کر رہے ہیں تو WireGuard بمقابلہ OpenVPN ان چار صورتوں کی وضاحت کرتا ہے جن میں OpenVPN کو برتری حاصل رہتی ہے۔

تنصیب مختصر ہے:

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

plain WireGuard اس وقت مشکل بن جاتا ہے جب ہر device کو ہر دوسرے device تک رسائی درکار ہو۔ N nodes کا full mesh، N times N minus one peer blocks کا تقاضا کرتا ہے۔ چھ devices پر یہ تیس blocks بنتے ہیں جنہیں دستی طور پر ہم آہنگ رکھنا پڑتا ہے، اور duplicate AllowedIPs entry خاموشی سے اس peer کا traffic اپنے قبضے میں لے لیتی ہے جس کے پاس وہ پہلے موجود تھی؛ کہیں بھی کوئی error ظاہر نہیں ہوتی۔

Tailscale کا انتخاب کب درست ہے

Tailscale اس وقت منتخب کریں جب مشینیں مختلف نیٹ ورکس پر منتقل ہوتی رہتی ہوں۔ ہوٹل کے نیٹ ورک پر موجود laptops، mobile data استعمال کرنے والا phone، یا ایسے router کے پیچھے موجود home server جس پر آپ کا کنٹرول نہیں ہے۔ یہ بالکل وہ صورتیں ہیں جنہیں plain WireGuard مؤثر طور پر handle نہیں کرتا، کیونکہ کسی بھی جانب ایسا مستحکم public endpoint موجود نہیں ہوتا جسے Endpoint میں درج کیا جا سکے۔

Client install کرنے کے لیے official installer کی ایک command کافی ہے:

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

tailscale up ایک URL دکھاتا ہے۔ اسے کھولیں، log in کریں، اور machine network میں شامل ہو جائے گی۔ Copy کرنے کے لیے کسی key کی ضرورت نہیں ہوتی اور inbound port کھولنے کی بھی ضرورت نہیں ہوتی، کیونکہ daemon coordination server سے outbound connection بناتا ہے اور اسے برقرار رکھتا ہے۔ اسی وجہ سے Tailscale node ایسے network پر بھی کام کرتا ہے جہاں کسی firewall پر آپ کا کوئی کنٹرول نہیں ہوتا۔

اس کے بعد دو settings زیادہ تر مفید کام انجام دیتی ہیں۔ 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

Route اس وقت تک inactive رہتا ہے جب تک آپ اسے admin console میں approve نہ کر دیں۔ یہ جان بوجھ کر ایسا رکھا گیا ہے: کوئی node خود سے آپ کے network میں route inject نہیں کر سکتا۔ Linux clients کو sudo tailscale set --accept-routes بھی درکار ہوتا ہے، کیونکہ Linux بطور default advertised routes قبول نہیں کرتا۔ اس لیے server side پر approved نظر آنے والا route بھی Linux laptop پر اس وقت تک کوئی اثر نہیں ڈالتا جب تک آپ یہ setting configure نہ کریں۔ اگر آپ کو یہی setup درکار ہے تو VPS پر subnet router چلانا approval step اور forwarding settings کو اس ترتیب سے بیان کرتا ہے جس سے half-working route سے بچا جا سکے۔

Exit node client کی عام internet traffic، یعنی وہ تمام traffic جو پہلے سے کسی دوسرے tailnet device یا approved subnet route کی طرف نہیں جا رہی، ایک machine کے ذریعے بھیجتا ہے۔ یہی full tunnel behaviour ہے جس سے عموماً "VPN" مراد لیا جاتا ہے۔ Linux پر اسے advertise کرنے سے پہلے اوپر دکھائی گئی وہی IP forwarding settings درکار ہوتی ہیں:

sudo tailscale set --advertise-exit-node

یہ flag آسان حصہ ہے، جبکہ VPS کو exit node میں تبدیل کرنا اس کے بعد کے مراحل بیان کرتا ہے: admin console میں route approve کرنا، پھر DNS اور IPv6 behaviour درست کرنا، ورنہ traffic غلط راستے سے باہر جا سکتی ہے۔ اگر آپ کو پورے network کے بجائے صرف ایک web service تک رسائی دینی ہے تو serve اور funnel اس کے بجائے ایک single local port کے سامنے HTTPS رکھتا ہے، خواہ رسائی صرف tailnet تک محدود ہو یا public internet کے لیے کھلی ہو۔

جب Headscale موزوں انتخاب ہے

Headscale coordination server کا open source implementation ہے، اور یہ آپ کے زیرِ ملکیت VPS پر چلتا ہے۔ سرکاری Tailscale clients hosted service کے بجائے اسی کی طرف connect ہوتے ہیں:

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

Data path کے بارے میں سب کچھ تبدیل نہیں ہوتا۔ یہ اب بھی WireGuard ہی ہے، اور جہاں network اجازت دے وہاں peers کے درمیان براہِ راست رابطہ برقرار رہتا ہے۔ تبدیلی صرف یہ ہے کہ node list، keys اور policy آپ کی اپنی disk پر موجود SQLite file میں رہتے ہیں۔ بیرونی کوئی فریق آپ کے network کی ساخت نہیں دیکھ سکتا، آپ کا account disable نہیں کر سکتا، اور آپ سے فی user billing نہیں کر سکتا۔

اس کے بدلے حقیقی انتظامی کام کرنا پڑتا ہے۔ اب آپ ایک public HTTPS service چلا رہے ہیں، جس کے لیے DNS name، certificate اور ایسا reverse proxy درکار ہے جو WebSocket upgrades کو درست طور پر forward کرے۔ اس کی uptime کی ذمہ داری آپ کی ہے، اور اگر coordination server down ہو تو نئے nodes register نہیں ہو سکتے اور موجودہ nodes تبدیلیوں سے آگاہ نہیں ہو سکتے۔ Headscale ابھی version 1.0 سے کم ہے، اور اس کی minor releases میں breaking changes آتی رہی ہیں، اس لیے ہر upgrade سے پہلے changelog پڑھیں۔ Headscale کو اپنا Tailscale control server چلانے کا طریقہ میں install، config.yaml، preauth keys اور کھولنے کے لیے درکار ports کا احاطہ کیا گیا ہے۔

ایک اہم احتیاط اکثر دیر سے معلوم ہوتی ہے۔ Headscale میں Tailscale کا global relay network شامل نہیں ہے۔ جہاں دو peers براہِ راست connect نہیں ہو سکتے، وہاں آپ کو اپنے server پر embedded relay enable کرنا ہوگا یا config کو کسی دوسرے relay کی طرف point کرنا ہوگا۔ یہ relay ایک ہی region میں موجود ایک single box ہوتا ہے، دنیا بھر میں پھیلا ہوا fleet نہیں۔ دنیا کے دوسرے سرے پر موجود peers اس فرق کو محسوس کرتے ہیں۔ اگر آپ یہ حصہ خود تیار نہیں کرنا چاہتے تو NetBird کو self-host کرنے کا طریقہ control plane کو اپنے infrastructure میں رکھنے کا دوسرا راستہ ہے، کیونکہ اس کا quickstart management، signal اور relay services کو ایک ہی VPS پر ساتھ چلا دیتا ہے۔ تاہم NetBird، Headscale کی طرح drop-in Tailscale server نہیں ہے۔ یہ اپنے clients اور اپنا policy model فراہم کرتا ہے، اس لیے Headscale کے بجائے اسے منتخب کرنے سے پہلے access rules اور relays کے معاملے میں NetBird اور Tailscale کا فرق پڑھیں۔

ایک ہی مرحلے میں فیصلہ کیسے کریں

پوچھیں کہ کتنی مشینوں کو ایک دوسرے تک پہنچنا ضروری ہے۔ اگر جواب یہ ہے کہ تمام مشینیں صرف سرور سے رابطہ کرتی ہیں، تو اسی نتیجے کے لیے plain WireGuard میں کم سافٹ ویئر درکار ہوگا۔

پوچھیں کہ آیا مشینوں کے public addresses مستحکم ہیں۔ اگر زیادہ تر مشینیں ایسے NAT کے پیچھے ہیں جسے آپ کنٹرول نہیں کرتے، تو آپ کو control plane درکار ہوگا، کیونکہ hole punching مشکل حصہ ہے اور اسے دوبارہ بنانا قابلِ قدر کام نہیں۔

پوچھیں کہ آپ کے network کی ساخت کے بارے میں جاننے کی اجازت کس کو ہے۔ اگر جواب میں بیرونی کمپنیوں کی اجازت شامل نہیں، یا users کی تعداد کے باعث per-seat billing ناقابلِ برداشت ہو جاتی ہے، تو Headscale چلائیں اور یہ تسلیم کریں کہ اب control server آپ کو خود operate کرنا ہوگا۔ اگر فیصلہ billing کے دباؤ کی وجہ سے ہو رہا ہے، تو migration کا عہد کرنے سے پہلے حساب کر لیں، کیونکہ آپ کی ٹیم کے سائز کے لحاظ سے اصل ادائیگی زیادہ تر اس بات پر منحصر ہوتی ہے کہ کتنے لوگوں کے accounts ہیں، نہ کہ آپ کتنی مشینیں چلاتے ہیں؛ یہ صورت اس وقت تک رہتی ہے جب تک آپ کے tagged servers ہر plan میں شامل 50 سے زیادہ نہ ہو جائیں، اور یہ دونوں اعداد عموماً قریب نہیں ہوتے۔

آپ اپنا فیصلہ کم لاگت پر بدل سکتے ہیں۔ تینوں صورتوں میں data plane ایک ہی protocol ہے، اس لیے plain WireGuard سے coordinated mesh کی طرف منتقلی redesign کے بجائے client install کا کام ہے۔ اسی طرح Tailscale سے Headscale کی طرف منتقلی میں ہر node کو مختلف login server کے خلاف دوبارہ register کرنا ہوتا ہے۔

تینوں میں سے کوئی بھی آپ کو کیا فراہم نہیں کرتا

ان میں سے کوئی بھی firewall نہیں ہے۔ tunnel یہ طے کرتا ہے کہ کون سے packets منتقل کیے جائیں، یہ نہیں کہ کون سی services listen کریں۔ tunnel کے ذریعے قابل رسائی server internet سے اب بھی ان تمام ports پر قابل رسائی رہتا ہے جو آپ نے کھلے چھوڑے ہیں، اس لیے VPS پر UFW firewall rules برقرار رکھیں تاکہ وہ اپنا کام کرتے رہیں۔ Tailscale کی policy file یہ محدود کرتی ہے کہ دوسرے nodes کن وسائل تک پہنچ سکتے ہیں، لیکن یہ public interface کے بارے میں کچھ نہیں کرتی۔

ان میں سے کوئی بھی ہر service کے لیے authentication فراہم نہیں کرتا، اور connected ہونے کے بعد user نے کیا کیا، اس کا audit trail بھی کوئی نہیں دیتا۔ تینوں کو transport سمجھیں، اور login checks application میں رکھیں۔

FAQ

کیا Tailscale اضافی مراحل کے ساتھ صرف WireGuard ہے؟

Tailscale ڈیٹا path کے لیے WireGuard protocol استعمال کرتا ہے، اس لیے encryption اور tunnel ایک جیسے ہیں۔ یہ coordination شامل کرتا ہے: key exchange، address assignment، STUN اور DERP relays کے ذریعے NAT traversal، key expiry، اور ایسی policy file جو IP ranges کے بجائے users کے نام استعمال کرتی ہے۔ Plain WireGuard میں یہ کام آپ کو خود کرنے پڑتے ہیں۔ مختلف networks کے درمیان machines منتقل ہونے پر یہی کام مشکل ہو جاتے ہیں۔

کیا میرا traffic Tailscale کے servers سے گزرتا ہے؟

عام طور پر نہیں۔ Coordination server کے peers کو متعارف کرانے کے بعد peers براہ راست ایک دوسرے سے connect کرتے ہیں، اور tailscale status ان peer lines پر direct دکھاتا ہے۔ جب direct path قائم نہ ہو سکے تو traffic DERP relay پر منتقل ہو جاتا ہے اور line میں relay لکھا ہوتا ہے۔ اس صورت میں بھی relay encrypted packets منتقل کرتا ہے اور آپ کی WireGuard private keys اس کے پاس نہیں ہوتیں، اس لیے وہ contents نہیں پڑھ سکتا۔ یہ دیکھنے کے لیے tailscale netcheck چلائیں کہ آیا آپ کا network direct connections کے لیے درکار UDP کو block کر رہا ہے۔

کیا میں official Tailscale apps کے ساتھ Headscale استعمال کر سکتا ہوں؟

ہاں۔ Headscale وہی control protocol بولتا ہے، اس لیے official clients sudo tailscale up --login-server https://headscale.example.com کے ساتھ join کرتے ہیں۔ Desktop اور mobile apps کو custom login server پر بھی point کیا جا سکتا ہے، تاہم ہر platform پر یہ setting مختلف جگہ موجود ہوتی ہے، اور مخصوص version کی ضرورت mobile apps کو زیادہ پڑ سکتی ہے۔ پورے network کو migrate کرنے سے پہلے ایک phone پر test کریں۔

کیا Tailscale یا Headscale کے لیے ports کھولنا اب بھی ضروری ہے؟

Tailscale client کو کسی inbound port کی ضرورت نہیں ہوتی، کیونکہ وہ coordination server سے outbound connection بناتا ہے اور اسے کھلا رکھتا ہے۔ Self-hosted Headscale server کے لیے inbound ports درکار ہوتے ہیں: control protocol کے لیے 443، HTTP-01 certificate challenge استعمال کرنے کی صورت میں 80، اور embedded relay enable کرنے پر صرف 3478/udp۔ Plain WireGuard کے لیے اس کا UDP listen port، عموماً 51820، server پر اور provider کے زیرانتظام کسی الگ network firewall پر کھلا ہونا چاہیے۔

ان تینوں میں سب سے تیز کون سا ہے؟

Throughput یکساں ہوتا ہے، کیونکہ تینوں WireGuard کے ذریعے packets منتقل کرتے ہیں۔ فرق connection setup اور path quality میں ظاہر ہوتا ہے۔ درست Endpoint کے ساتھ Plain WireGuard ہر بار براہ راست connect ہوتا ہے۔ Tailscale اور Headscale زیادہ تر وقت براہ راست connect ہوتے ہیں، لیکن جب network hole punching کو block کرتا ہے تو relay پر منتقل ہو جاتے ہیں، اور relayed path latency بڑھا دیتا ہے۔ اپنے path کی پیمائش tailscale ping <node> سے کریں، جو بتاتا ہے کہ route direct ہے یا relayed، یا tunnel کے ذریعے iperf3 استعمال کریں۔ اگر direct path پر یہ number آپ کی line rate سے بہت کم آئے تو مسئلہ ان تینوں میں سے انتخاب نہیں ہے۔ عام وجہ path MTU mismatch ہے، جو control plane کے ساتھ یا اس کے بغیر یکساں طور پر اثر انداز ہوتا ہے۔