OpenVPN артындағы Docker және VM трафигі: маршрут па, қайта нөмірлеу ме?

OpenVPN клиенті бар хосттағы контейнерлер мен қонақтар не қайту жолын жоғалтады, не туннель префиксімен соқтығысады. Үш сұрақ шешім таңдайды.

Хост туннель арқылы шолып отыр, ал қасындағы контейнер ештеңеге жетпейді. Өз 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, әр мекенжайға жариялаудың орнына.

Қатысты мақалалар