VPN اور ویب کے لیے ایک ہی عوامی ہوسٹ: کردار کیسے تقسیم کیے جائیں

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

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

پورٹس سے پہلے پتے کا مالک منتخب کریں

سرنگ کا آخری نقطہ اور ویب سرور ایک ہی کرنل شیئر کر سکتے ہیں؛ ایک ہی وقت میں ایک پتہ، پورٹ اور پروٹوکول شیئر کرنا ہی وہ چیز ہے جو ناکام ہوتی ہے۔ WireGuard عام طور پر UDP 51820 لیتا ہے، OpenVPN UDP 1194 یا TCP 443 لیتا ہے، اور ویب سرور TCP 443 لیتا ہے۔ تکلیف دینے والا جوڑا HTTPS کے ساتھ TCP 443 پر OpenVPN ہے، کیونکہ دونوں کو وہی ساکٹ چاہیے اور کرنل اسے پہلے بائنڈ کرنے والے کو دیتا ہے۔ صرف سامنے کا ڈیملٹی پلیکسر، جیسے sslh یا TLS سمجھنے والا پراکسی، انہیں یہ پورٹ شیئر کرنے دیتا ہے، اور یہ ایسا جزو شامل کرتا ہے جس کی ناکامی فائر وال مسئلے جیسی دکھتی ہے۔

کچھ بدلنے سے پہلے مالکان کو دیکھیں: ss -lntup ہر سننے والے ساکٹ کا مقامی پتہ، پورٹ اور عمل چھاپتا ہے۔ دکھانے والی دو سطریں 0.0.0.0:443 کا مطلب ہے کہ دوسری سروس نے کبھی بائنڈ نہیں کیا، چاہے اس کی init اسکرپٹ کتنی ہی خوش ہو۔ بریجنگ مالک کو بھی ہلاتی ہے۔ جب eth0 میں شامل ہوتا ہے br0، IP br0 پر چلا جاتا ہے اور ہر فائر وال قاعدہ جو eth0 کا نام لیتا ہے ملنا بند کر دیتا ہے، اس لیے سروسز کو بریج پر بائنڈ کریں اور ip -br addr سے تصدیق کریں۔

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

دو LAN کے درمیان روٹ کریں یا ایک طرف NAT کریں

جو دو LAN ایک دوسرے کو نہیں دیکھتے وہ دونوں عوامی ہوسٹ کو کال کر سکتے ہیں، جو پھر سرنگوں کے درمیان فارورڈ کرتا ہے۔ اس روٹ شدہ ڈیزائن کو تین چیزیں درکار ہیں: فارورڈنگ چالو، ہر دور دراز پریفکس کی طرف راستہ اور فارورڈنگ پالیسی جو گزرنے دیتی ہے۔ sysctl -w net.ipv4.ip_forward=1 پہلی کو ڈھانپتا ہے، ip route add 10.20.0.0/24 dev wg1 دوسری کو، اور nftables کی سطر nft add rule inet filter forward iifname "wg0" oifname "wg1" accept تیسری کو۔

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

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

دو کردار بند ہونے پر تقسیم جانچیں

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

تین کمانڈز اس جانچ کو ٹھوس بناتی ہیں۔ curl -sk --resolve example.test:443:203.0.113.10 https://example.test/ ثابت کرتا ہے کہ مقامی سامع بیرونی DNS کے بغیر جواب دیتا ہے، wg show کلائنٹ پر ثابت کرتا ہے کہ ہاتھ ملانا مکمل ہوا، اور tcpdump -ni any port 51820 مرکز پر روٹنگ مسئلے کو کلید کے مسئلے سے الگ کرتا ہے۔ جو ہاتھ ملانا کیپچر میں کبھی ظاہر نہیں ہوتا وہ میزبان سے پہلے مر گیا: فراہم کنندہ کی فائر وال، غلط عوامی پتہ یا راستے میں NAT قاعدہ۔

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

کردار کم کرتے وقت قواعد کا مجموعہ پڑھنے کے قابل رکھیں۔ nft list ruleset کو ہر اس سمت کے لیے ایک منظوری قاعدہ دکھانا چاہیے جس کی آپ کو واقعی ضرورت ہے، اور سب کچھ منظور کرنے والی فارورڈنگ زنجیر علیحدگی نہیں، وہ چلتا ہوا ڈیمو ہے۔

صرف IPv6 رسائی لائنیں اور IPv4 سروسز

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

ہر خاندان کو الگ الگ جانچیں curl -4 اور curl -6 سے، کیونکہ ایک کامیاب درخواست اس راستے کے بارے میں کچھ نہیں کہتی جو آپ نے آزمایا نہیں۔ پورٹ کی ملکیت خاندانوں کے درمیان نہیں بدلتی، مگر سامع بدلتا ہے: ss -lntup IPv4 اور IPv6 ساکٹس کو الگ سطروں میں درج کرتا ہے، اور 0.0.0.0:443 اسے ڈھانپتا نہیں [::]:443 جب تک عمل نے dual-stack ساکٹ نہ مانگا ہو۔

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