WireGuard یا OpenVPN: خود VPN سرور کے لیے کون بہتر ہے؟

مختصر جواب

WireGuard بمقابلہ OpenVPN، ایک ایسے فرد کے لیے جو اپنے VPS پر خود VPN سرور چلا رہا ہو، کوئی سخت مقابلہ نہیں ہے: WireGuard منتخب کریں۔ یہ چھوٹا ہے، Linux kernel کے اندر چلتا ہے، ایک سیکنڈ کے معمولی حصے میں کنکشن قائم کرتا ہے، اور کام کرنے والی client config تقریباً دس سطروں پر مشتمل ہوتی ہے۔ OpenVPN کے صرف چار حقیقی استعمال باقی رہتے ہیں۔ اگر ان میں سے کوئی بھی آپ کی ضرورت نہیں ہے تو آپ کو OpenVPN کی ضرورت نہیں۔

یہ چار استعمال یہ ہیں: ایسے network سے باہر نکلنا جو صرف TCP port 443 کی اجازت دیتا ہو، موجودہ certificate authority سے جڑنا، password یا دوسرے factor کے ذریعے نامزد صارفین کی authentication کرنا، اور Layer 2 پر bridging کرنا۔ ذیل میں اس تجویز کے شواہد اور وہ درست مقام دیا گیا ہے جہاں ہر استثنا آپ پر لاگو ہونا شروع ہوتا ہے۔

self-hosters کے لیے WireGuard کیوں کامیاب رہا

اس کا codebase اتنا مختصر ہے کہ اسے پڑھا جا سکتا ہے۔ WireGuard project میں اس کے protocol implementation کی لمبائی تقریباً 4,000 lines of code ہے۔ OpenVPN میں OpenSSL library کو شامل کرنے کے بعد، جس پر یہ ہر cryptographic operation کے لیے انحصار کرتا ہے، code کی مقدار چھ ہندسوں تک پہنچ جاتی ہے۔ حجم اہم ہے، کیونکہ ہر line attack surface ہوتی ہے، اور نہ آپ نہ آپ کا reviewer 100,000 lines پڑھنے والا ہے۔ آپ 4,000 lines پڑھ سکتے ہیں۔

یہ kernel میں چلتا ہے۔ WireGuard Linux کے mainline میں 5.6 سے شامل ہے، اس لیے Ubuntu 24.04 اور Debian 13 میں اسے compile کرنے کی ضرورت نہیں رہتی۔ Packets کو وہیں encrypt کیا جاتا ہے جہاں وہ پہلے سے موجود ہوتے ہیں، یعنی kernel space میں؛ انہیں userspace process میں copy کرکے واپس لانے کی ضرورت نہیں ہوتی۔ کسی بھی دوسرے کام سے پہلے یہ check کریں:

sudo modprobe wireguard && echo ok

KVM VPS پر یہ ok دکھاتا ہے۔ ایسی container virtualisation میں جو host kernel share کرتی ہے، مثلاً OpenVZ یا LXC، یہ Operation not supported کے ساتھ fail ہوتا ہے، کیونکہ ایسے kernel میں module load نہیں کیا جا سکتا جو آپ کی ملکیت نہ ہو۔

اس میں negotiate کرنے کے لیے کچھ نہیں ہوتا۔ WireGuard میں ایک fixed cipher suite ہے: data کے لیے ChaCha20-Poly1305 اور Curve25519 keys۔ ایسا کوئی version نہیں جسے downgrade کیا جا سکے، اور نہ ہی کوئی ایسی option ہے جسے غلط set کیا جا سکے۔ OpenVPN ہر client کے ساتھ cipher اور TLS (transport layer security) version negotiate کرتا ہے۔ یہ flexibility ہے، لیکن misconfiguration بھی اسی جگہ پیدا ہوتی ہے۔ data-ciphers AES-256-GCM:AES-128-CBC کے ساتھ چھوڑا گیا server ایسے client کے لیے CBC cipher پر آسانی سے fallback کر دے گا جو اس سے بہتر option پیش نہیں کرتا، اور log کمزور cipher کو مسئلہ قرار نہیں دے گا۔ جہاں data channel offload دستیاب ہو، OpenVPN یہ note لکھتا ہے کہ CBC entry نے offload بند کر دیا ہے۔ یہ warning speed کے بارے میں ہوتی ہے، security کے بارے میں نہیں۔

