OpenVPN کا مکمل ٹنل آپ کا SSH سیشن کاٹ دیتا ہے: واپسی کا راستہ درست کریں

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

VPN لاگ پڑھنے سے پہلے روٹنگ ٹیبل پڑھیں۔ لاگ کہے گا کہ ٹنل اوپر آ گیا، اور یہ درست ہے۔ سوال یہ ہے کہ ہر جواب کس انٹرفیس کو دیا جاتا ہے، اور یہ اُس ٹیبل میں ہر پیکٹ کے لیے تلاش ہے جو ٹنل نے ابھی دوبارہ لکھا ہے۔

جواب غلط دروازے سے کیوں نکلتا ہے

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

OpenVPN کی اپنی حفاظت بالکل ایک منزل کو ڈھکتی ہے۔ 2.6 کی دستی --redirect-gateway کو ایک ترتیب کے طور پر بیان کرتی ہے: یہ ٹنل سے پہلے استعمال ہونے والے گیٹ وے کے ذریعے VPN peer کے لیے ہوسٹ روٹ شامل کرتی ہے، تاکہ خفیہ کردہ ٹریفک اپنے اندر واپس نہ جا سکے، اور پھر ڈیفالٹ روٹ بدل دیتی ہے۔ وہ ہوسٹ روٹ صرف peer کے لیے ہے۔ آپ کا SSH کلائنٹ محض ایک اور انٹرنیٹ پتہ ہے اور کوئی استثنا نہیں پاتا۔

ایک سابقہ غلطی کو جلدی خارج کرنا بہتر ہے۔ لمبائی کے بغیر ip route add -net 0.0.0.0 gw 10.8.0.1 dev tun0 صرف ایک پتے 0.0.0.0 سے مماثل ہے، انٹرنیٹ سے نہیں؛ اسے 0.0.0.0/0 ہونا چاہیے۔ اور اگر ڈیفالٹ لینا ٹنل کی اپنی ترسیل توڑ دے، تو اینڈ پوائنٹ کو فزیکل انٹرفیس کے ذریعے ہوسٹ روٹ کے طور پر شامل کریں, فراہم کنندہ کے اصل پتے کا استعمال کرتے ہوئے۔

فوری مرمت کے لیے اپنے SSH کلائنٹ کا پتہ پن کریں

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

curl -s https://ifconfig.co
ip route

سرور پر، کلائنٹ شروع ہونے سے پہلے استثنا شامل کریں۔ یہاں پتے پلیس ہولڈر ہیں؛ شکل اہم ہے:

sudo ip route add 80.128.240.55 via 192.168.178.1

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

کلائنٹ کو ڈیفالٹ روٹ لینے سے روکیں

زیادہ صاف آپشن یہ ہے کہ ٹنل کو ڈیفالٹ روٹ بالکل بدلنے نہ دیا جائے۔ route-nopull، --client یا --pull کے ساتھ استعمال ہونے پر، روٹس، block-outside-dns اور DNS سرورز جیسے DHCP طرز کے آپشنز کے سوا دھکیلے گئے آپشنز قبول کرتا ہے، لہٰذا آپ صرف ضروری سابقے شامل کرتے ہیں۔ زیادہ تنگ اوزار پل فلٹر ہے، جو ایک مسئلہ والی ہدایت خارج کرتا ہے اور باقی رکھتا ہے:

route-nopull
pull-filter ignore "redirect-gateway"

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

واپسی کا راستہ ماخذ یا کنکشن کے مطابق تقسیم کریں

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

ip rule add from 192.168.1.11 table 128
ip route add table 128 to 192.168.1.0/24 dev eth0
ip route add table 128 default via 192.168.1.1

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

iptables -t mangle -A PREROUTING -i eth0 -m conntrack --ctstate NEW -j CONNMARK --set-mark 1234
iptables -t mangle -A OUTPUT -m connmark --mark 1234 -j MARK --set-mark 4321
ip route add default via 192.168.1.1 dev eth0 table 3412
ip rule add fwmark 4321 table 3412

جانچ کے دوران کنکشن نشان، فائر وال نشان اور ٹیبل نمبر الگ رکھیں۔ ایک نمبر کو دو کرداروں کے لیے دوبارہ استعمال کرنا ایسا قاعدہ بناتا ہے جو درست دکھتا ہے اور غلط پیکٹوں پر لگتا ہے۔ ٹیبل کے ڈیفالٹ اندراج کو عام ایتھرنیٹ لنک پر LAN گیٹ وے کے ساتھ via بھی درکار ہے؛ ننگا dev eth0 صرف اُس وقت کام کرتا ہے جب انٹرفیس پوائنٹ ٹو پوائنٹ ہو یا اگلی چھلانگ کسی اور طریقے سے حل ہو۔ رپورٹ شدہ Jessie ہوسٹ اتفاقاً ایسے لنک پر تھا جہاں ننگا روپ کام کرتا تھا، اور یہ نقل کرنے کے قابل کوئی تقسیمی قاعدہ نہیں ہے۔

باہر تالا لگائے بغیر تصدیق کریں

ڈسکنیکٹ کر کے جانچ نہ کریں۔ پہلا سیشن کھلا رکھیں، ٹنل اوپر لائیں، اور کرنل سے پوچھیں کہ آپ کا اپنا پتہ کون سا راستہ لے گا:

ip route get 80.128.240.55

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

پوری مشق کے دوران بینڈ سے باہر کنسول دستیاب رکھیں۔ جس سرور کا واحد رسائی راستہ وہی ٹنل ہے جو آپ نے ابھی توڑا، اُسے اُسی ٹنل سے درست نہیں کیا جا سکتا، اور اگر آپ شامل کیے گئے ٹیبل نمبر اور سابقے لکھ لیں تو واپس پلٹانا آسان ہوتا ہے۔