LAN سرور پر VPN کلائنٹ: جواب غلط راستے سے کیوں نکلتے ہیں

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

جواب ایک نیا پیکٹ ہے، راستے کا الٹا سفر نہیں

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

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

باقی پڑھتے وقت دو ذیلی جال ذہن میں رکھیں۔ ایک VPN پتوں کا تالاب ہے جہاں سے دور دراز کلائنٹ آتے ہیں، اس مثال میں 10.64.0.0/24۔ دوسرا وہ LAN ہے جو چلتا رہنا چاہیے، 172.16.24.0/24 جس کا روٹر 172.16.24.1 پر ہے۔ خرابی یہ ہے کہ ان کے درمیان ٹریفک طے شدہ راستہ طے کرتا ہے۔

اسے کیپچر اور تلاش سے ثابت کریں

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

ip route get 10.64.0.23 from 172.16.24.10
tcpdump -ni any -c 6 icmp

جواب دو حصوں میں پڑھیں۔ اگر وہ dev tun0 بتاتا ہے، ہوسٹ جواب کو انکیپسولیٹ کر کے فراہم کنندہ کو دے گا، اور LAN کلائنٹ اسے کبھی نہیں دیکھے گا۔ اگر وہ dev eth0 بتاتا ہے مگر کلائنٹ کو پھر بھی وقت ختم ہوتا ہے، تو راستہ پہلے ہی درست ہے اور پیکٹ بعد میں ضائع ہو رہا ہے، جو دوسرا مسئلہ اور دوسرا حل ہے۔

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

ٹنل کو پیچھے چھوڑنے والا سب سے تنگ راستہ نصب کریں

پریفکس کی لمبائی طے کرتی ہے، میٹرک نہیں، اس لیے LAN روٹر کے ذریعے کلائنٹ تالاب کا راستہ VPN کلائنٹ کے کسی بھی طے شدہ راستے پر بھاری پڑتا ہے۔ میٹرک کی سرجری کی ضرورت نہیں، اور طے شدہ راستہ وہیں رہ سکتا ہے جہاں کلائنٹ نے رکھا تھا۔

ip route replace 10.64.0.0/24 via 172.16.24.1 dev eth0
ip route get 10.64.0.23 from 172.16.24.10

دوسرے add کی بجائے replace استعمال کریں، کیونکہ دوبارہ جڑنے والا کلائنٹ اپنی اندراج پہلے ہی نصب کر چکا ہوگا اور دوسرا add موجودہ راستے کی غلطی سے ناکام ہوتا ہے جو اجازت کی مشکل جیسی پڑھی جاتی ہے۔ Windows ہوسٹ پر متبادل route add 10.64.0.0 mask 255.255.255.0 172.16.24.1 -p ہے، جہاں -p دوبارہ چلانے کے دوران اندراج رکھتا ہے، کیونکہ ٹنل دوبارہ اٹھنے پر کلائنٹ جدول دوبارہ بنا سکتا ہے۔ جدید Windows ہوسٹ پر تعاون یافتہ متبادل New-NetRoute -DestinationPrefix 10.64.0.0/24 -NextHop 172.16.24.1 -InterfaceAlias Ethernet -PolicyStore PersistentStore ہے، اور پرانا route حکم legacy شکل کے طور پر رکھا گیا ہے۔

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

دوبارہ جڑنے کے بعد بھی جواب رکھیں

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

حالت والا فائر وال درست راستے کو بھی ہرا سکتا ہے۔ اگر کیپچر اب دکھاتی ہے کہ جواب eth0 سے باہر جاتا ہے اور کلائنٹ کو پھر بھی وقت ختم ہوتا ہے، تو دیکھیں کہ ہوسٹ بھیجنے سے پہلے پیکٹ ضائع کر رہا ہے یا نہیں۔ سخت ریورس پاتھ فلٹرنگ اور net.ipv4.conf.all.rp_filter کو 1 پر رکھنا، ایسے پیکٹ ضائع کرتے ہیں جن کا ماخذ اسی انٹرفیس سے واپس روٹ نہیں ہوتا جس سے آیا، اور یہی وہ غیر متوازن صورت ہے جو آپ نے ابھی بنائی اور پھر ٹھیک کی، اور conntrack حالت آگے بھیجے گئے پورٹس کے لیے بھی وہی کہانی سناتی ہے۔

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