یہ port جواب نہیں دیتا۔ ایسا WireGuard packet جس کا message authentication check fail ہو جائے، بغیر کسی reply کے drop کر دیا جاتا ہے۔ اس لیے nmap -sU -p 51820 یہ معلوم نہیں کر سکتا کہ سامنے WireGuard server ہے یا ایسا port ہے جسے firewall خاموشی سے drop کر رہا ہے: دونوں صورتوں میں open|filtered واپس آتا ہے۔ صرف ایسا unfiltered port جس پر کچھ بھی listening نہ ہو، اپنی موجودگی ظاہر کرتا ہے، کیونکہ kernel ICMP port unreachable کے ساتھ جواب دیتا ہے اور nmap اسے closed report کرتا ہے۔ TCP mode میں OpenVPN server یہ فیصلہ کرنے سے پہلے TCP handshake مکمل کرتا ہے کہ آپ کو رسائی دینی ہے یا نہیں۔ اس سے scanner کو اتنا ثابت ہو جاتا ہے کہ وہاں کچھ موجود ہے۔ tls-crypt کے ساتھ UDP پر OpenVPN تقریباً اتنا ہی خاموش رہتا ہے، اس لیے یہ دلیل OpenVPN کے خلاف نہیں بلکہ اسے TCP پر چلانے کے خلاف ہے۔

Roaming مفت دستیاب ہے۔ WireGuard peer کی شناخت اس کی public key سے ہوتی ہے، address سے نہیں۔ آپ کا laptop گھر کے network سے mobile hotspot پر منتقل ہوتا ہے، نئے address سے ایک handshake بھیجتا ہے، اور server اس endpoint کو update کر دیتا ہے جس پر وہ جواب بھیجتا ہے۔ کچھ reconnect نہیں ہوتا، کیونکہ کوئی چیز کبھی connected ہی نہیں تھی۔ OpenVPN float کے ساتھ کچھ ایسا ہی کر سکتا ہے، لیکن client عام طور پر مکمل TLS session کو بند کرکے دوبارہ بناتا ہے۔ اسی لیے OpenVPN میں lid کھولنے کے بعد آنے والا pause محسوس ہوتا ہے، جبکہ WireGuard میں نہیں ہوتا۔

رفتار 2026 میں: kernel offload کے بغیر فرق صرف کم ہوتا ہے

کئی سال تک رفتار کے بارے میں درست بات یہ تھی کہ OpenVPN ہر packet کو userspace میں منتقل کرتا، وہیں اسے encrypt کرتا، پھر واپس منتقل کرتا تھا، جبکہ WireGuard کبھی kernel سے باہر نہیں جاتا تھا۔ Stock Ubuntu 24.04 server پر اب بھی صورتِ حال یہی ہے، اور WireGuard نمایاں طور پر تیز ہے۔ 2026 میں تبدیلی یہ آئی ہے کہ جب kernel اور OpenVPN version دونوں اس کی حمایت کرتے ہوں تو OpenVPN بھی اپنا data path kernel میں منتقل کر سکتا ہے۔ اس حقیقت کو نظرانداز کرنے والا موازنہ اب پرانا ہو چکا ہے۔

