VPS پر اپنا WireGuard VPN کیسے بنائیں

آپ کیا بنا رہے ہیں

اپنے زیرِ انتظام سرور پر WireGuard VPN کی configuration تقریباً 40 سطروں پر مشتمل ہوتی ہے: ایک key pair، ایک interface file، ایک sysctl، ایک NAT rule، اور firewall میں ایک اجازت شدہ port۔ installation آسان ہے، اس لیے اس guide کا بیشتر حصہ ان مسائل کا احاطہ کرتا ہے جو عموماً پیش آتے ہیں، key permissions، AllowedIPs، forwarding اور DNS۔

WireGuard kernel میں Layer 3 tunnel ہے اور Linux 5.6 سے mainline میں شامل ہے۔ اس لیے Ubuntu 24.04 اور Debian 13 اسے کسی external module کے بغیر فراہم کرتے ہیں۔ اس میں cipher negotiation، certificate authority یا username/password کا مرحلہ نہیں ہوتا۔ ایک peer ایک public key اور ان IP addresses کا مجموعہ ہوتا ہے جنہیں وہ key استعمال کر سکتی ہے۔ جس packet کی MAC check ناکام ہو جائے اسے کسی reply کے بغیر drop کر دیا جاتا ہے، اس لیے port scans کا جواب نہیں دیتا۔ دوسری طرف، کوئی auth server موجود نہیں ہوتا۔ لہٰذا access ختم کرنے کے لیے سرور پر peer delete کرنا پڑتا ہے۔

پہلے virtualization چیک کریں

WireGuard کے لیے ایسا kernel درکار ہوتا ہے جس میں module load کیا جا سکے، اور KVM VPS پر یہ عموماً بغیر اضافی configuration کے کام کرتا ہے۔ Host kernel شیئر کرنے والی container virtualization، مثلاً OpenVZ یا LXC، میں پہلا command RTNETLINK answers: Operation not supported کے ساتھ fail ہو جاتا ہے۔ ایسی صورت میں متبادل کے طور پر wireguard-go userspace implementation استعمال کریں۔ پہلے sudo modprobe wireguard && echo ok سے چیک کریں۔

کلیدیں اس طرح بنائیں کہ وہ افشا نہ ہوں

دنیا کے ہر صارف کے لیے قابلِ مطالعہ /etc/wireguard/server.key دراصل VPN نہ ہونے کے برابر ہے۔ عام umask 077 && wg genkey | sudo tee ... کمانڈ قابلِ اعتماد نہیں، کیونکہ sudo اپنی بنائی ہوئی tee فائل پر اپنا umask لاگو کرتا ہے۔ mode واضح طور پر مقرر کریں۔

sudo apt update && sudo apt install -y wireguard nftables
sudo install -d -m 700 /etc/wireguard
sudo sh -c 'umask 077; wg genkey > /etc/wireguard/server.key'
sudo sh -c 'wg pubkey < /etc/wireguard/server.key > /etc/wireguard/server.pub'
sudo chmod 600 /etc/wireguard/server.key

کلائنٹ کی key pair بھی اسی طریقے سے بنائیں۔ wg genpsk ایک اختیاری pre-shared key شامل کرتا ہے، جس کی ایک سطر ہر config میں شامل کی جاتی ہے۔

سرور کا انٹرفیس: /etc/wireguard/wg0.conf

[Interface]
Address = 10.8.0.1/24
ListenPort = 51820
PrivateKey = <contents of /etc/wireguard/server.key>

[Peer]
PublicKey = <laptop public key>
PresharedKey = <psk, optional>
AllowedIPs = 10.8.0.2/32

chmod 600 کر دیں؛ اگر startup warning میں بتایا جائے کہ فائل world-accessible ہے تو اس کا مطلب ہے کہ آپ نے یہ قدم چھوڑ دیا۔ Address ٹنل کے اندر سرور کا address ہے، اور اس میں پورے VPN subnet کا mask شامل ہوتا ہے۔ ایسی range منتخب کریں جس سے آپ کو عام نیٹ ورکس میں واسطہ نہ پڑے۔ 192.168.1.0/24 ان متعدد home routers سے متصادم ہے جن کے پیچھے آپ کے clients موجود ہوتے ہیں، اور پھر tunnel مقامی route کے مقابلے میں خاموشی سے ناکام ہو جاتی ہے۔

