OpenVPN کے پیچھے Docker اور VM ٹریفک: راستہ یا دوبارہ نمبر؟

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

تین سوال طے کرتے ہیں کہ ان دونوں میں سے کون سی صورت ہے، اور اس میں تقریباً ایک منٹ لگتا ہے۔

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

پہلی واپسی کے راستے کا مسئلہ ہے۔ شائع شدہ پورٹ کنٹینر میں منتقل ہوتا ہے، درخواست پہنچتی ہے، اور جواب میزبان کے طے شدہ راستے سے بھیجا جاتا ہے، جسے OpenVPN کلائنٹ نے tun0 کی طرف موڑ دیا ہے۔ جواب ایسے پتے سے نکلتا ہے جس کی دور دراز ساتھی توقع نہیں کرتا، اور اسے گرا دیا جاتا ہے۔ دوسری سابقے کا ٹکراؤ ہے: Docker کا طے شدہ بریج 172.17.0.0/16 رکھتا ہے اور کارپوریٹ سرنگ وہی رینج دھکیلتی ہے۔

ایک روٹنگ ٹیبل سے ٹھیک ہوتا ہے، دوسرا بریج کو دوبارہ نمبر دے کر۔ یہ جاننے سے پہلے ترمیم کرنا کہ کون سا کون سا ہے، چل رہے کنٹینر کو توڑنے کا طریقہ ہے۔

تین سوالوں سے فیصلہ کریں

پہلا سوال: کیا VPN بند کرنے پر خرابی ختم ہو جاتی ہے؟ اگر سرنگ بند ہونے پر سب کچھ چلتا ہے تو واپسی کے راستے پر شک کریں۔ دوسرا سوال: کیا ip route show table all وہی سابقہ دو بار درج کرتا ہے، ایک بار بریج پر اور ایک بار tun0 پر؟ یہی ٹکراؤ ہے۔ تیسرا سوال: متاثرہ پتہ کنٹینر ہے، NAT مہمان ہے یا بریج کیا گیا مہمان؟

تیسرا سوال اہم ہے کیونکہ ہر ایک کا الگ درست حل ہے، اور کنٹینر کا حل libvirt مہمان پر لگانا ایک شام ضائع کرتا ہے۔

ip route
ip route show table all | grep -E '172\.1[7-9]|10\.8'
docker network inspect bridge --format '{{.IPAM.Config}}'

واپسی کا راستہ: ایک ذریعہ پتے کے لیے ٹیبل

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

ip rule add from 172.22.0.3 lookup 10
ip route add default via 172.22.0.1 table 10

ہر وہ پیکٹ جس کا ذریعہ وہ پتہ ہو، پہلے ٹیبل 10 دیکھتا ہے، اور ٹیبل 10 اسے سرنگ کے بجائے بریج کے گیٹ وے پر بھیجتا ہے۔

اس سے تصدیق کریں: ip route get 1.1.1.1 from 172.22.0.3۔ جواب میں بریج انٹرفیس کا نام ہونا چاہیے، tun0 نہیں۔ اس طرح شامل کیے گئے قواعد ری بوٹ پر ختم ہو جاتے ہیں، اس لیے انہیں اس unit یا نیٹ ورک ہک میں رکھیں جو کنٹینر کا مالک ہے۔

یہی نمونہ WireGuard کنٹینر کے لیے بھی کام کرتا ہے، جہاں جوابی راستے کو بھی واضح قاعدہ درکار ہوتا ہے۔

سابقے کا ٹکراؤ: بریج کو دوبارہ نمبر دیں

روٹنگ ٹیبل ایک سابقہ ایک ہی جگہ بھیجتا ہے۔ اگر VPN 172.17.0.0/16 دھکیلتا ہے جبکہ Docker کا بریج پہلے سے وہاں ہے، تو کم میٹرک جیتتی ہے: Docker اپنا منسلک راستہ میٹرک 0 پر رکھتا ہے، اور دھکیلا گیا راستہ 50 پر آتا ہے۔ تب Docker کے چلتے رہنے پر بھی سرنگ ٹوٹی ہوئی دکھتی ہے، یا اس کے برعکس، تنصیب کی ترتیب کے مطابق۔ میٹرک سے لڑنے کے بجائے بریج کو دوبارہ نمبر دیں۔

{
  "bip": "10.200.0.1/24",
  "default-address-pools": [{"base": "10.201.0.0/16", "size": 24}]
}

تبدیلی کے بعد Docker دوبارہ شروع کریں اور پرانے تالاب سے بنے نیٹ ورک دوبارہ بنائیں۔ اس کے بجائے میٹرک بدلنا صرف تصادم کو اگلی بوٹ پر منتقل کرتا ہے۔

VM کو پھر سے دوسرا جواب درکار ہے

طے شدہ NAT نیٹ ورک پر libvirt مہمان میزبان کی روٹنگ ورثے میں لیتا ہے اور جیسے ہی میزبان کی سرنگ طے شدہ راستے کی مالک ہوتی ہے، باہر پہنچنا بند کر دیتا ہے۔ مہمان کو بریج یا macvtap ڈیوائس پر منتقل کرنا اسے جسمانی نیٹ ورک پر اپنا راستہ دیتا ہے۔ virt-manager میں ہارڈ ویئر شامل کریں، Network منتخب کریں، ماخذ کو macvtap میزبان ڈیوائس پر رکھیں، ماڈل کے طور پر virtio رکھیں، پھر پرانا NAT انٹرفیس غیر فعال کریں۔

macvtap مہمان عام طور پر اپنے میزبان تک نہیں پہنچ سکتا۔ یہ خرابی نہیں بلکہ متوقع رویہ ہے، اور یہ اس نوٹ میں ہونا چاہیے جو آپ چھوڑتے ہیں۔

جس مہمان کو صرف میزبان کا LAN درکار ہو، اس کے لیے وینڈر کے کلائنٹ میں گمشدہ سوئچ ہو سکتا ہے: Mullvad کے ساتھ mullvad lan set allow libvirt کو چھوئے بغیر مقامی رسائی بحال کرتا ہے۔ اور جب کنٹینر صرف سرنگ کے ذریعے قابل رسائی ہونا چاہیے، تو شائع شدہ پورٹ کو سرنگ کے پتے سے باندھیں، -p 10.8.0.5:8080:8080، ہر پتے پر شائع کرنے کے بجائے۔