OpenVPN 2.7 فروری 2026 میں upstream ovpn kernel module کی حمایت کے ساتھ release ہوا۔ یہ module Linux 6.16 میں شامل کیا گیا تھا۔ اسے DCO (data channel offload) کہا جاتا ہے: control channel userspace میں رہتا ہے، جبکہ زیادہ تر data path kernel میں منتقل ہو جاتا ہے۔ یہ تقریباً وہی طریقہ ہے جو WireGuard ابتدا سے استعمال کرتا آیا ہے۔ DCO استعمال کرنے کے لیے کافی نئے kernel اور OpenVPN version پر throughput دونوں ایک ہی درجے میں ہوتے ہیں، ان میں نمایاں فرق نہیں رہتا۔ اپنے سسٹم پر موجود versions اور support کی جانچ کریں:

uname -r
openvpn --version | head -n 1
modinfo ovpn 2>/dev/null | head -n 3

اکتوبر 2026 تک stock Ubuntu 24.04 LTS میں OpenVPN 2.6 شامل ہے، 2.7 نہیں، اور ovpn module کے لیے 2.7 درکار ہے۔ اس release پر offload صرف پرانے openvpn-dco-dkms package کے ذریعے حاصل ہوتا ہے۔ یہ package چلتے ہوئے kernel کے مقابلے میں out-of-tree module build کرتا ہے، اس لیے ہر kernel upgrade کے بعد اسے دوبارہ build کرنا پڑتا ہے۔ یہ ایک اضافی انتظامی جزو ہے جو WireGuard میں موجود نہیں۔ Ubuntu 26.04 LTS میں OpenVPN 2.7.0 اور Linux 7.0 kernel شامل ہیں، اور دونوں ovpn کے لیے کافی نئے ہیں۔ اس لیے اس release پر اوپر دیا گیا modinfo command check کرنے والا ہے۔

DCO کو استعمال میں رکھنے کی وجہ سمجھنے سے پہلے اس کی پابندیاں پڑھیں۔ یہ صرف Layer 3 tunnels کی حمایت کرتا ہے۔ یہ صرف AEAD ciphers قبول کرتا ہے (authenticated encryption with associated data: AES-GCM یا ChaCha20-Poly1305)۔ یہ compression کی حمایت نہیں کرتا۔ Server پر یہ صرف topology subnet کے ساتھ کام کرتا ہے۔ ان میں سے ہر پابندی OpenVPN کی ابتدائی لچک کا ایک حصہ ختم کر دیتی ہے۔ تیز OpenVPN دراصل ایسی configuration والا OpenVPN ہے جو WireGuard جیسا ہو۔

کسی کے شائع کردہ throughput number پر، اس صفحے کے number پر بھی، بھروسا نہ کریں۔ VPS پر زیادہ سے زیادہ رفتار عموماً protocol کے بجائے CPU allowance یا network allowance سے محدود ہوتی ہے۔ Tunnel کے اندر iperf3 چلا کر اپنی رفتار ناپیں، پھر اسے tunnel کے باہر دوبارہ چلائیں، اور دونوں نتائج کا موازنہ کریں۔

جہاں OpenVPN اب بھی مفید ہے

آپ کو TCP port 443 کے ذریعے باہر نکلنا ضروری ہے۔ WireGuard صرف UDP استعمال کرتا ہے، اور یہ جان بوجھ کر ایسا ڈیزائن کیا گیا ہے؛ TCP mode آنے والا نہیں۔ جو hotel network صرف port number کی بنیاد پر filtering کرتا ہے، وہ عموماً proto tcp-server اور port 443 کے ساتھ configured OpenVPN کو گزرنے دے گا۔ اسے traffic disguise نہ سمجھیں: TCP پر OpenVPN عام TLS session کے بجائے اپنی packet framing استعمال کرتا ہے، اس لیے corporate firewall یا proxy جو HTTPS کا inspection یا termination کرتا ہو، اسے پھر بھی شناخت کر کے block کر سکتا ہے۔ اسی network سے گزرنے کے لیے WireGuard کو wstunnel یا udp2raw جیسے wrapper کی ضرورت ہوتی ہے، جس کے لیے ایک اضافی process چلانا اور patched رکھنا پڑتا ہے۔ اس تصادم کو ذہن میں رکھیں: اگر اسی IP address پر کوئی web server پہلے ہی TCP 443 استعمال کر رہا ہے تو دونوں میں سے ایک کو منتقل کرنا ہوگا۔