server کی جانب peer کا AllowedIPs ایک /32 ہوتا ہے، یعنی tunnel کا وہ واحد address جو اس client کے لیے مخصوص ہے۔ دو peers کو ایک ہی allowed IP دینے پر وہ آخری configure کیے گئے peer کو منتقل ہو جاتا ہے، اور پہلے peer کو traffic موصول ہونا بند ہو جاتا ہے، جبکہ کہیں بھی کوئی error ظاہر نہیں ہوتا۔ SaveConfig کو unset رہنے دیں، ورنہ wg-quick down live state کی بنیاد پر اس فائل کو دوبارہ لکھ دیتا ہے۔

باکس کو router میں تبدیل کریں

Linux server ایسے packets کو discard کر دیتا ہے جو اس کے لیے addressed نہ ہوں۔ Forwarding اور source NAT دونوں default طور پر فعال نہیں ہوتے۔

printf 'net.ipv4.ip_forward = 1\nnet.ipv6.conf.all.forwarding = 1\n' \
  | sudo tee /etc/sysctl.d/99-wireguard.conf
sudo sysctl --system
sysctl net.ipv4.ip_forward

ایک سادہ sysctl -w اگلے reboot تک کام کرتا رہتا ہے، پھر خاموشی سے رک جاتا ہے۔ NAT کو egress interface درکار ہوتا ہے، یعنی وہ NIC جو internet تک رسائی فراہم کرتا ہے، نہ کہ wg0۔ eth0 فرض نہ کریں؛ اپنا interface ip route show default سے معلوم کریں، کیونکہ موجودہ images میں enp1s0 یا ens3 جیسے نام استعمال ہوتے ہیں۔

فائر وال: پورٹ اور forwarding path

ایک nftables فائل filter اور NAT دونوں کو cover کرتی ہے۔ /etc/nftables.conf لکھیں؛ یہ موجودہ ruleset کو flush کر دیتی ہے، اس لیے ایسے box پر اسے نہ چلائیں جسے پہلے ہی ufw یا Docker manage کر رہا ہو۔

#!/usr/sbin/nft -f
flush ruleset

table inet filter {
  chain input {
    type filter hook input priority filter; policy drop;
    ct state established,related accept
    iif lo accept
    tcp dport 22 accept
    udp dport 51820 accept
  }
  chain forward {
    type filter hook forward priority filter; policy drop;
    ct state established,related accept
    iifname "wg0" oifname "enp1s0" accept
  }
}

table ip nat {
  chain postrouting {
    type nat hook postrouting priority srcnat; policy accept;
    ip saddr 10.8.0.0/24 oifname "enp1s0" masquerade
  }
}

اسے sudo systemctl enable --now nftables کے ذریعے apply کریں اور دوسری SSH session کھلی رکھیں: policy drop کے ساتھ SSH rule میں ایک typo آپ کو اپنے ہی server سے lock out کر سکتا ہے۔ نوٹ کریں کہ forward chain کیا allow نہیں کرتی، wg0 سے wg0 تک۔ Peers internet تک پہنچ سکتے ہیں، ایک دوسرے تک نہیں؛ peer-to-peer VPN کے لیے iifname "wg0" oifname "wg0" accept شامل کریں۔ یہی chain اس بات کو بھی control کرتی ہے کہ کوئی peer خود server پر کن resources تک پہنچ سکتا ہے۔ یہ اس وقت اہم ہے جب box ایک tmux میں Claude Code چلانے والے remote development box کے طور پر بھی استعمال ہو رہا ہو اور آپ اس حصے کو public طور پر expose نہ کرنا چاہتے ہوں۔

ufw والے box پر: ufw allow 51820/udp، /etc/default/ufw میں DEFAULT_FORWARD_POLICY="ACCEPT"، اور /etc/ufw/before.rules کے شروع میں *nat POSTROUTING MASQUERADE rule شامل کریں۔

