Саобраћај Docker-а и VM иза OpenVPN-а: рута или пренумеравање?

Контејнери и гости на хосту са 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-ови опет траже други одговор

libvirt гост на подразумеваној NAT мрежи наслеђује рутирање хоста и престаје да достиже спољашњост када тунел хоста преузме подразумевану руту. Пребацивање госта на мост или macvtap уређај даје му сопствену путању на физичкој мрежи. У virt-manager-у додајте хардвер, изаберите Network, поставите извор на macvtap уређај хоста, задржите virtio као модел, затим деактивирајте стари NAT интерфејс.

macvtap гост обично не може да достигне сопствени хост. То је очекивано понашање, а не квар, и припада белешци коју остављате.

За госта коме треба само LAN хоста, клијент добављача можда има прекидач који недостаје: са Mullvad-ом mullvad lan set allow враћа локалну доступност без дирања libvirt-а. А када контејнер мора да буде доступан само кроз тунел, вежите објављени порт на адресу тунела, -p 10.8.0.5:8080:8080, уместо да га објављујете на свакој адреси.

Повезани чланци