روٹ شدہ VPN کلائنٹ سرور تک پہنچتا ہے مگر LAN میزبانوں تک نہیں

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

جواب کا پیچھا کریں، درخواست کا نہیں

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

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

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

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

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

# on the LAN gateway; tunnel pool 172.20.5.0/24, VPN server 10.60.4.10
ip route add 172.20.5.0/24 via 10.60.4.10
ip route get 172.20.5.14

سورس NAT اسے ٹھیک کرتا کیوں دکھتا ہے

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

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

iptables -t nat -A POSTROUTING -s 172.20.5.0/24 -o ens18 -j MASQUERADE
iptables -t nat -L POSTROUTING -n -v

کلاؤڈ راستے کو تین سیٹنگز درکار ہیں

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

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

جانچیں اسی ترتیب سے کریں

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

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

sysctl net.ipv4.ip_forward net.ipv4.conf.all.rp_filter
tcpdump -ni any host 172.20.5.14 and icmp

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