اسے systemd کے تحت شروع کریں

sudo systemctl enable --now wg-quick@wg0
sudo wg show

wg-quick interface بناتا ہے، addresses شامل کرتا ہے، اور AllowedIPs سے اخذ کردہ routes نصب کرتا ہے۔ enable --now اہم حصہ ہے: ہاتھ سے چلایا گیا wg-quick up wg0 اگلے reboot کے بعد ختم ہو جاتا ہے، اور kernel upgrades کے لیے reboot ضروری ہوتا ہے۔ ان میں سے کسی reboot کے بعد دوبارہ شروع نہ ہونے والی unit اس وقت تک خاموش رہتی ہے جب تک کوئی اس سے connect ہونے کی کوشش نہ کرے۔ اس لیے wg-quick@wg0 پر اپنے ntfy server کی طرف اشارہ کرنے والا OnFailure= drop-in، فون پر اس کی اطلاع پانے کا سب سے کم خرچ طریقہ ہے، بجائے اس کے کہ اس کا علم کسی ایسے صارف سے ہو جو server سے lock out ہو چکا ہو۔

کلائنٹ کی configuration، اور وہ setting جسے سب اکثر غلط سمجھتے ہیں

[Interface]
PrivateKey = <laptop private key>
Address = 10.8.0.2/32
DNS = 10.8.0.1

[Peer]
PublicKey = <server public key>
Endpoint = vpn.example.com:51820
AllowedIPs = 0.0.0.0/0, ::/0
PersistentKeepalive = 25

AllowedIPs ایک ہی وقت میں دو مختلف کام کرتا ہے، اور انہیں باہم خلط ملط کرنا WireGuard سے متعلق زیادہ تر الجھنوں کی وجہ ہے۔

Outbound سمت میں یہ routing table ہے۔ جس packet کی destination کسی peer کے AllowedIPs سے match ہو، اسے encrypt کرکے اسی peer کو بھیجا جاتا ہے۔ 0.0.0.0/0, ::/0 تمام traffic کو tunnel سے گزارتا ہے؛ یہ full tunnel ہے، جس میں server default route ہوتا ہے۔ Split tunnel میں فہرست محدود ہوتی ہے: AllowedIPs = 10.8.0.0/24, 10.20.0.0/16 VPN traffic کے ساتھ server کے پیچھے موجود ایک private network تک رسائی بھی فراہم کرتا ہے، جبکہ باقی تمام traffic اپنی local route برقرار رکھتا ہے۔ یہی محدود فہرست آپ کو services کو مکمل طور پر public internet سے دور رکھنے دیتی ہے۔ مثلاً VPS پر private Nextcloud instance جو tunnel address پر bind ہو، یا اسی machine پر چلنے والی nested-virtualisation lab VMs peers کے لیے قابل رسائی اور باقی سب کے لیے پوشیدہ رہتی ہیں۔

Inbound سمت میں یہ access-control list ہے۔ اگر کسی peer سے decrypt ہونے والے packet کا source address اس peer کے AllowedIPs میں موجود نہ ہو تو اسے drop کر دیا جاتا ہے۔ اسی لیے server پر laptop کے لیے 10.8.0.2/32 درج کیا جاتا ہے: وہاں 0.0.0.0/0 کا اندراج اس client کو tunnel میں کسی بھی address کی spoofing کی اجازت دے دے گا۔

PersistentKeepalive ان clients کے لیے استعمال ہوتا ہے جو NAT کے پیچھے ہوں، جہاں router صرف packets کے تبادلے کے دوران UDP mapping کھلا رکھتا ہے۔ mapping کی مدت ختم ہونے پر server client تک دوبارہ نہیں پہنچ سکتا۔ PersistentKeepalive = 25 mapping کو کھلا رکھتا ہے؛ اسے client پر set کریں، ایسے server پر نہیں جس کا public IP ہو۔

DNS اور وہ لیک جس پر کوئی توجہ نہیں دیتا

