ٹنل قائم ہے، انٹرنیٹ نہیں: فارورڈنگ کہاں رکتی ہے

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

تصدیق کریں کہ انٹرنیٹ کا اخراج کبھی ڈیزائن تھا یا نہیں

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

کلائنٹ جو نصب کرتا ہے وہ ہمیشہ وہ نہیں ہوتا جو پروفائل کا مقصد ہے۔ دھکیلا گیا روٹ کم میٹرک والے مقامی روٹ سے مغلوب ہو سکتا ہے، اور وہ کلائنٹ جو اپنا LAN روٹ رکھتے ہوئے ڈیفالٹ روٹ شامل کرتا ہے، اس ذیلی نیٹ کے لیے تقسیم شدہ ٹنل کی طرح برتاؤ کرتا ہے۔

ایک عوامی درخواست کو گزاریں

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

ip route get 1.1.1.1
ip -4 addr show tun0
conntrack -L | grep 1.1.1.1
tcpdump -ni any host 1.1.1.1

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

فارورڈنگ، روٹ اور ترجمہ جانچیں

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

sysctl net.ipv4.ip_forward
ip route get 1.1.1.1
nft list ruleset | grep -A6 forward
sysctl net.ipv4.conf.all.rp_filter

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

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

جواب کا راستہ اور حل کنندہ دو مختلف جواب ہیں

صرف درخواست نہیں، جواب پر بھی نظر رکھیں۔ اگر درخواست ترجمہ شدہ باہر جائے اور جواب ترجمہ شدہ بہاؤ میں واپس آئے، تو فارورڈنگ کام کرتی ہے چاہے ایپلیکیشن ابھی ناکام ہو، اور اگلی تفتیش ایپلیکیشن یا DNS کی ہے۔

جو سائٹ HTTP غلطی واپس کرے وہ اس بات کا ثبوت ہے کہ انٹرنیٹ پر فارورڈنگ کام کرتی ہے۔ ایسا نام جو حل نہ ہو جبکہ پتے سے رسائی کام کرے، حل کنندہ کا مسئلہ ہے، NAT کا نہیں۔

درست اصلاح کے بعد کلائنٹ اور کسی بھی جان بوجھ کر محدود نجی وسیلے کو دوبارہ جانچیں۔ انٹرنیٹ تک رسائی دینے سے گیٹ وے سے منسلک ہر نیٹ ورک تک رسائی خاموشی سے نہیں بڑھنی چاہیے۔