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

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

پہلا مرحلہ: کلائنٹ کے روٹنگ فیصلے کو دیکھیں

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

ip route get 192.168.50.10

اگر جواب آپ کے فزیکل ایڈاپٹر اور دفتر کے گیٹ وے کا نام لے، تو سرور کی طرف کوئی تبدیلی مدد نہیں کر سکتی۔ OpenVPN راستے صرف اُس وقت بانٹتا ہے جب سرور اُنہیں دھکیلتا ہے، سو سرور کنفیگ میں push "route 192.168.50.0 255.255.255.0" تلاش کریں، اور پھر کلائنٹ دوبارہ منسلک کریں۔ زیادہ تر کلائنٹ دھکیلے گئے راستے منسلک ہوتے وقت لاگو کرتے ہیں، پروفائل دوبارہ لوڈ کرنے پر نہیں۔

Windows پر اسی سوال کا دوسرا کمانڈ ہے۔ Find-NetRoute -RemoteIPAddress 192.168.50.10 وہ انٹرفیس اور اگلا ہاپ چھاپتا ہے جو اسٹیک چنے گا، اور route print -4 دکھاتا ہے کہ دھکیلا گیا سابقہ بالکل موجود ہے یا نہیں۔

دوسرا مرحلہ: یقینی بنائیں کہ سرور پیکٹ فارورڈ کرے گا

اگر کلائنٹ راستہ درست ہے تو پیکٹ سرور تک پہنچتا ہے اور سرور کو اُسے فارورڈ کرنے پر راضی ہونا ہوگا۔ کرنل سوئچ پہلا دروازہ ہے، اور sysctl net.ipv4.ip_forward کو 1 واپس دینا ہوگا۔ echo 1 > /proc/sys/net/ipv4/ip_forward سے اسے سیٹ کرنا اگلی ری بوٹ تک چلتا ہے، اور اسی لیے وہی شکایت ہفتوں بعد لوٹ آتی ہے۔

اسے ایسی جگہ لکھیں جو ری اسٹارٹ کے بعد بھی رہے:

echo 'net.ipv4.ip_forward = 1' > /etc/sysctl.d/99-openvpn-forward.conf
sysctl --system

دوسرا دروازہ فلٹر جدول ہے۔ Docker والے میزبان پر اکثر FORWARD پالیسی DROP ہوتی ہے، اور ٹنل وہ فیصلہ ورثے میں لیتا ہے۔ iptables -L FORWARD -v -n پالیسی اور پیکٹ کاؤنٹر دونوں دکھاتا ہے؛ اگر پالیسی DROP ہے تو فارورڈنگ کو ٹنل سے LAN کی سمت کے لیے ایک واضح اجازت اور جواب کے لیے ایک اور چاہیے۔

تیسرا مرحلہ: پیکٹ کو LAN تک ٹریک کریں اور جواب ڈھونڈیں

سرور کے دونوں رخ ایک ساتھ دیکھیں۔ ٹنل پر اور LAN انٹرفیس پر کیپچر کریں، ایک کلائنٹ اور ایک میزبان پر فلٹر کر کے تاکہ آؤٹ پٹ پڑھنے کے قابل رہے:

tcpdump -ni tun0 host 192.168.50.10
tcpdump -ni eth0 host 192.168.50.10

جو درخواستیں tun0 پر اور پھر eth0 پر 10.8.0.x ماخذ کے ساتھ ظاہر ہوتی ہیں، اور اُن کے بعد خاموشی آتی ہے، اُن کا مطلب ہے کہ پیکٹ پہنچ گیا اور جواب کہیں اور چلا گیا۔ LAN میزبان اپنے ڈیفالٹ گیٹ وے کو جواب دیتا ہے، اُس گیٹ وے کے پاس VPN پول کے لیے راستہ نہیں، اور جواب LAN راؤٹر پر دم توڑ دیتا ہے۔ سرور سے LAN میزبان کو ping کرنا اس راستے کے بارے میں کچھ ثابت نہیں کرتا، کیونکہ وہ ٹریفک کبھی ٹنل عبور نہیں کرتا۔

چوتھا مرحلہ: ترجمے اور واپسی راستے کے درمیان انتخاب کریں

دو مرمتیں سوراخ بند کرتی ہیں، اور اس انتخاب کے نتائج ping چلنے سے آگے جاتے ہیں۔ ماخذ ترجمہ سرور کو ظاہری بھیجنے والا بناتا ہے:

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

قاعدے کو پول اور LAN انٹرفیس تک محدود کریں، پھر اسے مستقل کریں، ورنہ اگلی فائر وال ری لوڈ آپ کی مرمت خاموشی سے ہٹا دے گی۔ قیمت شناخت ہے: LAN لاگز اور رسائی قواعد میں ہر کلائنٹ VPN سرور جیسا دکھتا ہے، اور per-client policy becomes guesswork۔

LAN راؤٹر پر VPN سرور کی طرف اشارہ کرنے والا 10.8.0.0/24 کا مستقل راستہ کلائنٹ پتے نظر آتے رکھتا ہے اور جب وہ راؤٹر آپ کا ہو تو یہ بہتر طویل مدتی جواب ہے۔ بہت سی سائٹیں کچھ وقت دونوں چلاتی ہیں، فوری مرمت کے لیے NAT اور فائر وال پالیسی لکھے جانے کے بعد راستہ۔ اگر سرور پول کے بجائے سائٹ سے سائٹ ساتھی ہو، تو سرور کی طرف بھی دور دراز سب نیٹ کے لیے iroute درکار ہے، ورنہ ساتھی کا راستہ موجود ہے مگر کلائنٹ ٹریفک کبھی اُس سے منسلک نہیں ہوتا۔

پانچواں مرحلہ: کلائنٹ سے تصدیق کریں اور لکھیں کہ کیا بدلا

حلقہ سرور سے نہیں، کلائنٹ سے بند کریں۔ LAN میزبان پر کسی حقیقی سروس سے منسلک ہوں، پھر تصدیق کریں کہ ترجمے کے کاؤنٹر iptables -t nat -L POSTROUTING -v -n سے آگے بڑھے ہیں، کیونکہ صفر پیکٹ والا قاعدہ وہ قاعدہ ہے جو کبھی ملا نہیں۔ جب آپ کو ثبوت چاہیے کہ واپسی سمت ٹریک ہو رہی ہے، تو conntrack -L -s 10.8.0.5 بہاؤ اور اُس کی حالت دکھاتا ہے۔

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