AllowedIPs = 0.0.0.0/0 کے ساتھ، لیکن DNS = لائن کے بغیر، کلائنٹ مقامی نیٹ ورک سے حاصل کیا ہوا resolver استعمال کرتا رہتا ہے، جو کیفے کا router 192.168.1.1 ہے۔ یہ route default route سے زیادہ specific ہے، اس لیے DNS queries مقامی link سے cleartext میں باہر جاتی ہیں، جبکہ باقی تمام traffic tunnel کے ذریعے جاتا ہے۔ traffic نجی رہتا ہے؛ ناموں کی فہرست نجی نہیں رہتی۔

دو درست اختیارات ہیں۔ DNS کو public resolver (DNS = 9.9.9.9) پر point کریں۔ اس طرح queries tunnel کے ذریعے جاتی ہیں اور آپ کے server سے باہر نکلتی ہیں، اگرچہ وہ resolver پھر بھی انہیں دیکھ سکتا ہے۔ یا unbound یا dnsmasq کو 10.8.0.1 پر bound کر کے چلائیں، DNS = 10.8.0.1 set کریں، input chain میں udp dport 53 iifname "wg0" accept شامل کریں، وہ لائن set کریں اور resolver کو بھول جائیں؛ اس صورت میں کچھ بھی resolve نہیں ہوگا۔

Linux clients پر wg-quick، DNS کو resolvconf کے ذریعے apply کرتا ہے؛ اگر یہ موجود نہ ہو تو آپ کو resolvconf: command not found ملتا ہے۔ openresolv install کریں، یا systemd-resolved کلائنٹ پر PostUp = resolvectl dns %i 10.8.0.1 set کریں۔

ٹنل بند کیے بغیر peers شامل کرنا اور ہٹانا

کسی user کو شامل کرنے کے لیے interface restart کرنے سے تمام connected users کا کنکشن منقطع ہو جاتا ہے۔ [Peer] block کو wg0.conf میں شامل کریں، پھر peer set کو اسی وقت reload کریں۔

sudo bash -c 'wg syncconf wg0 <(wg-quick strip wg0)'

wg-quick strip config کو Address، DNS اور PostUp جیسی صرف wg-quick کے لیے مخصوص keys کے بغیر ظاہر کرتا ہے، جبکہ syncconf live sessions برقرار رکھتے ہوئے فرق لاگو کرتا ہے۔ یہ صرف peers کو update کرتا ہے؛ تبدیل شدہ Address کے لیے اب بھی مکمل down/up درکار ہے۔ sudo wg set wg0 peer <public key> remove کے ذریعے peer revoke کریں، پھر file سے اس کا block حذف کریں، ورنہ اگلے reload پر وہ دوبارہ شامل ہو جائے گا۔

خرابی کی صورتیں، اور وہ strings جو آپ دیکھیں گے

Handshake مکمل نہیں ہوتا۔ wg show peer کو latest handshake کے بغیر دکھاتا ہے، اور client logs میں یہ درج ہوتا ہے:

Handshake for peer 1 (10.0.0.10:51820) did not complete after 5 seconds, retrying (try 2)

یا تو کچھ موصول نہیں ہو رہا، یا کچھ قبول نہیں کیا جا رہا۔ پہلے یہ جانچیں: کیا UDP 51820، VPS firewall میں اور آپ کے provider کے network firewall میں کھلا ہے؟ زیادہ تر panels میں یہ الگ control ہوتا ہے۔ کیا Endpoint کا address اور port درست ہے؟ کیا keys آپس میں الٹ تو نہیں گئیں؟ Client کے [Peer] block میں server کی public key ہونی چاہیے، اور اس کے برعکس۔ Private key یا client کی اپنی public key paste کرنے سے یہی symptom ظاہر ہوتا ہے۔ Server پر sudo tcpdump -ni any udp port 51820 سے معلوم کریں کہ packets بالکل پہنچ رہے ہیں یا نہیں۔ Kernel module بطور default کچھ log نہیں کرتا۔ WireGuard کے messages dmesg میں صرف dynamic debug (echo module wireguard +p | sudo tee /sys/kernel/debug/dynamic_debug/control) فعال کرنے کے بعد ظاہر ہوتے ہیں۔ اسے فعال کرنے پر key mismatch، invalid-MAC drop کے طور پر نظر آتا ہے۔

