WireGuard، Tailscale یا Headscale: VPS کے لیے کیا بہتر ہے؟
Tailscale، WireGuard کے ساتھ control plane فراہم کرتا ہے۔ جانیں coordination server کیا دیتا ہے، اس کی قیمت کیا ہے، اور VPS کے لیے WireGuard، Tailscale یا Headscale میں سے کیا چنیں۔
WireGuard بمقابلہ Tailscale: مختصر جواب
WireGuard بمقابلہ Tailscale کا انتخاب دو پروٹوکولز کے درمیان انتخاب نہیں ہے، کیونکہ Tailscale خود WireGuard ہے۔ Tailscale وہی encryption اور وہی tunnel استعمال کرتا ہے، پھر اس میں ایک control plane شامل کرتا ہے: ایسا coordination server جو public keys کا تبادلہ کرتا ہے، addresses فراہم کرتا ہے، NAT (network address translation) کے ذریعے راستے بناتا ہے، اور access policy نافذ کرتا ہے۔ آپ دراصل یہ منتخب کر رہے ہیں کہ اس coordination کا کتنا حصہ خود چلانا چاہتے ہیں۔
اس کے تین واضح جواب ہیں۔ جب آپ کے پاس ایک server اور چند clients ہوں جو سب اسی server سے connect ہوتے ہوں، تو plain WireGuard چلائیں۔ جب آپ چاہتے ہوں کہ ہر machine کسی بھی دوسری machine تک پہنچ سکے اور کوئی config file برقرار نہ رکھنی پڑے، تو Tailscale چلائیں۔ جب آپ یہی mesh چاہتے ہوں لیکن کسی third party کو node list نہیں دینا چاہتے ہوں، تو Headscale چلائیں۔
کنٹرول پلین دراصل آپ کو کیا فراہم کرتا ہے
سادہ WireGuard میں دریافت کی سہولت نہیں ہوتی۔ ہر peer متن کا ایک حصہ ہوتا ہے جسے آپ دستی طور پر لکھتے ہیں: ایک public key، ایک AllowedIPs لائن، اور اگر وہ peer قابلِ رسائی ہو تو ایک Endpoint۔ دس machines کے network میں ایک machine شامل کرنے کا مطلب دس config files میں ترمیم کرنا ہے، کیونکہ ہر طرف کو دوسری طرف کی key درکار ہوتی ہے۔ اسی لیے تقریباً ہر self-hosted WireGuard setup hub-and-spoke ہوتا ہے: ایک public IP والا server، اور ایسے clients جو صرف اسی سے رابطہ کرتے ہیں۔
کنٹرول پلین دستی ترمیم کی ضرورت ختم کر دیتا ہے۔ ہر node ایک بار register ہوتا ہے، اسے 100.64.0.0/10 CGNAT (carrier grade NAT) range سے ایک address ملتا ہے، اور اسے ان nodes کی public keys دی جاتی ہیں جن تک اسے پہنچنے کی اجازت ہے۔ Tunnel اب بھی دو peers کے درمیان براہِ راست WireGuard connection ہوتا ہے، اور آپ کا 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 ہے۔ آپ کا data relay کے ذریعے بھی end-to-end encrypted رہتا ہے، کیونکہ relay کے پاس keys نہیں ہوتیں۔ tailscale status چلائیں؛ ہر peer line میں direct یا relay لکھا ہوگا۔ tailscale netcheck چلانے سے معلوم ہوتا ہے کہ کون سا relay قریب ترین ہے اور آیا آپ کا network UDP کی اجازت دیتا ہے۔
اختتام کی مدت کے ساتھ key rotation۔ WireGuard keys کبھی expire نہیں ہوتیں۔ تین سال پہلے جاری کی گئی key ہمیشہ کام کرتی رہے گی، جب تک آپ peer block کو دستی طور پر حذف نہ کریں۔ اس کے برعکس Tailscale node keys کو expire کرتا ہے۔ July 2026 تک، نئے tailnet کے لیے default expiry period 180 days ہے۔ جو machine دوبارہ authenticate نہیں کرتی، وہ connection بنانا بند کر دیتی ہے۔ آپ server یا subnet router کے لیے ہر device پر expiry بند کر سکتے ہیں، اگر وہاں login کرنے کے لیے کوئی موجود نہیں ہوگا۔
Routing کے بجائے policy۔ سادہ WireGuard میں AllowedIPs routing table اور access control list دونوں کا کام کرتا ہے۔ اس لیے "alice database تک پہنچ سکتی ہے" کو IP range کی صورت میں بیان کرنا پڑتا ہے۔ Tailscale ایک الگ policy file رکھتا ہے، جس میں rules users، groups اور tags کے نام استعمال کرتے ہیں۔ کوئی rule یہ کہہ سکتا ہے کہ tag:laptop کو port 5432 پر tag:db تک رسائی حاصل ہو، اور کسی اور چیز تک نہیں۔ یہ rule اس وقت بھی برقرار رہتا ہے جب machine کو نیا address مل جائے۔
کنٹرول پلین کی لاگت
کوآرڈینیشن سرور آپ کے نیٹ ورک کو جانتا ہے۔ اس میں ہر نوڈ کی public key، ہر نوڈ کا نام، تفویض کردہ تمام پتے، اور پالیسی محفوظ ہوتی ہے۔ Hosted Tailscale استعمال کرنے کی صورت میں یہ سرور آپ کے کنٹرول سے باہر ایک کمپنی کے پاس ہوتا ہے۔ وہ آپ کے packets کو پڑھ نہیں سکتی، کیونکہ WireGuard کی private keys آپ کی مشینوں پر ہی رہتی ہیں۔ لیکن آپ کے نیٹ ورک کا ڈھانچہ اسے دکھائی دیتا ہے، اور آپ کا کنکشن قائم کرنے کا اختیار اس بات پر منحصر ہوتا ہے کہ اس کی سروس دستیاب ہو اور آپ کا account درست حالت میں ہو۔
ایک دوسری لاگت بھی ہے جسے نظرانداز کرنا آسان ہے۔ Tailscale ہر مشین پر ایک daemon ہوتا ہے، اس لیے اب آپ کو ہر مشین پر اس software کو patches کے ساتھ اپ ڈیٹ رکھنا ہوگا۔ Ubuntu 24.04 پر Plain WireGuard ایک kernel module ہے جو distribution کے ساتھ جاری ہوتا ہے اور kernel کے ساتھ اپ ڈیٹ ہوتا ہے۔
تیسری لاگت billing ہے۔ July 2026 تک Personal plan مفت ہے اور اس میں 6 صارفین تک unlimited devices شامل ہیں، Standard کی قیمت $8 فی صارف فی ماہ ہے، اور Premium کی قیمت $18 فی صارف فی ماہ ہے۔ ایک گھرانہ مفت رہتا ہے۔ 10 افراد کی ٹیم مفت نہیں رہتی۔
plain WireGuard موزوں انتخاب کب ہے
plain WireGuard اس وقت منتخب کریں جب نیٹ ورک کی ساخت واقعی hub and spoke ہو۔ ایک VPS جس کے پاس public IP ہو، اور تین یا چار devices جو اس سے connect ہوں، جبکہ ان devices کا ایک دوسرے تک پہنچنا ضروری نہ ہو۔ config ایک 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 کو اب بھی برتری حاصل ہے۔
تنصیب مختصر ہے:
sudo apt update && sudo apt install -y wireguard
sudo modprobe wireguard && echo okplain WireGuard اس وقت مشکل بن جاتا ہے جب ہر device کو ہر دوسرے device تک پہنچنا ضروری ہو۔ N nodes کا full mesh بنانے کے لیے N times N minus one peer blocks درکار ہوتے ہیں۔ چھ devices پر یہ تیس blocks بنتے ہیں جنہیں ہاتھ سے sync رکھنا پڑتا ہے۔ اگر AllowedIPs entry duplicate ہو جائے تو وہ خاموشی سے اس peer کا network traffic اپنے طرف لے لیتی ہے جس کے پاس وہ پہلے موجود تھی، اور کہیں بھی کوئی error ظاہر نہیں ہوتا۔
Tailscale کب درست انتخاب ہے
جب مشینیں مختلف نیٹ ورکس پر منتقل ہوتی رہیں تو Tailscale منتخب کریں۔ ہوٹل کے نیٹ ورکس پر موجود لیپ ٹاپ، mobile data استعمال کرنے والا فون، یا ایسے router کے پیچھے موجود home server جسے آپ کنٹرول نہیں کرتے۔ یہ بالکل وہ صورتیں ہیں جنہیں سادہ WireGuard مؤثر طریقے سے نہیں سنبھالتا، کیونکہ کسی بھی جانب مستحکم public endpoint موجود نہیں ہوتا جسے Endpoint میں درج کیا جا سکے۔
client انسٹال کرنے کے لیے official installer سے ایک command چلائیں:
curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up
tailscale statustailscale up ایک URL دکھاتا ہے۔ اسے کھولیں، sign in کریں، اور مشین network میں شامل ہو جاتی ہے۔ کسی key کو نقل کرنے یا inbound port کھولنے کی ضرورت نہیں ہوتی، کیونکہ daemon coordination server سے outbound connection بناتا ہے اور اسے برقرار رکھتا ہے۔ اسی وجہ سے Tailscale node ایسے network پر بھی کام کرتا ہے جہاں آپ کسی firewall کو بالکل کنٹرول نہیں کرتے۔
اس کے بعد دو settings زیادہ تر مفید کام انجام دیتی ہیں۔ subnet router پورے LAN کو network میں advertise کرتا ہے، اس لیے آپ کو ہر device پر client انسٹال نہیں کرنا پڑتا:
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 کو approve نہ کریں، یہ inactive رہتا ہے۔ یہ دانستہ حفاظتی طریقہ ہے: کوئی node اپنی طرف سے آپ کے network میں route شامل نہیں کر سکتا۔ Linux clients کو sudo tailscale set --accept-routes کی بھی ضرورت ہوتی ہے، کیونکہ Linux بطور default advertised routes قبول نہیں کرتا۔ اس لیے server side پر approved نظر آنے والا route بھی Linux laptop پر اس وقت تک کوئی اثر نہیں دکھاتا جب تک آپ یہ setting نہ کریں۔
exit node client کے تمام traffic کو ایک مشین کے ذریعے بھیجتا ہے۔ لوگ عموماً "VPN" سے full tunnel کے اسی رویے کو مراد لیتے ہیں:
sudo tailscale set --advertise-exit-nodeجب Headscale درست انتخاب ہے
Headscale، coordination server کا ایک open source implementation ہے، اور یہ آپ کے اپنے VPS پر چلتا ہے۔ سرکاری Tailscale clients hosted service کے بجائے اسے استعمال کرتے ہیں:
sudo tailscale up --login-server https://headscale.example.comData path میں کوئی تبدیلی نہیں آتی۔ یہ اب بھی WireGuard ہے، اور جہاں network اجازت دے وہاں peers کے درمیان براہِ راست کنکشن قائم ہوتا ہے۔ تبدیلی صرف یہ ہے کہ node list، keys اور policy آپ کی ملکیت والی disk پر موجود SQLite file میں رہتے ہیں۔ باہر کا کوئی شخص آپ کے network کی ساخت نہیں دیکھ سکتا، آپ کا account disable نہیں کر سکتا، اور آپ سے فی user بل وصول نہیں کر سکتا۔
اس کے بدلے میں حقیقی انتظامی کام درکار ہوتا ہے۔ اب آپ ایک public HTTPS service چلا رہے ہیں، جس کے لیے DNS name، certificate اور ایسا reverse proxy درکار ہے جو WebSocket upgrades کو درست طور پر آگے بھیجے۔ اس کی uptime کی ذمہ داری آپ کی ہے۔ اگر coordination server بند ہو تو نئے 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 کرنا ہوگا یا config کو کسی دوسرے relay کی طرف point کرنا ہوگا۔ یہ relay ایک ہی region میں موجود ایک single box ہوتا ہے، دنیا بھر میں پھیلا ہوا fleet نہیں۔ دنیا کے دوسری جانب موجود peers پر اس فرق کا اثر محسوس ہوتا ہے۔
ایک ہی مرحلے میں فیصلہ کیسے کریں
پوچھیں کہ کتنی مشینوں کو ایک دوسرے تک رسائی درکار ہے۔ اگر جواب یہ ہے کہ سب مشینیں صرف سرور سے رابطہ کرتی ہیں، تو اسی نتیجے کے لیے plain WireGuard کم سافٹ ویئر استعمال کرتا ہے۔
پوچھیں کہ آیا مشینوں کے public addresses مستحکم ہیں۔ اگر ان میں سے زیادہ تر ایسے NAT کے پیچھے ہیں جسے آپ کنٹرول نہیں کرتے، تو آپ کو control plane درکار ہے، کیونکہ hole punching مشکل حصہ ہے اور اسے دوبارہ بنانا فائدہ مند نہیں۔
پوچھیں کہ آپ کے network کی ساخت جاننے کی اجازت کس کو ہے۔ اگر جواب میں بیرونی کمپنیوں کو شامل نہیں کیا جاتا، یا صارفین کی تعداد کے باعث فی صارف billing مشکل ہو جاتی ہے، تو Headscale چلائیں اور یہ ذمہ داری قبول کریں کہ اب آپ control server خود چلا رہے ہیں۔
آپ اپنا فیصلہ کم لاگت کے ساتھ بدل سکتے ہیں۔ چونکہ تینوں صورتوں میں data plane ایک ہی protocol ہے، اس لیے plain WireGuard سے coordinated mesh کی طرف منتقلی redesign کے بجائے client install کا معاملہ ہے، اور Tailscale سے Headscale کی طرف منتقلی میں ہر node کو ایک مختلف login server کے ساتھ دوبارہ register کرنا ہوتا ہے۔
یہ تینوں آپ کو کیا فراہم نہیں کرتے
ان میں سے کوئی بھی firewall نہیں ہے۔ Tunnel یہ طے کرتا ہے کہ کون سے packets منتقل کیے جائیں، یہ نہیں کہ کون سی services listen کریں۔ Tunnel کے ذریعے قابل رسائی server ان تمام ports پر internet سے بھی قابل رسائی رہتا ہے جو آپ نے کھلے چھوڑے ہیں۔ اس لیے VPS پر موجود UFW firewall rules برقرار رکھیں تاکہ وہ اپنا کام کرتی رہیں۔ Tailscale کی policy file یہ محدود کرتی ہے کہ دوسرے nodes کن وسائل تک پہنچ سکتے ہیں، لیکن یہ public interface کے بارے میں کچھ نہیں کرتی۔
ان میں سے کوئی بھی ہر service کے لیے authentication فراہم نہیں کرتا، اور ان میں سے کوئی بھی اس بات کا audit trail نہیں ہوتا کہ connected ہونے کے بعد کسی user نے کیا کیا۔ ان تینوں کو transport سمجھیں، اور login checks application میں نافذ کریں۔
FAQ
کیا Tailscale صرف اضافی مراحل کے ساتھ WireGuard ہے؟
Tailscale ڈیٹا پاتھ کے لیے WireGuard پروٹوکول استعمال کرتا ہے، اس لیے encryption اور tunnel ایک جیسے ہیں۔ اس میں coordination شامل ہے: key exchange، address assignment، STUN اور DERP relays کے ذریعے NAT traversal، key expiry، اور ایسی policy file جو IP ranges کے بجائے users کے نام استعمال کرتی ہے۔ Plain WireGuard میں یہ کام آپ کو خود کرنے ہوتے ہیں۔ جب machines مختلف networks کے درمیان منتقل ہوتی ہیں تو یہی کام مشکل ہو جاتے ہیں۔
کیا میرا 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 کی طرف بھی بھیجا جا سکتا ہے، لیکن ہر 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 فعال کرنے پر صرف 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 بڑھاتا ہے۔ tailscale ping <node> سے اپنا path measure کریں؛ یہ بتاتا ہے کہ route direct ہے یا relayed۔ آپ tunnel کے پار iperf3 بھی استعمال کر سکتے ہیں۔