آپ پہلے ہی certificate authority چلاتے ہیں۔ OpenVPN، X.509 certificates کے ذریعے authentication کرتا ہے، اس لیے یہ اس PKI (public key infrastructure) میں شامل ہو جاتا ہے جسے آپ پہلے سے چلا رہے ہیں۔ Certificates خود expire ہو جاتے ہیں، اور کسی certificate کو certificate revocation list میں شامل کر کے revoke کیا جا سکتا ہے؛ server یہ فہرست crl-verify کے ذریعے پڑھتا ہے۔ WireGuard میں certificates، expiry اور revocation list کا کوئی تصور نہیں۔ کسی peer کو ہٹانے کے لیے server config میں ترمیم کر کے اسے reload کرنا پڑتا ہے۔ دس peers تک یہ قابلِ انتظام ہے۔ لیکن چار سو peers اور audit requirement کی صورت میں certificate model آپ کے لیے حقیقی انتظامی فائدہ فراہم کرتا ہے۔

آپ کو صرف keys نہیں بلکہ نامزد users درکار ہیں۔ OpenVPN، auth-user-pass-verify یا openvpn-plugin-auth-pam.so جیسے plugin کے ذریعے authentication کسی external system کے حوالے کر سکتا ہے۔ اسی طرح LDAP یا one-time-password پر مبنی second factor شامل کیا جاتا ہے۔ WireGuard میں user کا کوئی تصور موجود نہیں۔ کوئی key یا تو config میں موجود ہوتی ہے یا نہیں ہوتی۔ اگر آپ کی requirement یہ ہے کہ "Sara کو اپنے phone سے code داخل کرنا ہوگا"، تو WireGuard یہ عمل خود انجام نہیں دے سکتا۔

آپ کو Layer 2 یا کسی قدیم system کے لیے client درکار ہے۔ dev tap کے ساتھ OpenVPN Ethernet frames کو bridge کرتا ہے، جو broadcast protocols اور پرانے LAN games کے لیے اہم ہے۔ WireGuard صرف Layer 3 ہے اور ہمیشہ رہے گا۔ OpenVPN کے ایسے hardware اور operating systems کے لیے بھی clients موجود ہیں جہاں کبھی WireGuard app دستیاب نہیں ہوگی۔ یہ دونوں وجوہات بتدریج کم اہم ہو رہی ہیں، اور dev tap، DCO کے ساتھ compatible نہیں ہے؛ اس لیے bridge استعمال کرنے پر آپ کو slow path اختیار کرنا پڑتا ہے۔

یہ دونوں سیٹ اپ دراصل آپ سے کیا لاگت لیتے ہیں

WireGuard کی شناخت بنانے کے لیے ایک کمانڈ کافی ہے، اور قوسین اہم ہیں کیونکہ کلید بننے سے پہلے وہ فائل موڈ مقرر کرتی ہیں:

(umask 077; wg genkey > private.key)
wg pubkey < private.key > public.key

OpenVPN کا مساوی انتظام ایک certificate authority ہے، جس کی ذمہ داری VPN کے موجود رہنے تک آپ کے پاس رہتی ہے:

sudo apt install -y easy-rsa
make-cadir ~/openvpn-ca
cd ~/openvpn-ca
./easyrsa init-pki
./easyrsa build-ca
./easyrsa gen-req server nopass
./easyrsa sign-req server server

دونوں فہرستیں منصفانہ ہیں۔ CA آپ کو میعاد ختم ہونے اور منسوخی کی سہولت دیتی ہے، لیکن اس کے بدلے آپ کو ایک ایسی private key کئی سال تک محفوظ رکھنی ہوگی، renewal یاد رکھنا ہوگا، اور key ضائع ہونے کی صورت میں دوبارہ ترتیب دینا ہوگی۔ اگر آپ اس کی فراہم کردہ سہولتیں استعمال نہیں کر رہے، تو آپ بلاوجہ لاگت ادا کر رہے ہیں۔ مکمل WireGuard طریقہ کار، جس میں forwarding، NAT (network address translation)، اور وہ handshake failures شامل ہیں جو پورا ایک دوپہر ضائع کر دیتے ہیں، اپنے VPS پر WireGuard VPN خود میزبانی کرنے کی رہنما میں موجود ہے۔