Handshake کام کرتا ہے، internet نہیں۔ ping 10.8.0.1 کامیاب ہوتا ہے، لیکن ping 1.1.1.1 timeout ہو جاتا ہے: forwarding یا NAT موجود نہیں ہے۔ تصدیق کریں کہ sysctl net.ipv4.ip_forward میں 1 درج ہے۔ پھر client کے ping کرنے کے دوران counters کو sudo nft list ruleset یا sudo iptables -t nat -L POSTROUTING -n -v سے monitor کریں۔ Masquerade rule پر zero packets کا مطلب ہے کہ اس کا egress interface name غلط ہے۔ Replies کے بغیر بڑھتا ہوا counter، forward chain policy کی طرف اشارہ کرتا ہے۔

Internet کام کرتا ہے، names کام نہیں کرتے۔ ping 1.1.1.1 کامیاب ہوتا ہے، اور curl https://example.com Could not resolve host واپس کرتا ہے۔ DNS line موجود نہیں ہے، یا اس میں ایسا resolver درج ہے جو tunnel کے اندر سے قابل رسائی نہیں ہے۔

کچھ HTTPS sites رک جاتی ہیں۔ SSH اور ping درست کام کرتے ہیں، لیکن بڑے pages رک جاتے ہیں۔ یہ path MTU کا مسئلہ ہے: tunnel اضافی overhead شامل کرتا ہے، اور راستے میں کوئی link oversized packets کو اس وقت drop کر دیتا ہے جب ICMP message واپس نہیں پہنچتا۔ Client کے [Interface] میں MTU کم کریں۔ 1420 آزمائیں، پھر 1380، اور پھر 1280۔ اگر MTU کم کرنے سے یہ رکاوٹ دور ہو جائے، لیکن throughput پھر بھی توقع سے کم رہے، تو گول اعداد کا اندازہ لگانا بند کریں اور bisection کے ذریعے حقیقی path MTU معلوم کرنے اور TCP MSS کو محدود کرنے کا طریقہ اختیار کریں۔ اس سے وہ وجوہات بھی الگ ہو جاتی ہیں جن کا tunnel سے کوئی تعلق نہیں ہوتا۔

Interface شروع ہونے سے انکار کرتا ہے۔ Address already in use کا مطلب ہے کہ کوئی دوسرا process UDP 51820 استعمال کر رہا ہے۔ ناکام up کے بعد Cannot find device wg0 عموماً اس بات کی نشاندہی کرتا ہے کہ config مسترد کر دی گئی ہے؛ journalctl -u wg-quick@wg0 -n 50 پڑھیں۔

Streisand یا OpenVPN سے منتقلی

Streisand کی دیکھ بھال نہیں ہو رہی اور اس کا repository archive ہو چکا ہے۔ متروک automation پر VPN چلانا بتدریج پیدا ہونے والا security مسئلہ ہے۔ براہِ راست upgrade ممکن نہیں۔ OpenVPN کی PKI کو convert نہیں کیا جا سکتا۔ WireGuard میں certificates، CA یا expiry نہیں ہوتی، اس لیے ہر client کو نیا key pair دینا ہوتا ہے۔

منتقلی parallel طور پر کریں۔ ایک ہی server پر UDP 51820 پر WireGuard اور 1194 پر OpenVPN بیک وقت چل سکتے ہیں۔ wg0 کو فعال کریں، clients کو ایک ایک کر کے منتقل کریں، پھر پرانی service روک دیں۔ OpenVPN کا username/password اور revocation model منتقل نہیں ہوتا۔ اگر accounts یا audit trail درکار ہو تو اسے WireGuard کے اوپر ایک الگ layer کے طور پر شامل کریں۔

پیمانے پر بیک اپ، اپ گریڈز اور دباؤ کے عوامل

