فائر وال پر کون سے VPN پورٹ کھولنے چاہئیں: پروٹوکول بہ پروٹوکول
PPTP کو TCP 1723 اور GRE چاہیے، L2TP/IPsec کو UDP 500 اور 4500 نیز ESP چاہیے، اور SSTP، OpenVPN اور WireGuard کو ایک ایک پورٹ چاہیے۔ یہ ہے کہ کیا کھولنا ہے۔
VPN ٹنل فائر وال سے گزرے گی یا نہیں، یہ دو الگ قواعد طے کرتے ہیں: وہ پورٹ جس پر کلائنٹ ڈائل کرتا ہے اور وہ پروٹوکول جو پے لوڈ اٹھاتا ہے۔ صرف پہلا کھولیں تو ٹنل تصدیق سے گزر جاتی ہے، لیکن اس کے بعد کوئی ڈیٹا نہیں جاتا۔ کم از کم PPTP کے لیے ایک TCP پورٹ اور GRE، L2TP/IPsec اور IKEv2 کے لیے دو UDP پورٹ اور ESP، اور SSTP، OpenVPN اور WireGuard کے لیے ایک ایک پورٹ ہے۔ سمت، حالت کی نگرانی اور NAT باقی طے کرتے ہیں۔
اُس پورٹ سے شروع کریں جس پر کلائنٹ ڈائل کرتا ہے
ہر خاندان کا ایک داخلہ مقام ہوتا ہے جس سے کلائنٹ سب سے پہلے رابطہ کرتا ہے، اور آپ کی اجازت کا قاعدہ اسی داخلہ مقام کا نام لے۔ PPTP کلائنٹ TCP 1723 سے جڑتے ہیں۔ L2TP/IPsec UDP 500 پر IKE شروع کرتا ہے اور NAT گزر استعمال ہونے پر UDP 4500 پر چلا جاتا ہے، جبکہ L2TP فریم خود ٹنل کے اندر UDP 1701 پر ہوتا ہے۔ SSTP سیشن کو TCP 443 پر TLS میں لپیٹتا ہے، IKEv2 UDP 500 اور 4500 پر بات چیت کرتا ہے، OpenVPN بطور طے شدہ UDP 1194 استعمال کرتا ہے مگر اکثر TCP 443 پر منتقل کر دیا جاتا ہے، اور WireGuard UDP 51820 پر سنتا ہے۔
| Family | Rule to add on the gateway | Typical mistake |
|---|---|---|
| WireGuard | UDP port from ListenPort, for the peer address | Assuming 51820 when the config says otherwise |
| OpenVPN | The configured UDP or TCP port, often 443 | Opening 1194 after the server moved |
| SSTP | TCP 443 limited to the gateway IP | Allowing 443 to any destination |
| IKEv2 | UDP 500 and UDP 4500, plus ESP | Allowing only 500 and losing NAT-T |
| L2TP/IPsec | UDP 500, 4500, ESP, and 1701 inside the tunnel | Exposing 1701 to the internet |
| PPTP | TCP 1723 and IP protocol 47 | Writing a rule for TCP 47 |
ان اعداد کو مستقل خصوصیات نہیں بلکہ طے شدہ قدریں سمجھیں۔ WireGuard انٹرفیس وہی سننے والا پورٹ استعمال کرتا ہے جو اس کی ترتیب اعلان کرتی ہے، اور OpenVPN سرور منتظم کے چنے ہوئے کسی بھی پورٹ پر بیٹھ سکتا ہے۔ قاعدہ لکھنے سے پہلے سرور کی ترتیب پڑھیں، کیونکہ 1194 کے لیے کھولی گئی فائر وال 443 پر منتقل ہونے والے سرور کے لیے کچھ نہیں کرتی۔
تیسرا ستون وہ جگہ ہے جہاں بیشتر تبدیلی ٹکٹ غلط ہوتے ہیں۔ قاعدہ موجود ہے، مگر وہ غلط منزل، غلط سمت یا غلط ترسیل کی طرف اشارہ کرتا ہے۔
GRE اور ESP پروٹوکول نمبر ہیں، پورٹ نہیں
GRE اور ESP کے پورٹ ہی نہیں ہوتے، اس لیے صرف پورٹ نمبر قبول کرنے والا فائر وال فارم انہیں بیان نہیں کر سکتا۔ GRE IP پروٹوکول 47 ہے اور ESP IP پروٹوکول 50، دونوں IP ہیڈر کے پروٹوکول خانے سے ملائے جاتے ہیں۔ TCP پورٹ 47 کے طور پر لکھا گیا قاعدہ کسی سے نہیں ملتا، اور اسی طرح PPTP پالیسی درست دکھتی ہے اور پھر بھی ہاتھ ملانے کے بعد ہر پیکٹ گرا دیتی ہے۔
گھریلو راؤٹر اسے پاس تھرو چیک باکس کے پیچھے چھپاتے ہیں، جو پروٹوکول کا قاعدہ لگاتا ہے اور GRE کے لیے بہاؤ کی نقشہ سازی کے لیے درکار NAT معاون بھی لگاتا ہے۔ اصل فائر وال پر آپ خود پروٹوکول شامل کرتے ہیں: PPTP سرور کی طرف IP پروٹوکول 47 کی اجازت دیں، IPsec گیٹ وے کی طرف IP پروٹوکول 50 کی اجازت دیں۔ جہاں پلیٹ فارم پروٹوکول کا خانہ نہ دے، وہاں انکیپسولیشن راستہ ہے، اسی لیے IKEv2 UDP 4500 پر واپس جا سکتا ہے اور اسی لیے OpenVPN اور WireGuard کو یہ مسئلہ کبھی نہیں آتا۔
کلائنٹ کو قصوروار ٹھہرانے سے پہلے دیکھیں کہ قاعدہ اصل میں کس سے ملتا ہے۔ گیٹ وے پر صفر پر رکنے والا پیکٹ کاؤنٹر کہتا ہے کہ قاعدہ کبھی چلا ہی نہیں، اور کلائنٹ کی طرف کتنی بار بھی دوبارہ نصب کریں، یہ نہیں بدلتا۔
سمت، حالت اور NAT جواب بدلتے ہیں
باہر ڈائل کرنے والا کلائنٹ اور اندر سننے والا گیٹ وے الگ الگ تقاضے ہیں، اور وہی پورٹ فہرست ایک سمت میں درست اور دوسری میں غلط ہو سکتی ہے۔ حالت جاننے والی فائر وال 500 اور 4500 پر UDP بہاؤ کی نگرانی کرتی ہے اور دوسرے قاعدے کے بغیر جوابات واپس جانے دیتی ہے۔ ESP اور GRE کوئی پورٹ نہیں اٹھاتے، اس لیے NAT آلے کے پاس پکڑنے کو کچھ نہیں ہوتا اور سیشن کی پیروی کے لیے اسے معاون یا انکیپسولیشن چاہیے۔
NAT گزر ہی وہ حصہ ہے جو رہ جاتا ہے۔ IKEv2 UDP 500 پر شروع ہوتا ہے، NAT آلہ پہچانتا ہے اور UDP 4500 پر جاری رہتا ہے، اس لیے صرف 500 کی اجازت دینے والی پالیسی ایسی ٹنل دیتی ہے جو قائم ہو کر پھر خاموش ہو جاتی ہے۔ L2TP/IPsec بھی وہی حرکت کرتا ہے۔ اگر آپ کی گرفت پہلی ادلا بدلی دکھائے مگر مسلسل ٹریفک نہ دکھائے، تو 500 پر رکنے والا قاعدہ تلاش کریں۔
ہر قاعدے کے ساتھ سمت لکھیں۔ «UDP 4500 کی اجازت دیں» کچھ نہیں کہتا جب تک آپ یہ نہ بتائیں کہ کہاں سے کہاں تک، اور گھومتے کلائنٹ کے لیے درست قاعدہ عام طور پر سائٹ سے سائٹ ساتھی کے لیے غلط ہوتا ہے۔
ہر راستہ گرفت سے جانچیں
گرفت کلائنٹ پر نہیں بلکہ گیٹ وے پر چلائیں: کلائنٹ صرف وہی درج کرتا ہے جو آیا۔ یہ فلٹر اوپر کے خاندانوں کو ڈھانپتے ہیں اور دکھاتے ہیں کہ کون سا مرحلہ غائب ہے:
sudo tcpdump -ni any tcp port 1723
sudo tcpdump -ni any udp port 500 or udp port 4500
sudo tcpdump -ni any proto gre
sudo tcpdump -ni any proto 50آؤٹ پٹ کو ترتیب کے طور پر پڑھیں۔ جب بات چیت نظر آئے مگر پے لوڈ پروٹوکول نہ، تو گرنا کلائنٹ اور گیٹ وے کے درمیان کہیں ہوتا ہے۔ جب دونوں نظر آئیں اور صفحہ پھر بھی ناکام ہو، تو فائر وال اب مشتبہ نہیں؛ روٹنگ، DNS یا کلائنٹ کو دیا گیا پتہ پول دیکھیں۔
tcpdump کے بغیر مشین پر وہی ثبوت انٹرفیس اور قاعدہ کاؤنٹر سے آتے ہیں۔ ٹنل انٹرفیس پر بائٹ اندر آتے ہیں مگر باہر نہیں جاتے — یہ پہلے اجازت کے قاعدے کی طرف نہیں بلکہ واپسی کے راستے کی طرف اشارہ کرتا ہے۔
ایسا قواعد کا مجموعہ چھوڑیں جس کا آپ دفاع کر سکیں
TCP 443 پر SSTP کسی بھی پورٹ پر مبنی فلٹر کے لیے عام HTTPS سے الگ نہیں پہچانا جا سکتا، اور جب نیٹ ورک صرف ویب ٹریفک کی اجازت دے تو یہی مقصد ہے۔ اسی لیے 443 کے قاعدے کو پورے انٹرنیٹ کی بجائے گیٹ وے کو منزل کا نام دینا چاہیے۔ ٹنل چلتے ہی عارضی کسی بھی سے کسی بھی قواعد مٹا دیں۔ لکھیں کہ کون سا قاعدہ ملا، جہاں ہو وہاں پروٹوکول نمبر، اور سمت، تاکہ اگلا شخص ثبوت سے شروع کرے۔
کلاؤڈ پوائنٹ ٹو سائٹ گیٹ وے انتخاب کو نظر آنے کے قابل بناتے ہیں: ڈاؤن لوڈ شدہ پروفائل یا 443 پر SSTP یا 500 اور 4500 پر IKEv2 استعمال کرتا ہے، اور صرف وہی کھولنا چاہیے جو پروفائل واقعی چنتا ہے۔ جدید نیٹ ورک میں PPTP GRE کی رعایت کے قابل نہیں، کیونکہ موبائل آپریٹر آپ کی فائر وال سے قطع نظر پروٹوکول 47 اکثر گرا دیتے ہیں۔ ٹکٹ بند کرنے سے پہلے تصدیق کریں کہ قاعدہ سرور ترتیب کے پورٹ سے ملتا ہے، پروٹوکول کا خانہ وہاں مقرر ہے جہاں خاندان کو ضرورت ہے، اور منزل کوئی پتہ نہیں بلکہ گیٹ وے ہے۔