OpenVPN orqasidagi Docker va VM trafiki: marshrutmi yoki qayta raqamlashmi?

Xost tunnel orqali ko‘rib chiqadi, yonidagi konteyner esa hech narsaga yetib bormaydi. O‘z VPN mijozini ishga tushirgan konteynerdan port e’lon qilish undan ham yomon: so‘rov keladi, javob esa hech qachon chiqmaydi. Ikkalasi ham xostdagi marshrutlash qarorlari, Docker esa faqat xabarchi.

Ushbu ikki holatdan qaysi biri ekanini uch savol aniqlaydi va taxminan bir daqiqa oladi.

Bir xil ko‘rinadigan ikki nosozlik

Birinchisi — qaytish yo‘li muammosi. E’lon qilingan port konteynerga tarjima qilinadi, so‘rov keladi, javob esa xostning standart marshruti orqali yuboriladi, uni OpenVPN mijozi tun0 ga yo‘naltirgan. Javob uzoq tomon kutmagan manzildan chiqadi va tashlab yuboriladi. Ikkinchisi — prefikslar to‘qnashuvi: Dockerning standart ko‘prigi 172.17.0.0/16 ga ega, korporativ tunnel esa xuddi shu diapazonni itarib yuboradi.

Biri marshrut jadvali bilan, ikkinchisi ko‘prikni qayta raqamlash bilan tuzatiladi. Qaysi biri qaysi ekanini bilmasdan tahrir qilish — ishlab turgan konteynerni buzishning yo‘li.

Uch savol bilan qaror qiling

Birinchi savol: VPN to‘xtatilganda nosozlik yo‘qoladimi? Tunnel o‘chirilganda hammasi ishlasa, qaytish yo‘lidan shubhalaning. Ikkinchi savol: ip route show table all o‘sha prefiksni ikki marta, bir marta ko‘prikda va bir marta tun0 da ko‘rsatadimi? Bu — to‘qnashuv. Uchinchi savol: zararlangan manzil konteynermi, NAT mehmonmi yoki ko‘prikka ulangan mehmonmi?

Uchinchi savol muhim, chunki har birining to‘g‘ri tuzatishi boshqacha, konteyner tuzatishini libvirt mehmoniga qo‘llash esa bir oqshomni behuda o‘tkazadi.

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

Qaytish yo‘li: bitta manba manzili uchun jadval

Konteyner trafigi jismoniy interfeysdan chiqishi kerak bo‘lsa, xostning o‘zi tunneldan foydalanayotgan bo‘lsa, manbaga asoslangan marshrutlash eng kichik o‘zgarishdir. Konteyner manziliga mos qoida qo‘shing va uni alohida jadvalga yuboring. Xostda boshqa hech narsa qimirlamaydi.

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

Manbasi o‘sha manzil bo‘lgan har bir paket avval 10-jadvalni ko‘radi, 10-jadval esa uni tunnel o‘rniga ko‘prik shlyuziga yuboradi.

Buni quyidagi bilan tasdiqlang: ip route get 1.1.1.1 from 172.22.0.3. Javob ko‘prik interfeysini nomlashi kerak, tun0 ni emas. Shu tarzda qo‘shilgan qoidalar qayta yuklashda yo‘qoladi, shuning uchun ularni konteynerga tegishli unit yoki tarmoq ilgagiga joylang.

Xuddi shu naqsh WireGuard konteyneri uchun ham ishlaydi, u yerda ham javob yo‘li aniq qoidani talab qiladi.

Prefikslar to‘qnashuvi: ko‘prikni qayta raqamlang

Marshrut jadvali bitta prefiksni bitta joyga yuboradi. Agar VPN 172.17.0.0/16 ni itarib yuborsa, Docker ko‘prigi allaqachon o‘sha yerda bo‘lsa, pastroq metrika yutadi: Docker o‘z ulangan marshrutini 0 metrika bilan o‘rnatadi, itarilgan marshrut esa 50 bilan keladi. Shunda Docker ishlashda davom etganda tunnel buzilgandek ko‘rinadi yoki aksi, o‘rnatish tartibiga qarab. Metrika bilan kurashish o‘rniga ko‘prikni qayta raqamlang.

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

O‘zgarishdan keyin Docker ni qayta ishga tushiring va eski hovuz bilan qurilgan tarmoqlarni qaytadan yarating. Buning o‘rniga metrikani o‘zgartirish faqat mojaroni keyingi yuklashga ko‘chiradi.

VM larga yana boshqacha javob kerak

Standart NAT tarmog‘idagi libvirt mehmoni xostning marshrutlashini meros oladi va xost tunneli standart marshrutga ega bo‘lgach tashqariga chiqishni to‘xtatadi. Mehmonni ko‘prik yoki macvtap qurilmasiga o‘tkazish unga jismoniy tarmoqda o‘z yo‘lini beradi. virt-manager da apparat qo‘shing, Network ni tanlang, manbani macvtap xost qurilmasiga qo‘ying, model sifatida virtio ni saqlang, so‘ng eski NAT interfeysini o‘chiring.

macvtap mehmoni odatda o‘z xostiga yetib bora olmaydi. Bu nosozlik emas, kutilgan xatti-harakat, va u siz qoldiradigan eslatmaga kirishi kerak.

Faqat xostning LAN i kerak bo‘lgan mehmon uchun sotuvchining mijozida yetishmayotgan kalit bo‘lishi mumkin: Mullvad bilan mullvad lan set allow libvirt ga tegmasdan mahalliy yetib borishni tiklaydi. Va konteyner faqat tunnel orqali yetib boriladigan bo‘lishi kerak bo‘lsa, e’lon qilingan portni tunnel manziliga bog‘lang, -p 10.8.0.5:8080:8080, har bir manzilda e’lon qilish o‘rniga.