/etc/wireguard ہی سرور ہے۔ اس کا بیک اپ بنائیں (sudo tar czf wg-backup.tgz -C /etc wireguard، mode 600، سرور سے باہر محفوظ) اور آپ چند منٹ میں نئے VPS پر اسے دوبارہ بنا سکتے ہیں۔ سرور کی private key ضائع ہونے کی صورت میں ہر client configuration دوبارہ جاری کرنی ہوگی، کیونکہ clients سرور کی public key کو pin کرتے ہیں۔ اپ گریڈ معمول کے apt upgrade کے ساتھ ہوتے ہیں، جبکہ kernel updates کے لیے reboot درکار ہوتا ہے، اور اگر آپ نے wg-quick@wg0 فعال کیا ہو تو وہ خود بخود دوبارہ دستیاب ہو جاتا ہے۔

ہر peer کی state مختصر ہوتی ہے اور cryptographic عمل kernel میں چلتا ہے، اس لیے حد آپ کے VPS کی CPU اور bandwidth allowance ہے، اس configuration کی کوئی داخلی حد نہیں۔ اسے شائع شدہ اعداد پر بھروسا کرنے کے بجائے tunnel کے ذریعے iperf3 سے ناپیں۔ بڑے پیمانے پر اصل دباؤ operations پر آتا ہے۔ ہر peer کے لیے منفرد tunnel IP درکار ہوتا ہے، اور ساٹھ [Peer] blocks کو ہاتھ سے edit کرنا duplicate AllowedIPs پیدا کرنے کا آسان طریقہ ہے؛ configurations کو script سے generate کریں۔ ایک سرور ایک UDP endpoint اور failure کا ایک نقطہ ہوتا ہے، جبکہ WireGuard میں clustering نہیں ہے۔ Redundancy کے لیے اپنی keys والا دوسرا سرور درکار ہوتا ہے۔ Key rotation دستی رہتی ہے، اس لیے درج کریں کہ کون سی key کس کے پاس ہے اور اسے revoke کیسے کرنا ہے۔ جب یہ bookkeeping ایک text file سے بڑی ہو جائے تو معمول کا حل اسی kernel data plane کے اوپر control plane چلانا ہے۔ self-hosted NetBird server address allocation، peer distribution اور setup keys سنبھالتا ہے، جو بصورت دیگر آپ کو دستی طور پر کرنا پڑتا۔ اگر خود control plane چلانا ایک اضافی سرور ہو، تو Tailscale اسے آپ کے لیے host کرتا ہے، اور اس کا free plan چھ users اور unlimited devices کا احاطہ کرتا ہے، جو اتنا کافی ہے کہ زیادہ تر ذاتی fleets کو اس کی ادائیگی نہیں کرنی پڑتی۔ اس حد کے بعد لاگت machines کے بجائے لوگوں کی تعداد سے بڑھتی ہے، اس لیے گھرانے یا چھوٹی ٹیم کی حقیقی ادائیگی اس بات پر منحصر ہوتی ہے کہ کتنے افراد کے پاس logins ہیں، نہ کہ کتنے peers کو آپ wg0.conf میں ہاتھ سے شامل کرتے۔ اس صورت میں split-tunnel AllowedIPs bookkeeping کا متبادل subnet router سے اپنی private ranges advertise کرنا ہے۔ اسے ایک VPS سے ایک بار announce کر کے مرکزی طور پر approve کیا جاتا ہے، ہر client file میں paste نہیں کیا جاتا۔ یہ تبدیلی مفید ہے یا نہیں، اس کا فیصلہ اس بات پر ہوتا ہے کہ hosted control plane حقیقتاً کیا access کر سکتا ہے، اور اس کے پاس آپ کے traffic کو encrypt کرنے والی keys کبھی نہیں ہوتیں، اگرچہ یہ طے کرتا ہے کہ کون سے peers ایک دوسرے کے بارے میں معلومات حاصل کریں۔

