روٹر پر VPN فیل اوور پالیسی بغیر لیک کے کیسے بنائیں
فیصلہ کریں کہ ترجیحی ٹنل گرنے پر ٹریفک کیا کرے: بیک اپ ٹنل، سادہ WAN یا بلاک۔ پھر اسے روٹر پر بنائیں اور جانچیں۔
فیل اوور بالکل ویسے ہی کام کر گیا جیسے ترتیب دیا گیا تھا، اور یہی مسئلہ تھا۔ جب بنیادی ٹنل گری، روٹر نے ڈیفالٹ روٹ کیبل موڈیم کی طرف منتقل کر دیا، لیپ ٹاپ براؤز کرتے رہے، اور کسی نے فون نہیں کیا۔ دو دن بعد کسی نے دیکھا کہ فنانس شیئر چھ گھنٹے تک کھلے انٹرنیٹ راستے پر قابلِ رسائی رہا۔ روٹر پر VPN فیل اوور پالیسی کوئی روٹنگ چال نہیں؛ یہ فیصلہ ہے کہ ترجیحی راستہ جانے پر ٹریفک کیا کرے، اور یہ فیصلہ راستہ جانے سے پہلے موجود ہونا چاہیے۔
ڈیٹیکٹر منتخب کرنے سے پہلے نتیجہ طے کریں
عام طور پر میز پر تین نتائج ہوتے ہیں: متاثرہ کلائنٹس کو بیک اپ ٹنل سے بھیجنا، انہیں عام WAN استعمال کرنے دینا، یا انہیں مکمل طور پر بلاک کرنا۔ لکھیں کہ کون سا کس VLAN، SSID یا ڈیوائس کلاس پر لاگو ہوتا ہے۔ ایک ہی سادہ «WAN پر جائیں» اصول کی وجہ سے اوپر والا فنانس شیئر عوامی راستے پر پہنچا۔
یہ تینوں ایک دوسرے کے بدل نہیں۔ WAN پر واپسی سپورٹ ڈیسک کو فون کے جوابات دیتے رکھتی ہے مگر اندرونی نام مقامی ریزولور پر ظاہر کرتی ہے۔ بیک اپ ٹنل پالیسی کو برقرار رکھتا ہے مگر ایسے ایگزٹ پتے پر پہنچ سکتا ہے جو دوسرا فریق قبول نہیں کرتا۔ بلاک کرنا پے رول VLAN کے لیے درست ہے اور اس گیسٹ نیٹ ورک کے لیے غلط ہے جس نے کبھی ٹنل استعمال نہیں کیا۔
| Outcome | Right for | What breaks |
|---|---|---|
| Backup tunnel | Policy must hold, remote access required | New exit address, return route, slower rekey |
| Plain WAN | Guest or public-only traffic | Internal names, DNS and IPv6 exposure |
| Block | Payroll, admin, anything VPN-only | Users lose all access and call you |
ڈیٹیکٹر کو اسی ناکامی سے ملائیں جس سے آپ واقعی ڈرتے ہیں
ہینڈ شیک کی حالت، انٹرفیس کی حالت اور قابلِ استعمال فارورڈنگ تین مختلف سگنل ہیں، اور صارف کے لیے صرف آخری اہم ہے۔ WireGuard ہم منصب تازہ ہینڈ شیک دکھا سکتا ہے جبکہ فراہم کنندہ کا اپ اسٹریم پیکٹ پھینک رہا ہو۔ OpenVPN کلائنٹ «منسلک» کی حالت میں رہ سکتا ہے جب اس کے دھکیلے گئے روٹ کا حل ہونا بند ہو جائے۔
pfSense پر عملی انتظام dpinger سے چلنے والا گیٹ وے گروپ ہے، جو نگرانی کے پتے کی جانچ کرتا ہے اور نقصان یا تاخیر کی حدیں پار ہونے پر گیٹ وے کو غیر فعال نشان زد کرتا ہے۔ اس نگرانی کو ٹنل سے باہر کسی چیز کی طرف موڑیں، جیسے دور دراز LAN کا میزبان یا کوئی عوامی پتہ جس تک اس کے ذریعے پہنچتے ہیں۔ اسے ٹنل کے اپنے ہم منصب پتے کی طرف موڑنا وہ حصہ ناپتا ہے جس کے بارے میں آپ پہلے ہی جانتے ہیں کہ زندہ ہے۔
گروپ ایسے بنائیں کہ بیک اپ آخری راستہ رہے
ایک سادہ ممبر فہرست کے بجائے درجے استعمال کریں۔ بنیادی درجہ 1 میں، بیک اپ ٹنل درجہ 2 میں، WAN درجہ 3 میں صرف ان VLAN کے لیے جن کی پالیسی اجازت دیتی ہے۔ pfSense میں یہ System > Routing > Gateway Groups کے تحت ہے: دونوں گیٹ وے شامل کریں، انہیں مختلف درجے دیں، Trigger Level کو ممبر ڈاؤن اور پیکٹ نقصان پر رکھیں، محفوظ کریں، پھر گروپ کو انٹرفیس ڈیفالٹ یا ان فائر وال قواعد کے Gateway خانے میں لاگو کریں جنہیں اس کی ضرورت ہے۔
pfSense 2.5 اور بعد کے OpenVPN کلائنٹ انسٹانس کے لیے، انسٹانس کی Default Gateway سیٹنگ طے کرتی ہے کہ ٹنل سسٹم کے ڈیفالٹ روٹ کو بدلتا ہے یا نہیں۔ قاعدے کے مطابق روٹنگ صرف اسی وقت ویسا برتاؤ کرتی ہے جیسا آپ توقع کرتے ہیں جب آپ کا فرض کردہ روٹ واقعی نصب ہو۔ تبدیلی کے بعد ٹنل کی حالت کے آئیکن پر بھروسے کے بجائے Status > Gateways دیکھیں۔
دو سیٹنگز زیادہ تر فلپنگ کا سبب بنتی ہیں۔ ایک جانچ کا وقفہ جو فراہم کنندہ کی اپنی دوبارہ ہم آہنگی سے چھوٹا ہو۔ دوسرا ایسا گروپ جس میں بنیادی اور بیک اپ ایک ہی درجہ شیئر کرتے ہیں، اس لیے دونوں ہر وقت اہل رہتے ہیں۔ صارفین کے خود محسوس کرنے سے پہلے نقصان اور تاخیر کی حدوں کے ذریعے ہسٹریسس شامل کریں۔
وہ راستے بند کریں جو ٹنل نے کبھی نہیں رکھے
پہلے DNS لیک۔ ریزولور WAN پر جواب دیتا رہتا ہے اور وہیں سے آگے بھیجتا ہے، اس لیے نام ISP کے ذریعے حل ہوتے رہتے ہیں جبکہ ٹریفک ٹنل سے بندھا ہوتا ہے۔ ریزولور کے آؤٹ باؤنڈ انٹرفیس محدود کریں، اندرونی ریزولور کلائنٹس تک پہنچائیں، اور صرف VPN والے VLAN میں باقی سب کے لیے پورٹ 53 بلاک کریں۔
IPv6 کو اپنا فیصلہ چاہیے۔ ڈوئل اسٹیک LAN ٹنل کھو سکتا ہے اور کام کرتا عالمی IPv6 ڈیفالٹ روٹ برقرار رکھ سکتا ہے، اس لیے براؤزر IPv6 کو ترجیح دیتے ہیں اور WAN سے باہر جاتے ہیں جبکہ IPv4 مکمل قابو میں دکھتا ہے۔ یا تو IPv6 کو ٹنل میں روٹ کریں یا ٹنل کے گرنے پر عالمی پریفکس کا اعلان بند کریں۔ آدھی پالیسی کسی سے بھی بدتر ہے، کیونکہ یہ کام کرتی دکھتی ہے۔
پھر واپسی کا راستہ۔ اگر بیک اپ ایگزٹ مختلف ماخذ پتہ استعمال کرتا ہے، دوسرے فریق کو جاننا ہوگا کہ ٹریفک اس کی طرف واپس کیسے بھیجنا ہے، اور پرانے پتے سے جڑی ہر حالت پہلے ہی مر چکی ہے۔ بنیادی کے گرنے پر کھلے سیشن منتقل نہیں ہوتے؛ وہ وقت ختم ہونے تک رکے رہتے ہیں اور ایپلیکیشن فیصلہ کرتی ہے کہ کیا کرنا ہے۔
گرنے، فلپنگ اور واپس آنے کے راستے کو جانچیں
بنیادی کو بے ضرر ٹریفک چلتے ہوئے نکالیں، پھر چار چیزیں پڑھیں: گروپ کے ممبران کی حالتوں کے لیے Status > Gateways، پرانے گیٹ وے سے بندھی حالتوں کے لیے pfctl -ss، ایگزٹ راستے کے لیے کلائنٹ سے traceroute، اور یہ دیکھنے کے لیے ریزولور استفسار کہ کس سرور نے جواب دیا۔
اب اسے فلپ کریں۔ بنیادی کو تیس سیکنڈ اوپر، تیس نیچے، دو بار لائیں۔ اگر ٹریفک ہر تبدیلی کے پیچھے بھاگے، حدیں بہت تنگ ہیں یا درجے غلط ہیں۔ اسے اپنے شیڈول پر ٹھیک کریں، ورنہ فراہم کنندہ اسے اپنے شیڈول پر کرے گا۔
آخر میں تصدیق کریں کہ آپ اب بھی روٹر کا انتظام کر سکتے ہیں۔ کنسول کیبل، مینجمنٹ VLAN یا سیلولر موڈیم جیسا آؤٹ آف بینڈ راستہ رکھیں۔ وہ فیل اوور ٹیسٹ جو آپ کو باہر بند کر دے وہ ٹیسٹ ہے جو آپ مکمل نہیں کر سکتے، اور ناقابلِ رسائی روٹر خود واپس نہیں آ سکتا۔
پالیسی کو مکمل کہنے سے پہلے، آپ کو ٹرمینل کھولے بغیر چار سوالوں کے جواب دے سکنے چاہئیں: ٹنل کے گرنے پر کون سے VLAN، WAN استعمال کر سکتے ہیں، ڈیٹیکٹر کیا دیکھتا ہے اور کتنا انتظار کرتا ہے، کون سے نام سرور اور IPv6 روٹ راستے کے ساتھ چلتے ہیں، اور اگر بیک اپ بھی ناکام ہو تو آپ واپس کیسے آئیں گے۔ اگر کوئی جواب «جو بھی ڈیفالٹ تھا» ہو، پالیسی اب بھی روٹر کی ہے، آپ کی نہیں۔