سائٹ سے سائٹ VPN کا جواب سرنگ سے نہیں گزرتا
سرنگ سے بچ نکلنے والا جواب دور کے سرے کا روٹنگ فیصلہ ہے۔ ہوسٹ ٹیبل، سلیکٹرز اور rp_filter جانچیں، پھر راستہ یا NAT منتخب کریں۔
میں نے ایک صبح ایسی سرنگ پر گزاری جو صاف طور پر اٹھی اور ٹریفک کو بالکل ایک ہی سمت میں لے گئی: برانچ ہیڈکوارٹر کے فائل سرور تک پہنچ سکتی تھی، اور ہیڈکوارٹر سے برانچ میں کھلنے والا ہر کنکشن پہلے SYN پر ہی مر جاتا تھا۔ SA فعال تھے، سرنگ کے کاؤنٹر بڑھ رہے تھے، اور ہینڈ شیک کبھی مسئلہ نہیں تھا۔ جواب کہیں ایسی جگہ روٹ ہو رہا تھا جہاں سرنگ نہیں پہنچتی، اور یہ انتخاب دور کے سرے کا ہے۔ سائٹ سے سائٹ VPN صرف وہ پیکٹ لے کر جاتا ہے جو ہوسٹ گیٹ وے کے حوالے کرتا ہے، اور ہر ہوسٹ یہ انتخاب الگ الگ، ہر سمت میں، اپنی روٹنگ ٹیبل سے کرتا ہے۔
دونوں سمتیں الگ الگ روٹ ہوتی ہیں
IP گفتگو کی سمت کی کوئی یاد نہیں رکھتا۔ پیکٹ بھیجنے والا ہر ہوسٹ اپنی سب سے طویل سابقہ تلاش چلاتا ہے، اگلا ایک ہاپ منتخب کرتا ہے اور فیصلہ بھول جاتا ہے۔ درخواست اور جواب دو غیر متعلقہ پیکٹ ہیں جو اتفاقاً ایک ہی کنکشن سے تعلق رکھتے ہیں، اور سرنگ ایک ہاپ ہے جسے ان میں سے کوئی بھی استعمال کر سکتا ہے یا نہیں۔ IKE کے تبادلے میں کچھ بھی دور کے سرور کو یہ نہیں سکھاتا کہ آپ کے سب نیٹ تک کیسے پہنچا جائے؛ گفت و شنید صرف اس پر متفق ہوتی ہے کہ کون سے سابقے خفیف کیے جا سکتے ہیں۔
یہ معاہدہ دوسرا دروازہ ہے۔ strongSwan پر ٹریفک سلیکٹرز leftsubnet اور rightsubnet ہیں، اور جس پیکٹ کا ماخذ یا منزل طے شدہ جوڑے سے باہر ہو وہ خفیف نہیں ہوتا، روٹنگ ٹیبل کچھ بھی کہے۔ جو سابقہ سرنگ میں روٹ ہوتا ہے مگر سلیکٹرز میں نہیں، وہ خاموش یک سمتی ناکامی ہے: راستہ درست دکھتا ہے، پیکٹ پھر بھی کھلا نکل جاتا ہے یا پھینک دیا جاتا ہے، اور صرف charon کا لاگ شکایت کرتا ہے۔
دور کا ہوسٹ آپ کی سرنگ کے بارے میں کچھ نہیں جانتا
دور کے LAN کے اندر جواب آپ کے کلائنٹ کے نام ایک عام پیکٹ ہے۔ منزل کا ہوسٹ کوئی IPsec ہیڈر نہیں دیکھتا اور VPN گیٹ وے کو ترجیح دینے کی کوئی وجہ نہیں رکھتا؛ وہ آپ کا سابقہ تلاش کرتا ہے، اپنے طے شدہ راستے سے زیادہ مخصوص کچھ نہیں پاتا اور اسی پر چلتا ہے۔ اگر طے شدہ راستہ کسی مرکزی فائر وال کی طرف اشارہ کرے، تو فائر وال کے پاس سرنگ میں واپس جانے کا راستہ ہے یا نہیں۔ نہ ہو تو آپ کو خاموش اخراج، ICMP unreachable، یا ایسا جواب ملتا ہے جو انٹرنیٹ کی طرف والے انٹرفیس سے نکل کر مر جاتا ہے۔
راستہ موجود ہونے کے باوجود دوسرا انٹرفیس اسے توڑنے کے لیے کافی ہے۔ دوسرے VLAN پر مینجمنٹ لنک والا NAS، بیک اپ uplink والا سرور، ایک ماخذ کی حد کو دوسری ٹیبل میں بھیجنے والا پالیسی قاعدہ: ان میں سے کوئی بھی جواب پکڑ سکتا ہے۔ Linux پر، ip rule show اور ip route show table all وہ قواعد اور ٹیبل دکھاتے ہیں جنہیں طے شدہ فہرست چھپاتی ہے۔
فیصلہ جواب بھیجنے والی مشین پر پڑھیں
کچھ بھی بدلنے سے پہلے کرنل سے پوچھیں، اور اسے ماخذ کا پتہ دیں، کیونکہ ماخذ پر منحصر قواعد جواب بدل دیتے ہیں۔
ip route get 10.10.5.10 from 10.20.30.15
ip rule show
ip route show table all
ss -tn state established "( sport = :445 )"آؤٹ پٹ باہر جانے والا انٹرفیس اور اگلا ہاپ بتاتا ہے۔ اگر انٹرفیس وہ نہیں جو VPN گیٹ وے کی طرف ہے، تو آپ کو خرابی مل گئی ہے، اور باقی کام یہ طے کرنا ہے کہ راستہ کہاں ہونا چاہیے۔ گیٹ وے سے کیا گیا ping یہاں کم ثابت کرتا ہے: وہ ایسے پتے سے جواب دیتا ہے جو دور کا ہوسٹ رکھ سکے، آپ کے لیپ ٹاپ کے پتے سے نہیں۔
Windows پر متبادل Find-NetRoute -RemoteIPAddress 10.10.5.10 فیصلے کے لیے اور Get-NetRoute ٹیبل کے لیے ہیں۔ طے شدہ سے زیادہ میٹرک والا New-NetRoute سے شامل کردہ راستہ خاموشی سے ہار جاتا ہے، اس لیے میٹرک کالم پڑھیں، اندراج نہیں۔ پھر پیکٹ سے تصدیق کریں: دور کے LAN انٹرفیس پر tcpdump -ni any "host 10.10.5.10 and tcp port 445" درخواست دکھاتا ہے، اور سرنگ کی طرف وہی فلٹر دکھاتا ہے کہ جواب واپس آیا یا نہیں۔ درخواست نظر آئے مگر جواب نہ ہو تو مطلب جواب کہیں اور روٹ ہوا یا پھینک دیا گیا؛ غلط انٹرفیس پر جواب راستہ چھونے سے پہلے آپ کو مجرم دے دیتا ہے۔
جب سرور کا گیٹ وے VPN کا آخری سرا نہ ہو
بہت سی سائٹس سرورز اور مرکزیت کے آلے کے درمیان فائر وال رکھتی ہیں۔ وہ فائر وال جواب آگے بھیجتی ہے، اس لیے اسے آپ کے کلائنٹ سابقے کے لیے VPN گیٹ وے کی طرف اشارہ کرنے والا راستہ اور دونوں سمتوں میں آگے بھیجنے کی پالیسی درکار ہے۔ حالت رکھنے والے آلات اسے مزید بگاڑتے ہیں: درخواست اس LAN ہوسٹ سے فائر وال پار کر گئی جسے اس نے اجازت دی، جواب اب دوسری سمت سے آتا ہے، اور کنکشن ٹریکنگ کا اندراج اب میل نہیں کھاتا، اس لیے پیکٹ مسترد ہونے کے بجائے ناجائز قرار دے کر پھینک دیا جاتا ہے۔ ٹریفک غائب ہوتے وقت پالیسی لاگ خالی دکھنے کی وجہ یہی ہے۔
گیٹ وے کا اپنا دوسرا فلٹر ہے۔ Linux کی معکوس راستہ فلٹرنگ ان پیکٹوں کو پھینکتی ہے جن کا ماخذ اس انٹرفیس سے قابل رسائی نہیں جس پر وہ آئے، اور یہ کسی جائز غیر متوازن واپسی راستے کی بالکل وہی شکل ہے۔ strongSwan کی آگے بھیجنے کی رہنما ہدایت اسی وجہ سے net.ipv4.ip_forward اور ڈھیلا net.ipv4.conf.all.rp_filter مانگتی ہے۔ کسی بھی گیٹ وے پر سخت قدر 1 درست راستہ خاموشی سے توڑ دیتی ہے، اور اگر جانتے ہوں کہ کہاں دیکھنا ہے تو nstat -az اخراج دکھاتا ہے۔
| Symptom | Where the reply is most likely lost |
|---|---|
| Gateway ping works, LAN host silent | Source address the far host cannot place in its table |
| SYN arrives, no SYN-ACK, tunnel counters flat | No route to the client prefix on the far host or its gateway |
| Reply counted on the internet-facing interface | Default route or policy rule on the far host |
| Firewall reports invalid state | Asymmetric path through a stateful device |
| Worked until a link failed over | New path is asymmetric, or rp_filter now rejects it |
روٹ کریں یا ترجمہ کریں، پھر دونوں سمتوں میں تصدیق کریں
دونوں مرمت برابر نہیں۔ راستہ شامل کرنا کلائنٹ کا پتہ برقرار رکھتا ہے، اس لیے ماخذ پر مبنی قواعد، آڈٹ لاگ اور کال کرنے والے کو ریکارڈ کرنے والی ایپس کام کرتی رہتی ہیں؛ قیمت یہ ہے کہ فیصلہ کرنے والے ہر ہاپ کو راستہ درکار ہوتا ہے، یعنی غلطی کے زیادہ مقامات۔ دور کے گیٹ وے پر ماسکریڈ واپسی راستے کو ایک ہاپ میں سمیٹ دیتا ہے، کیونکہ جواب اب خود گیٹ وے کے نام ہے، اور چھپاتا ہے کہ کس کلائنٹ نے کیا کیا۔
iptables -t nat -A POSTROUTING -o eth1 -s 10.20.30.0/24 -j MASQUERADEاسے سوچ سمجھ کر منتخب کریں: جیسے ہی کلائنٹ گیٹ وے کے پتے کی صورت میں نظر آئیں، ماخذ پر مبنی ACL انہیں الگ پہچاننا چھوڑ دیتے ہیں، اور جواب کو سرنگ میں واپس لکھنے کے لیے conntrack کو نقشہ رکھنا پڑتا ہے۔ اگر سلیکٹر اب بھی کلائنٹ سابقے کو خارج کریں، تو NAT کچھ نہیں بدلتا، کیونکہ درخواست کبھی سرنگ میں داخل نہیں ہوئی۔
اسے درست شدہ کہنے سے پہلے چار چیزیں ترتیب سے طے کریں: جواب بھیجنے والے ہوسٹ پر راستہ، اسے آگے بھیجنے والے ہر ہاپ پر راستہ، دونوں سابقوں کو ڈھکنے والے سلیکٹرز، اور ایسی ریکارڈنگ جو دکھائے کہ جواب آپ کی متوقع ماخذ کے ساتھ سرنگ میں داخل ہو رہا ہے۔ پھر دوسری سائٹ سے آزمائش دہرائیں۔ ایک سمت کا گزرنا آدھا کھلا ڈیزائن ہے، اور دوسری سمت عموماً اس وجہ سے مختلف وجہ سے ناکام ہوتی ہے جو آپ نے ابھی درست کی۔