Promet Dockerja in VM za OpenVPN: usmerjati ali preštevilčiti?

Gostitelj brska skozi tunel, vsebnik ob njem pa ne doseže ničesar. Objavljanje vrat iz vsebnika, ki poganja lastnega odjemalca VPN, je slabše: zahteva prispe in odgovor nikoli ne odide. Oboje so odločitve o usmerjanju na gostitelju, Docker pa je le sel.

Kateri od obeh primerov je pred vami, odločijo tri vprašanja, in traja približno minuto.

Dve okvari, ki izgledata enako

Prva je težava s povratno potjo. Objavljena vrata se prevedejo v vsebnik, zahteva prispe, odgovor pa se usmeri po privzeti poti gostitelja, ki jo je odjemalec OpenVPN usmeril na tun0. Odgovor odide z naslova, ki ga oddaljeni partner ne pričakuje, in se zavrže. Druga je trk predpon: privzeti most Dockerja ima 172.17.0.0/16, podjetniški tunel pa potiska isto območje.

Eno se popravi s tabelo usmerjanja, drugo s preštevilčenjem mostu. Urejati, preden veste, katera je katera, je način, kako pokvariti delujoč vsebnik.

Odločite se s tremi vprašanji

Prvo vprašanje: ali okvara izgine, ko ustavite VPN? Če ob izklopljenem tunelu vse deluje, sumite na povratno pot. Drugo vprašanje: ali ip route show table all navaja isto predpono dvakrat, enkrat na mostu in enkrat na tun0? To je trk. Tretje vprašanje: je prizadeti naslov vsebnik, gost NAT ali gost v mostu?

Tretje vprašanje je pomembno, ker ima vsak drugačen pravilen popravek, uporaba popravka za vsebnik na gostu libvirt pa zapravi večer.

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

Povratna pot: tabela za en naslov vira

Ko mora promet vsebnika oditi skozi fizični vmesnik, medtem ko gostitelj sam uporablja tunel, je usmerjanje glede na vir najmanjša sprememba. Dodajte pravilo, ki se ujema z naslovom vsebnika, in ga pošljite v namensko tabelo. Nič drugega na gostitelju se ne premakne.

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

Vsak paket, katerega vir je ta naslov, najprej pogleda tabelo 10, tabela 10 pa ga pošlje na prehod mostu namesto v tunel.

Potrdite z ip route get 1.1.1.1 from 172.22.0.3. Odgovor mora navesti vmesnik mostu, ne tun0. Tako dodana pravila ob ponovnem zagonu izginejo, zato jih vstavite v enoto ali omrežno kljuko, ki ima vsebnik.

Isti vzorec deluje za vsebnik WireGuard, kjer tudi povratna pot potrebuje izrecno pravilo.

Trk predpon: preštevilčite most

Tabela usmerjanja pošlje eno predpono na eno mesto. Če VPN potiska 172.17.0.0/16, medtem ko je most Dockerja že tam, zmaga nižja metrika: Docker namesti svojo povezano pot z metriko 0, potisnjena pot pa prispe s 50. Takrat je tunel videti pokvarjen, medtem ko Docker še deluje, ali obratno, odvisno od vrstnega reda namestitve. Preštevilčite most, namesto da bi se borili z metriko.

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

Po spremembi znova zaženite Docker in znova ustvarite omrežja, zgrajena s starim skladom. Spreminjanje metrike le premakne konflikt na naslednji zagon.

VM potrebujejo spet drugačen odgovor

Gost libvirt v privzetem omrežju NAT podeduje usmerjanje gostitelja in preneha dosegati zunanjost, ko tunel gostitelja prevzame privzeto pot. Preklop gosta na most ali napravo macvtap mu da lastno pot v fizičnem omrežju. V virt-managerju dodajte strojno opremo, izberite Network, nastavite vir na gostiteljsko napravo macvtap, obdržite virtio kot model in nato deaktivirajte stari vmesnik NAT.

Gost macvtap običajno ne more doseči svojega gostitelja. To je pričakovano vedenje in ne okvara, zato sodi v zapisek, ki ga pustite.

Za gosta, ki potrebuje le LAN gostitelja, ima odjemalec ponudnika morda manjkajoče stikalo: z Mullvadom mullvad lan set allow obnovi lokalno dosegljivost, ne da bi se dotaknil libvirta. In ko mora biti vsebnik dosegljiv le skozi tunel, privežite objavljena vrata na naslov tunela, -p 10.8.0.5:8080:8080, namesto da bi jih objavljali na vsakem naslovu.