pfSense بطور VPN سرور اور کلائنٹ: دو راستے، ایک روٹر

ایک آلہ ایک ہی وقت میں دو سمتوں میں دیکھ سکتا ہے: گھومنے پھرنے والے صارفین اندر جڑتے ہیں، اور وہی باکس باہر جا کر ایک ایگزٹ فراہم کنندہ سے جڑتا ہے تاکہ منتخب ٹریفک کسی دوسرے نیٹ ورک سے باہر جائے۔ دونوں سروسز کو فعال کرنے میں منٹ لگتے ہیں؛ انہیں ساتھ رہنے دینے کے لیے ایک ڈیزائن درکار ہے، کیونکہ دوسرا کردار اس روٹنگ جدول کو دوبارہ لکھتا ہے جس پر پہلا انحصار کرتا ہے۔ تین شرطیں طے کرتی ہیں کہ یہ ترتیب کام کرتی ہے یا نہیں، یعنی اندر آنے والی سروس اپنا واپسی راستہ رکھتی ہے یا نہیں، باہر جانے والی ٹنل اب بھی اپنے ساتھی تک پہنچتی ہے یا نہیں، اور جو ٹریفک آپ آگے بھیجنا چاہتے تھے وہ ایگزٹ کے لیے منتخب ہوتا ہے یا نہیں۔ ایک میں غلطی کریں تو دو ٹنلیں ملتی ہیں جو دونوں جڑے ہونے کی اطلاع دیتی ہیں جبکہ ان کے درمیان کوئی مفید چیز نہیں گزرتی۔ نیچے دیے گئے معائنے ہر شرط کو اسی ترتیب میں قائم کرتے ہیں جس ترتیب میں ناکامیاں عام طور پر ظاہر ہوتی ہیں۔

کسی بھی سیٹنگ کو چھونے سے پہلے دونوں کرداروں کے نام رکھیں

ہر انسٹانس کے لیے چار حقائق لکھیں: اس کا دور کا ساتھی، اس کا توثیقی مواد، وہ پتہ پول جو یہ تقسیم کرتا ہے، اور اس کے پیچھے کے نیٹ ورک۔ دونوں انسٹانس آلے پر الگ اشیاء ہیں اور آپ کے نوٹس میں بھی الگ رہنے چاہئیں۔ بعد میں آنے والی تقریباً ہر مبہم علامت ان کی قدروں کے مل جانے سے آتی ہے، اور دو انسٹانس کا ایک ہی نوٹ سیٹ شیئر کرنا ہی وہ راستہ ہے جس سے غلط پول غلط خانے میں پہنچتا ہے۔

اندر آنے والی سروس کو ایسا ٹنل نیٹ ورک چاہیے جو باہر جانے والی ٹنل کے پتوں یا آلے کے روٹ کردہ کسی بھی نجی نیٹ ورک سے متصادم نہ ہو۔ تصادم ہی وہ واحد غلطی ہے جو دونوں کرداروں میں بیک وقت علامات پیدا کرتی ہے، اور کاغذ پر اسے پکڑنا کہیں سستا ہے۔ کسی بھی سروس کی تشکیل سے پہلے دونوں پول اور ہر روٹ شدہ نجی نیٹ ورک ایک ہی جگہ پر موازنہ کریں۔

مشترکہ ہارڈویئر کا مطلب مشترکہ اسناد نہیں، اور دور رسائی پول سے آنے والا کلائنٹ سرٹیفکیٹ ایگزٹ فراہم کنندہ کے خلاف قابل استعمال نہیں ہونا چاہیے۔ الگ مواد منسوخی کو بھی پورے بیڑے کے واقعے کے بجائے مقامی فیصلہ بنا دیتا ہے۔

سرور کے جوابات WAN راستے پر رکھیں

آلہ خود جو جوابات پیدا کرتا ہے وہ لاپرواہ ڈیفالٹ راستے کا پہلا شکار ہیں۔ جب گھومنے پھرنے والے صارف کا لپٹا ہوا پیکٹ آتا ہے تو جواب مقامی طور پر پیدا ہونے والی ٹریفک ہے اور اسے اسی انٹرفیس سے نکلنا چاہیے جہاں سے وہ صارف آیا تھا۔ اگر باہر جانے والے کلائنٹ نے ایسا ڈیفالٹ راستہ لگایا ہوا ہے جو اسے پکڑ لیتا ہے تو جواب غلط ٹنل میں داخل ہوتا ہے اور سیشن رک جاتا ہے جبکہ سروس اب بھی صحت مند دکھائی دیتی ہے۔

