ریموٹ صارفین VPN ہب کے ذریعے دوسری سائٹ تک نہیں پہنچ پاتے

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

گزرنے کے لیے تین تلاشیں درکار ہیں، ایک سرنگ نہیں

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

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

دور کے سابقے کو ریموٹ کلائنٹ کی طرف دھکیلیں

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

push "route 10.20.0.0 255.255.255.0"

دھکیلا گیا راستہ کلائنٹ کے جڑنے پر نافذ ہوتا ہے، اس لیے آن لائن رہنے والا صارف دوبارہ جڑنے تک کچھ نہیں دیکھتا۔ کلائنٹ پر جانچیں: Linux پر ip route get 10.20.0.50، Windows پر route print۔ آؤٹ پٹ میں سرنگ انٹرفیس کا نام ہونا چاہیے۔

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

ہب کو حقیقی اخراجی راستہ دیں

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

ip route get 10.20.0.50 from 10.80.0.25
sudo ip route add 10.20.0.0/24 via 172.30.0.2 dev s2s0

جہاں سائٹ ٹو سائٹ حصہ خود OpenVPN ہے، وہاں راستہ اسی ترتیب میں ساتھی کے سرنگ پتے کو گیٹ وے بنا کر رہ سکتا ہے: route 10.20.0.0 255.255.255.0 172.30.0.2۔ گیٹ وے اختیاری نہیں۔ اسے چھوڑ دیں تو اگلی ہاپ عمل درآمد کے ڈیفالٹ پر گر جاتی ہے، جو یک طرفہ ریموٹ کلائنٹ اور متعدد ساتھیوں والے ہب میں مختلف ہے۔

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

دور والے جانب کو صارفین کے پول تک بڑھائیں

صدر دفتر پہلے ہی ہب کے LAN، 10.10.0.0/24 کا احاطہ کرتا ہے۔ صارفین کا پول دوسرا سابقہ ہے اور اسے سلیکٹرز میں بھی ہونا چاہیے، ورنہ کوئی پالیسی 10.80.0.25 کو بھیجے گئے جواب کا احاطہ نہیں کرتی۔ ہر ساتھی اپنی طرف سے سابقہ مجموعوں کی وہی جوڑی بتاتا ہے:

# strongSwan swanctl.conf, on the hub
local_ts  = 10.10.0.0/24, 10.80.0.0/24
remote_ts = 10.20.0.0/24

# on the headquarters peer
local_ts  = 10.20.0.0/24
remote_ts = 10.10.0.0/24, 10.80.0.0/24

ایک آلے کا local_ts دوسرے کا remote_ts ہے۔ ہب کا بلاک صدر دفتر پر کاپی کریں اور جوڑی الٹ جاتی ہے، اس لیے چائلڈ SA کبھی اوپر نہیں آتا۔

پرانی ipsec.conf ترکیب کوما سے الگ کردہ leftsubnet استعمال کرتی ہے۔ فعال سیکیورٹی ایسوسی ایشن وہ سلیکٹر رکھتی ہے جن پر گفت و شنید کی، اس لیے ترمیم کے بعد سرنگ دوبارہ قائم کریں۔ 10:00 پر بدلا گیا سلیکٹر 09:40 پر اوپر آئے SA کے خلاف جانچنے پر بھی ناکام ہوتا ہے، جبکہ کنفگ فائل پورے وقت درست دکھائی دیتی ہے۔

پھر آخری ہاپ جانچیں۔ دور والے سرے پر ip route get 10.80.0.25 سرنگ کی طرف اشارہ کرنا چاہیے۔ اگر سروس LAN روٹر کو اپنا ڈیفالٹ گیٹ وے بناتی ہے، تو اس روٹر کو بھی واپسی راستہ درکار ہے، ورنہ جواب وہیں مر جاتا ہے۔ اس حصے پر tcpdump -ni eth1 host 10.80.0.25 چلانا دکھاتا ہے کہ جواب سرے سے نکلا بھی تھا یا نہیں۔

ہب پر بہاؤ کی اجازت دیں

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

sysctl -w net.ipv4.ip_forward=1
iptables -I FORWARD -i tun0 -o s2s0 -s 10.80.0.0/24 -d 10.20.0.0/24 -j ACCEPT
iptables -I FORWARD -i s2s0 -o tun0 -s 10.20.0.0/24 -d 10.80.0.0/24 -j ACCEPT

ریورس پاتھ فلٹرنگ اس کے ساتھ والی خاموش ناکامی ہے: جب دونوں ٹانگیں الگ انٹرفیس پر ہوں، rp_filter=1 جواب گرا سکتا ہے جبکہ قبولیت قاعدے کا کاؤنٹر بالکل نہیں ہلتا۔ کسی کوشش سے پہلے اور بعد iptables -vnL FORWARD کا موازنہ کریں۔ جو قاعدہ کبھی نہیں بڑھتا وہاں پہنچا ہی نہیں جاتا، اس لیے اسے دوبارہ لکھنے کی بجائے ایک پرت نیچے دیکھیں۔

اگر صرف ایک گروہ کو گزرنا ہے، تو عالمی push کو وسیع کرنے کی بجائے client-config-dir کے تحت فی کلائنٹ فائل میں راستہ رکھیں۔ ہب پر Source NAT بھی دور والے جانب کے واپسی راستے کی ضرورت ہٹا دیتا ہے، مگر یہ صارف کا پتہ چھپا دیتا ہے، اس لیے دور والی سائٹ کے لاگ اور پتے پر مبنی قواعد صارفین میں فرق کرنا چھوڑ دیتے ہیں۔

کلائنٹ سے جانچیں، پھر الٹی ترتیب میں واپس کریں

صرف ICMP نہیں، TCP پورٹ جانچیں، کیونکہ پنگ گزر سکتا ہے جبکہ سروس بند رہتی ہے۔ کلائنٹ سے nc -vz 10.20.0.50 445 اور traceroute -n 10.20.0.50 دکھاتے ہیں کہ دوسری ہاپ ہب کا سرنگ پتہ ہے یا نہیں۔ ہب پر، tcpdump -ni tun0 host 10.20.0.50 اور سائٹ ٹو سائٹ انٹرفیس پر وہی فلٹر: دونوں پر درخواست مگر کسی پر جواب نہیں، مسئلہ دور والے جانب منتقل کر دیتا ہے۔

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

واپسی کی فہرست رکھیں، کیونکہ چار اشیاء بدلی ہیں اور تین بھولنا آسان ہے: دھکیلا گیا راستہ، ہب کا راستہ، سلیکٹرز اور فائر وال قواعد۔ انہیں الٹی ترتیب میں واپس لیں، SA دوبارہ قائم کریں، اور ایک صارف کو دوبارہ جڑنے دیں۔ جزوی واپسی ایسا راستہ چھوڑ دیتی ہے جو اب نہ ملنے والی سرنگ کی طرف اشارہ کرتا ہے، اور اسے پڑھنا اصل خاموشی سے مشکل ہے۔ OpenVPN 2.6 کا دستورالعمل آپ کے ورژن کے لیے push، route اور iroute کی دستاویز کرتا ہے۔