SSD Nodes Learn 8GB RAM — $66/سال
تعلیمی Matt Connorتحریر: Matt Connor · اپ ڈیٹ شدہ 2026-08-01

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

زیادہ تر self hosters کے لیے WireGuard رفتار، تقریباً 10 سطری config اور کم audit surface میں بہتر ہے۔ مگر OpenVPN کے یہ 4 استعمال اب بھی اہم ہیں۔

مختصر جواب

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

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

خود میزبانی کرنے والوں کے لیے WireGuard کیوں کامیاب رہا

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

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

sudo modprobe wireguard && echo ok

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

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

Port جواب نہیں دیتا۔ ایسا WireGuard packet جو message authentication check میں ناکام ہو، کسی بھی reply کے بغیر drop کر دیا جاتا ہے۔ اس لیے nmap -sU -p 51820 یہ open|filtered واپس کرتا ہے، چاہے کوئی چیز listening کر رہی ہو یا نہیں۔ TCP mode میں OpenVPN server اس وقت تک TCP handshake مکمل کر لیتا ہے جب تک وہ یہ فیصلہ نہ کر لے کہ آپ کو رسائی نہیں دینی۔ Scanner کے لیے یہ ثابت کرنے کو اتنا کافی ہے کہ وہاں کچھ موجود ہے۔ tls-crypt کے ساتھ UDP پر OpenVPN تقریباً اتنا ہی خاموش رہتا ہے۔ اس لیے یہ دلیل OpenVPN کے خلاف نہیں، بلکہ OpenVPN کو TCP پر چلانے کے خلاف ہے۔

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

2026 میں رفتار: فرق کم ہو گیا ہے

کئی سال تک رفتار کے بارے میں درست دلیل یہ تھی کہ OpenVPN ہر packet کو userspace میں نقل کرتا، وہیں encrypt کرتا، پھر اسے واپس نقل کرتا تھا، جبکہ WireGuard کبھی kernel سے باہر نہیں نکلتا تھا۔ اب مکمل صورتِ حال یہ نہیں رہی، اور اس پہلو کو نظرانداز کرنے والا موازنہ پرانا ہو چکا ہے۔

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

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 بناتا ہے، اس لیے ہر kernel upgrade کے بعد دوبارہ build ہوتا ہے۔ یہ ایک اضافی انتظامی جز ہے جو WireGuard میں نہیں ہوتا۔

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

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

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

آپ کو TCP port 443 کے ذریعے باہر نکلنا ضروری ہے۔ WireGuard صرف UDP استعمال کرتا ہے، اور یہ جان بوجھ کر ایسا ہے۔ TCP mode شامل نہیں کیا جائے گا۔ ہوٹل کا network یا corporate proxy، جو صرف TCP 443 کی اجازت دیتا ہے، proto tcp-server اور port 443 کے ساتھ configured OpenVPN traffic کو گزرنے دے گا، کیونکہ یہ traffic عام TLS session جیسا دکھائی دیتا ہے۔ اسی network سے گزرنے کے لیے WireGuard کو wstunnel یا udp2raw جیسے wrapper کی ضرورت ہوتی ہے۔ اس سے چلانے اور مسلسل patch کرنے کے لیے ایک اضافی process شامل ہو جاتا ہے۔ اس تضاد کو نوٹ کریں: اگر اسی IP address پر کوئی web server پہلے ہی TCP 443 استعمال کر رہا ہے، تو دونوں میں سے ایک کو منتقل کرنا ہوگا۔

آپ پہلے ہی certificate authority چلا رہے ہیں۔ OpenVPN، X.509 certificates کے ذریعے authentication کرتا ہے، اس لیے یہ اس PKI (public key infrastructure) میں شامل ہو جاتا ہے جسے آپ پہلے ہی چلا رہے ہیں۔ Certificates خود بخود expire ہوتے ہیں۔ کسی certificate کو revoke کرنے کے لیے اسے certificate revocation list میں شامل کریں، جسے 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 یا کسی قدیم 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 کرنل میں 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 برقرار رکھنا ہوں گے۔ اگر یہ پابندی آپ کے معمول کے کام کے ماحول کا حصہ ہے تو proto tcp-server اور port 443 کے ساتھ OpenVPN زیادہ آسان حل ہے۔

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

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

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

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