اسے طے کرنے والا کوئی ایک چیک باکس نہیں، کیونکہ فیصلہ اس بارے میں ہے کہ باہر جانے والا کلائنٹ کون سی ٹریفک پکڑ سکتا ہے۔ یا تو کوئی راستہ نہ کھینچیں اور صرف وہی بھیجیں جو آپ منتخب کریں، یا راستے کھینچیں اور وہ استثنائیں شامل کریں جو آلے کی اپنی سروسز کو چلتا رکھتی ہیں۔ انتخاب انسٹانس کے ساتھ لکھیں، ورنہ اگلا شخص دوسرے کو فرض کرے گا۔

netstat -rn | head -20
pfctl -sr | grep -i vpn
ifconfig | grep -A3 ovpn

روٹنگ جدول کو طویل ترین مماثلت کے مطابق پڑھیں، اُس ترتیب سے نہیں جس میں آپ نے کچھ تشکیل دیا۔ سوال یہ ہے کہ ایگزٹ ساتھی کے پتے کے لیے کون سا اندراج جیتتا ہے اور اندر آنے والی سروس کے جواب کے لیے کون سا اندراج، اور یہ دونوں جواب مختلف ہو سکتے ہیں۔

باہر جانے والی ٹنل کو اپنا ہی آخری سرا کھانے نہ دیں

باہر جانے والے کلائنٹ کو ٹنل کے قیام کے لیے اپنے ساتھی کے عوامی پتے تک پہنچنا ہی ہوگا۔ اگر وہ پتہ خود ٹنل میں روٹ ہو جائے تو کلائنٹ اپنی ہی دم کے پیچھے بھاگتا ہے: منتقلی کبھی نہیں اٹھتی، یا اٹھ کر اسی لمحے گر جاتی ہے جب راستہ نصب ہوتا ہے۔ لاگ روٹنگ خرابی کے بجائے توثیق کے وقت کی تکمیل جیسا دکھتا ہے، اسی لیے راستے کی جانچ پہلے ہونی چاہیے۔

اسناد سے پہلے راستے کی جانچ کریں اور ٹنل کے اٹھنے کے بعد پھر، کیونکہ اندراج بوقت آغاز درست اور ایک منٹ بعد غلط ہو سکتا ہے۔ ساتھی کا پتہ عام WAN راستے کی طرف اشارہ کرنا چاہیے، کبھی ٹنل کے آلے کی طرف نہیں۔ منتقلی مستحکم ہوتے ہی دلچسپ سوال آگے بھیجی گئی ٹریفک کی طرف منتقل ہوتا ہے، اور وہی اگلا فیصلہ ہے۔

netstat -rn | grep -F '198.51.100.10'
traceroute -n 198.51.100.10

منتخب کریں کہ کون سے صارفین کو ایگزٹ ملے

ماخذ پالیسی اسی داخلی دروازے کی ہے جہاں ٹریفک آلے میں داخل ہوتی ہے، اس لیے دور رسائی پول یا اس کے اندر کے تنگ شناختیں منتخب کریں۔ وہ نجی منزلیں اور انتظامی استثنائیں محفوظ رکھیں جو کبھی ایگزٹ پر نہ بھیجی جائیں، اور وہ قواعد وسیع قاعدے سے پہلے رکھیں۔ پھر ایگزٹ راستے کو اپنا ترجمہ یا روٹ شدہ واپسی کا انتظام چاہیے، جو زیادہ تر ڈیزائنوں میں ایگزٹ انٹرفیس پر باہر جانے والا NAT ہے جو پول کو ڈھکتا ہے۔ ترجمہ ایگزٹ منتخب نہیں کرتا؛ وہ صرف وہی دوبارہ لکھتا ہے جو پہلے ہی نکل چکا، اس لیے غیر متعلق WAN پر NAT قاعدہ انتخاب میں کچھ نہیں بدلتا۔

