De host bliedt troch de tunnel en de kontener derneist berikt neat. In poarte publisearje út in kontener dy't syn eigen VPN-klant draait is slimmer: it fersyk komt oan en it antwurd giet nea fuort. Beide binne rûtbeslissingen op 'e host, en Docker is allinnich de boadskipper.

Trije fragen beslisse hokker fan 'e twa jo sjogge, en se duorje sawat in minút.

Twa flaters dy't der itselde út sjogge

De earste is in probleem mei de weromrûte. In publisearre poarte wurdt nei de kontener oerset, it fersyk komt oan, en it antwurd wurdt rûte troch de standertrûte fan 'e host, dy't de OpenVPN-klant nei tun0 wiisd hat. It antwurd giet fuort fan in adres dat de fiere partner net ferwachtet, en it wurdt weilitten. De twadde is in prefixbotsing: de standertbrêge fan Docker hat 172.17.0.0/16 en in bedriuwsstunnel triuwt itselde berik.

De iene wurdt reparearre mei in rûtetabel, de oare troch in brêge opnij te nûmerjen. Bewurkje foardat jo witte hokker hokker is, is hoe't in wurkjende kontener stikken makke wurdt.

Beslis mei trije fragen

Fraach ien: ferdwynt de flater as jo de VPN stopje? As alles wurket mei de tunnel del, fertink dan de weromrûte. Fraach twa: listet ip route show table all itselde prefix twa kear, ien kear op in brêge en ien kear op tun0? Dat is de botsing. Fraach trije: is it oanpaste adres in kontener, in NAT-gast of in oerbrêge gast?

De tredde fraach is wichtich om't elk in oare juste oplossing hat, en de konteneroplossing tapasse op in libvirt-gast fergriemt in jûn.

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

Weromrûte: in tabel foar ien boarne-adres

As it ferkear fan 'e kontener troch de fysike interface nei bûten moat wylst de host sels de tunnel brûkt, boarnebasearre rûte is de lytste feroaring. Foegje in regel ta dy't by it adres fan 'e kontener past en stjoer it nei in wijd tabel. Neat oars op 'e host beweecht.

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

Elk pakket wêrfan't de boarne dat adres is, besjocht earst tabel 10, en tabel 10 stjoert it nei de gateway fan 'e brêge ynstee fan de tunnel.

Befêstigje mei ip route get 1.1.1.1 from 172.22.0.3. It antwurd moat de brêge-interface neame, net tun0. Regels dy't sa tafoege wurde, ferdwine by it opnij opstarten, dus set se yn 'e unit of netwurkhook dy't de kontener hat.

Itselde patroan wurket foar in WireGuard-kontener, dêr't de antwurd-rûte ek in eksplisite regel nedich hat.

Prefixbotsing: nûmerje de brêge opnij

In rûtetabel stjoert ien prefix nei ien plak. As de VPN 172.17.0.0/16 triuwt wylst de brêge fan Docker der al is, wint de legere metryk: Docker ynstallearret syn ferbûne rûte op metryk 0, en de triuwde rûte komt oan op 50. Dan liket de tunnel stikken wylst Docker trochwurket, of oarsom, ôfhinklik fan 'e ynstallaasjefolchoarder. Nûmerje de brêge opnij ynstee fan mei de metryk te fjochtsjen.

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

Start Docker opnij nei de feroaring en meitsje netwurken opnij dy't mei de âlde pool boud binne. De metryk feroarje ferpleatst it konflikt allinnich nei de folgjende opstart.

VM's hawwe wer in oar antwurd nedich

In libvirt-gast op it standert NAT-netwurk erft it rûten fan 'e host en hâldt op mei it berikken fan bûten sadree't de tunnel fan 'e host de standertrûte hat. De gast oersette nei in oerbrêge of macvtap-apparaat jout him syn eigen paad op it fysike netwurk. Yn virt-manager foegje jo hardware ta, kies Network, set de boarne op it macvtap-hostapparaat, hâld virtio as model, en skakel dan de âlde NAT-interface út.

In macvtap-gast kin meastentiids syn eigen host net berikke. Dat is ferwachte gedrach en net in flater, en it heart yn 'e notysje dy't jo efterlitte.

Foar in gast dy't allinnich it LAN fan 'e host nedich hat, hat de klant fan 'e leveransier miskien de ûntbrekkende skeakel: mei Mullvad herstelt mullvad lan set allow lokale berikberens sûnder libvirt oan te reitsjen. En as in kontener allinnich troch de tunnel berikber wêze moat, byn de publisearre poarte oan it tunneladres, -p 10.8.0.5:8080:8080, ynstee fan op elk adres te publisearjen.

Relatearre artikelen