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 ہو۔

کنٹرول پلین آپ کو عملی طور پر کیا فراہم کرتا ہے

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

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

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

NAT traversal۔ دو home routers کے پیچھے موجود دو laptops کے درمیان کوئی public IP نہیں ہوتا۔ Tailscale STUN (session traversal utilities for NAT) استعمال کرتا ہے تاکہ دونوں جانب کا بیرونی address اور port معلوم کیا جا سکے۔ پھر دونوں جانب ایک ہی وقت میں 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 کو خود حذف نہ کر دیں۔ اس کے برعکس Tailscale node keys کو expire کرتا ہے، اور July 2026 تک نئے tailnet میں default expiry period 180 days ہے۔ جو machine دوبارہ authenticate نہیں کرتی، وہ 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 رکھتا ہے، جہاں rules users، groups اور tags کے نام استعمال کرتے ہیں۔ کوئی rule یہ بیان کر سکتا ہے کہ tag:laptop کو port 5432 پر tag:db تک رسائی حاصل ہو، مگر کسی اور چیز تک نہیں، اور machine کو نیا address ملنے کے بعد بھی یہ rule برقرار رہتا ہے۔

کنٹرول plane کی آپ کے لیے لاگت

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

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

تیسری لاگت billing ہے۔ July 2026 تک Personal plan مفت ہے اور اس میں زیادہ سے زیادہ 6 users کے لیے unlimited devices شامل ہیں۔ Standard کی قیمت $8 فی user فی ماہ ہے، جبکہ Premium کی قیمت $18 فی user فی ماہ ہے۔ ایک household مفت رہتا ہے۔ 10 افراد کی team مفت نہیں رہتی۔ یہ حد عبور ہوتی ہے یا نہیں، اس کا تعلق devices کے بجائے seats سے ہے۔ ساتویں user کو invite کرنے سے پہلے یہ پڑھنا مفید ہے کہ free plan میں حقیقتاً کیا شامل ہے۔

جب سادہ WireGuard موزوں انتخاب ہے

سادہ 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 کی وضاحت کی گئی ہے۔ یہ تمام mechanisms tailnet کے نیچے بھی کام کر رہے ہوتے ہیں۔ اگر آپ اب بھی پرانے option پر غور کر رہے ہیں تو WireGuard بمقابلہ OpenVPN میں ان چار صورتوں کا احاطہ کیا گیا ہے جہاں OpenVPN کو اب بھی برتری حاصل ہے۔

Installation مختصر ہے:

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

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

جب Tailscale درست انتخاب ہو

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

official installer سے client install کرنے کے لیے ایک command چلائیں:

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

tailscale up ایک URL دکھاتا ہے۔ اسے کھولیں، login کریں، اور مشین network میں شامل ہو جاتی ہے۔ کسی key کو copy کرنے یا inbound port کھولنے کی ضرورت نہیں، کیونکہ daemon coordination server سے outbound connection بناتا ہے اور اسے کھلا رکھتا ہے۔ اسی وجہ سے Tailscale node ایسے network پر بھی کام کرتا ہے جہاں آپ کسی firewall کو بالکل control نہیں کرتے۔

اس کے بعد زیادہ تر مفید کام دو 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 advertised routes کو default طور پر قبول نہیں کرتا۔ اس لیے server side پر approved نظر آنے والا route بھی Linux laptop پر اس وقت تک کچھ نہیں کرتا جب تک آپ یہ setting نہ کریں۔ اگر آپ کو یہی configuration چاہیے تو VPS پر subnet router چلانا approval step اور forwarding settings کو اس ترتیب سے بیان کرتا ہے جس سے half-working route سے بچا جا سکے۔

exit node کسی client کا تمام traffic ایک مشین کے ذریعے بھیجتا ہے۔ عموماً "VPN" سے مراد یہی full tunnel behaviour ہوتا ہے:

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 پر چلتی ہے۔ Official Tailscale clients hosted service کے بجائے اسی کی طرف connect ہوتے ہیں:

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

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

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

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

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

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

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

معلوم کریں کہ آپ کے network کی ساخت کے بارے میں جاننے کی اجازت کس کو ہے۔ اگر جواب میں بیرونی کمپنیاں شامل نہ ہوں، یا صارفین کی تعداد کے باعث per seat billing مہنگی پڑے، تو Headscale چلائیں اور یہ ذمہ داری قبول کریں کہ اب control server آپ کو خود operate کرنا ہوگا۔ اگر فیصلہ billing کے دباؤ کی وجہ سے ہو رہا ہے، تو migration کا عہد کرنے سے پہلے حساب کر لیں، کیونکہ آپ کی ٹیم کے سائز کے لیے اصل لاگت اس بات پر منحصر ہوتی ہے کہ کتنے افراد کے accounts ہیں، نہ کہ آپ کتنی مشینیں چلاتے ہیں، اور یہ دونوں تعدادیں شاذ ہی قریب ہوتی ہیں۔

آپ کم لاگت کے ساتھ اپنا فیصلہ تبدیل کر سکتے ہیں۔ چونکہ تینوں صورتوں میں 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 کے ساتھ یا اس کے بغیر یکساں طور پر اثر انداز ہوتا ہے۔