ہر ایک آپ کے firewall سے کیا تقاضا کرتا ہے

WireGuard کو صرف ایک inbound rule درکار ہوتا ہے، یعنی ListenPort میں موجود port کے لیے UDP:

sudo ufw allow 51820/udp
sudo ufw status verbose

OpenVPN کو default طور پر UDP 1194 درکار ہوتا ہے، یا اگر آپ نے وہ راستہ منتخب کیا ہے تو TCP 443۔ اس کے بعد دونوں کے لیے IP forwarding فعال کرنا اور source NAT rule شامل کرنا ضروری ہے، کیونکہ Linux ایسے packets کو drop کر دیتا ہے جن کا address خود اس کے لیے نہ ہو۔ دونوں protocols کے لیے یہ حصہ یکساں ہے، اور زیادہ تر "tunnel connect ہو جاتا ہے لیکن internet دستیاب نہیں" کی رپورٹس اسی وجہ سے ہوتی ہیں۔ اگر ufw آپ کے لیے نیا ہے تو VPS پر ufw firewall کی بنیادی باتوں سے شروع کریں، اور یاد رکھیں کہ زیادہ تر providers اپنے control panel میں ایک دوسرا network firewall بھی چلاتے ہیں: اگر packet server تک پہنچ ہی نہ سکے تو server پر شامل کیا گیا rule کوئی اثر نہیں ڈالتا۔ port کیا ہوتا ہے اور Linux اس پر کیسے listen کرتا ہے کو سمجھنے سے دونوں checks تیزی سے مکمل ہو جاتے ہیں۔

ایک پیراگراف میں انتخاب کیسے کریں

جب تک آپ اس مخصوص کام کی نشاندہی نہ کر سکیں جو WireGuard آپ کے لیے انجام نہیں دے سکتا، WireGuard چلائیں۔ اگر محدود نیٹ ورک سے نکلنے کے لیے آپ کو TCP 443 درکار ہو تو وہاں OpenVPN چلائیں، اور دونوں چلانے پر غور کریں: یہ مختلف ports استعمال کرتے ہیں اور ایک ہی server پر بغیر کسی تنازع کے ساتھ چل سکتے ہیں۔ اگر آپ کو فی صارف accounts یا دوسرے factor کی ضرورت ہے تو WireGuard کے ساتھ زبردستی مطابقت پیدا کرنے کی کوشش نہ کریں۔ اس کے بجائے اس کے اوپر identity layer رکھیں۔ خود میزبانی والا Headscale control server اندرونی طور پر WireGuard استعمال کرتا ہے اور account model، key distribution اور device approval فراہم کرتا ہے، جن کا انتظام plain WireGuard میں آپ کو خود کرنا پڑتا ہے۔

OpenVPN سے بغیر تعطل کے منتقلی

براہِ راست تبدیلی ممکن نہیں۔ OpenVPN کی PKI، WireGuard keys میں تبدیل نہیں ہوتی، کیونکہ WireGuard میں تبدیل کرنے کے لیے certificates موجود نہیں ہوتے۔ ہر client کو نیا key pair ملتا ہے، جو server کے key pair کی طرح ہی تیار کیا جاتا ہے۔