اس پورے انتظام کے لیے ایسا Linux box درکار ہے جس پر آپ کا کنٹرول ہو، ایک public IP، ایسا kernel جس میں آپ module load کر سکیں، اور ایسا firewall جس پر ابتدا سے انتہا تک آپ کا اختیار ہو۔

FAQ

WireGuard handshake کبھی مکمل کیوں نہیں ہوتا؟

wg show میں ایسے peer کی فہرست دکھائی دینا جس کے پاس latest handshake نہ ہو، اس کا مطلب ہے کہ packets پہنچ نہیں رہے یا قبول نہیں کیے جا رہے۔ VPS firewall اور provider کے الگ network firewall، دونوں میں UDP 51820 چیک کریں۔ Endpoint host اور port کی تصدیق کریں۔ پھر یہ دیکھیں کہ keys باہم تبدیل تو نہیں ہوئیں۔ Client کے [Peer] block میں server کی public key ہونی چاہیے۔ Server پر sudo tcpdump -ni any udp port 51820 سے معلوم ہوتا ہے کہ packets بالکل پہنچ رہے ہیں یا نہیں۔ dmesg صرف اس وقت WireGuard کے handshake failures رپورٹ کرتا ہے جب dynamic debug (echo module wireguard +p | sudo tee /sys/kernel/debug/dynamic_debug/control) فعال کیا جائے۔ اس کے بعد key mismatch، invalid-MAC drop کے طور پر ظاہر ہوتا ہے۔

Tunnel connect ہو جاتا ہے، لیکن internet دستیاب نہیں۔ کیا missing ہے؟

ping 10.8.0.1 کا کام کرنا اور ping 1.1.1.1 کا timeout ہونا forwarding یا NAT کی طرف اشارہ کرتا ہے۔ تصدیق کریں کہ sysctl net.ipv4.ip_forward کی قدر 1 ہے اور یہ /etc/sysctl.d/ میں set ہے، صرف ایسے sysctl -w کے ذریعے نہیں جو reboot پر ختم ہو جائے۔ پھر masquerade rule چیک کریں کہ وہ ip route show default، enp1s0 یا ens3 میں سے اصل egress interface کا نام استعمال کر رہا ہے۔ شاذ و نادر صورت میں یہ eth0 ہو سکتا ہے۔

کیا مجھے اپنی client config میں DNS = line درکار ہے؟

Full tunnel اور DNS = line نہ ہونے کی صورت میں client وہ resolver استعمال کرتا ہے جو اسے local network سے ملا تھا۔ یہ queries local link پر cleartext میں جاتی ہیں، جبکہ باقی تمام traffic tunnel کے ذریعے جاتا ہے۔ DNS کو کسی public resolver پر point کریں، یا unbound/dnsmasq کو 10.8.0.1 پر bound چلا کر input chain میں udp dport 53 iifname "wg0" کھولیں۔

AllowedIPs اصل میں کس چیز کو control کرتا ہے؟

یہ دو کام کرتا ہے۔ Outbound سمت میں یہ routing table ہے: جس traffic کا match کسی peer کے AllowedIPs سے ہو، اسے encrypt کر کے اس peer کو بھیجا جاتا ہے۔ Inbound سمت میں یہ access-control list ہے: ایسا decrypted packet جس کا source اس peer کے AllowedIPs سے باہر ہو، drop کر دیا جاتا ہے۔ اسی لیے server side پر ہر client کے لیے ایک /32 درج ہوتا ہے، جبکہ client side پر 0.0.0.0/0 درج ہو سکتا ہے۔

کیا WireGuard کسی بھی VPS پر چل جائے گا؟

KVM VPS پر یہ in-kernel module کے ساتھ کام کرتا ہے اور اضافی setup درکار نہیں ہوتا۔ ایسی container virtualisation پر جو host kernel share کرتی ہو، مثلاً OpenVZ یا LXC، modprobe wireguard، Operation not supported کے ساتھ fail ہو جاتا ہے۔ ایسی صورت میں متبادل wireguard-go userspace implementation ہے۔ کسی بھی دوسرے کام سے پہلے sudo modprobe wireguard && echo ok چلائیں۔