تصدیق کریں کہ دور کا سرا اس ڈیزائن سے آگے بھیجی گئی ٹریفک کی اجازت دیتا ہے، کیونکہ بعض فراہم کنندگان دیتے ہیں اور بعض نہیں۔ فرق ایسی ٹنل کی صورت میں ظاہر ہوتا ہے جو جڑتی ہے مگر کچھ نہیں اٹھاتی، جسے مقامی خرابی سمجھ لینا آسان ہے۔ تینوں بہاؤ الگ الگ جانچیں، کیونکہ وہ آزادانہ ناکام ہوتے ہیں، اور تین میں سے دو کا مطلب آدھا بنا ہوا ڈیزائن ہے۔

openvpn --config user07.ovpn
curl -sS https://ifconfig.me
curl --interface 10.10.10.1 -sS https://intranet.corp.example/health

پہلا حکم گھومنے پھرنے والے صارف کا بیرونی رابطہ ہے، اور یہ تب کام کرتا ہے جب کلائنٹ بتائے کہ آغاز کی ترتیب مکمل ہو گئی ہے۔ دوسرا اسی جڑے ہوئے لیپ ٹاپ سے چلایا جاتا ہے اور اسے آپ کے WAN پتے کے بجائے ایگزٹ فراہم کنندہ کا پتہ بتانا چاہیے۔ تیسرا آلے پر پول کے کسی پتے سے بندھ کر چلتا ہے، اور یہ کسی بھی دور کے صارف کو شامل کیے بغیر آگے بھیجی گئی ٹریفک کے لیے ماخذ پالیسی جانچتا ہے۔ اگر یہ بجائے اس کے WAN سے جواب دے تو پالیسی مطابقت نہیں رکھتی، اور NAT کی تدوین کی کوئی مقدار انتخاب کا مسئلہ درست نہیں کرتی۔

فیصلہ کریں کہ ایگزٹ ناکام ہونے پر کیا ہوگا

ناکامی کا رویہ ہونے سے پہلے لکھیں: جب باہر جانے والی ٹنل گرے تو صارفین عام WAN پر لوٹتے ہیں یا ایگزٹ کے واپس آنے تک روکے جاتے ہیں؟ دونوں جواب جواز رکھتے ہیں، اور آلہ آپ کی جگہ انتخاب نہیں کرے گا۔ ہٹایا گیا راستہ یا مردہ گیٹ وے کی طرف اشارہ کرنے والی پالیسی خود بخود مکمل بندش کا نتیجہ نہیں دیتی۔ اگر آپ بندش چاہتے ہیں تو پالیسی کو یہ واضح طور پر کہنا ہوگا، اور اسے ایگزٹ ہٹا کر جانچنا ہوگا، اس کے بارے میں سوچ کر نہیں۔ اگر آپ واپسی چاہتے ہیں تو صارفین کو بتائیں، کیونکہ خاموشی سے عام راستہ لینے والی ٹریفک ہی وہ ٹریفک ہے جسے کسی نے ڈھکا ہوا سمجھا تھا۔

کلائنٹ انسٹانس کو غیر فعال کریں، دیکھیں کہ جڑا ہوا صارف اب بھی کہاں پہنچتا ہے، پھر اسے دوبارہ شروع کریں۔ وقت ختم ہونے والی درخواست ہی وہ مکمل بندش کا نتیجہ ہے جو آپ نے مانگا؛ جو WAN پتے کے ساتھ جواب دے وہی وہ واپسی ہے جو آپ نے درج نہیں کی۔ IPv6 اور DNS کے لیے معائنہ دہرائیں، کیونکہ IPv4 کے لیے لکھی گئی پالیسی AAAA ٹریفک کے بارے میں کچھ نہیں کہتی اور کسی بھی ٹنل کی دھکیلی ہوئی resolver وہیں سے جواب دیتی ہے جہاں سے سوال واقعی نکلتا ہے۔

pfSsh.php playback svc stop openvpn client 2
curl --max-time 6 -sS https://ifconfig.me
pfSsh.php playback svc start openvpn client 2

Netgate کی روٹ شدہ OpenVPN کی ترکیب دکھاتی ہے کہ ماخذ پالیسی، انٹرفیس کی تفویض اور باہر جانے والا ترجمہ کیسے ملتے ہیں، اور اس کا سائٹ سے سائٹ دائرہ وہی حصہ ہے جسے پورا نقل نہیں کرنا چاہیے۔ جو یہ آپ کو نہیں بتائے گی وہ یہ ہے کہ اوپر کی تین شرطوں میں سے کون سی آپ کے اپنے ڈیزائن نے پہلے ہی توڑ دی ہے۔