تبدیلی کرنے کے بجائے دونوں کو متوازی طور پر منتقل کریں۔ WireGuard، UDP 51820 پر، اور OpenVPN، 1194 پر، ایک ہی box پر بیک وقت چل سکتے ہیں۔ پہلے wg0 کو فعال کریں، sudo wg show کے ذریعے حالیہ latest handshake کی فہرست دیکھ کر اس کی تصدیق کریں، پھر clients کو ایک ایک کرکے منتقل کریں۔ جب OpenVPN peer list میں مزید تبدیلی نہ ہو، تو sudo systemctl disable --now openvpn-server@server کے ذریعے service روک دیں۔ CA files اس وقت تک محفوظ رکھیں جب تک آپ کو یقین نہ ہو جائے، کیونکہ حذف شدہ CA پر revoked client کو دوبارہ بنانا ممکن نہیں ہوتا۔

ایک چیز واقعی منتقل نہیں ہوتی: آپ کے username اور password والے accounts، اور ان کے ساتھ موجود revocation trail۔ پرانے server کو بند کرنے سے پہلے طے کریں کہ یہ معلومات کہاں رکھی جائیں گی، بعد میں نہیں۔

FAQ

کیا WireGuard، OpenVPN سے زیادہ تیز ہے؟

ایک عام Ubuntu 24.04 سرور پر ہاں، اور نمایاں فرق کے ساتھ، کیونکہ WireGuard kernel میں encryption کرتا ہے جبکہ OpenVPN 2.6 ہر packet کو userspace process سے گزارتا ہے۔ OpenVPN 2.7 اور Linux 6.16 کے ovpn kernel module کے ساتھ data path بھی kernel میں ہوتا ہے، اس لیے دونوں ایک ہی درجے میں آ جاتے ہیں۔ اپنے tunnel کے ذریعے iperf3 چلا کر خود رفتار ناپیں، کسی blog میں دی گئی تعداد پر بھروسا نہ کریں، کیونکہ VPS پر حد عموماً CPU یا bandwidth allowance ہوتی ہے۔

کیا WireGuard، TCP port 443 پر چل سکتا ہے؟

اپنے طور پر نہیں۔ WireGuard بنیادی طور پر صرف UDP استعمال کرتا ہے، اور TCP mode کا کوئی منصوبہ نہیں ہے۔ TCP 443 کی اجازت دینے والے network سے گزرنے کے لیے اسے wstunnel یا udp2raw جیسے tunnel میں لپیٹنا پڑتا ہے، جس کے لیے دونوں سروں پر ایک process چلانا اور اس کے patches لگانا ضروری ہوتا ہے۔ اگر یہ پابندی آپ کے معمول کے working environment کا حصہ ہے تو صرف port کی بنیاد پر filtering کرنے والے network میں proto tcp-server اور port 443 کے ساتھ OpenVPN زیادہ سادہ حل ہے، اگرچہ HTTPS کا معائنہ کرنے والا proxy اسے پھر بھی شناخت کر کے block کر سکتا ہے۔

کیا OpenVPN اب غیر محفوظ ہے؟

نہیں۔ AES-256-GCM جیسے AEAD cipher اور فعال tls-crypt کے ساتھ موجودہ OpenVPN ایک قابل اعتماد VPN ہے۔ WireGuard کے حق میں اصل دلیل کچھ اور ہے: OpenVPN میں کہیں زیادہ code اور کہیں زیادہ options ہوتے ہیں، اس لیے تھکا ہوا administrator اسے غلط configure کرنے کے زیادہ طریقوں کا سامنا کرتا ہے۔ کم اختیارات کا مطلب کم غلطیاں ہے۔

VPS پر ذاتی VPN کے لیے مجھے کون سا منتخب کرنا چاہیے؟

WireGuard۔ ہر device کے لیے ایک key pair، تقریباً دس lines کی ایک config file، کھلا ہوا ایک UDP port، اور ایسا handshake جو شروع ہونے کا احساس ہونے سے پہلے مکمل ہو جاتا ہے۔ OpenVPN صرف اس صورت میں منتخب کریں جب آپ باقاعدگی سے ایسے networks سے connect ہوتے ہوں جو UDP کو block کرتے ہیں، یا آپ کو کسی پہلے سے موجود certificate authority یا user directory کے ساتھ مطابقت رکھنا ضروری ہو۔