Docker-konttien liikenne ohittaa isäntäkoneen VPN:n: näin tarkistat sen
Isäntäkoneen VPN kattaa vain isäntäkoneen nimiavaruuden. Näillä tarkistuksilla selviää, meneekö sillan konttien liikenne tunneliin vai lähteekö se suoraan ulos.
Isäntäkoneen selain näyttää VPN:n lähtöosoitteen, kontti ilmoittaa kotiyhteytesi ja joku kutsuu sitä vuodoksi. Mitään ei vuotanut. Isäntäkoneen tunneli on joukko liitäntöjä, reittejä ja sääntöjä, jotka kuuluvat isäntäkoneen verkkonimiavaruuteen, ja sillalla oleva kontti on toinen nimiavaruus omalla oletusreitillään. Olen istunut Compose-pinon ääressä, jossa VPN-asiakas oli ollut yhdistettynä viikkoja eikä yksikään kontin paketti ollut koskaan mennyt siihen.
Tarkista nimiavaruus ennen ilmaisinalueen kuvaketta
Nimiavaruudet ovat koko argumentti. Kun Docker käynnistää kontin siltverkossa, se luo verkkonimiavaruuden, liittää veth-parin toisen pään sen sisään ja antaa nimiavaruudelle osoitteen ja oletusreitin. Tunneliliitäntä, miksi sitä sitten kutsutaankin, elää isäntäkoneen nimiavaruudessa. Kontin sisällä oleva liikenne ei näe sitä, eikä mikään asiakasohjelman asetus muuta sitä ulkopuolelta.
Kaksi tuettua siirtoa vievät sinut eristyksestä. --network host sijoittaa kontin isäntäkoneen nimiavaruuteen, joten se perii isäntäkoneen reitit ja siten tunnelin. --network container:vpn jakaa toisen kontin nimiavaruuden, ja näin useimmat sidecar-ratkaisut lähettävät työkuorman VPN-kontin kautta. Molemmat ovat nimenomaisia valintoja; yleensä vain toinen niistä on se, mitä käyttöönottaja tarkoitti.
Isäntätila ei ole ilmainen päivitys. Kontti lakkaa omistamasta omaa osoitettaan, porttien julkaisu lakkaa päten ja prosessi, jolla on siellä NET_ADMIN, voi kirjoittaa isäntäkoneen reitityksen uudelleen. Sen hyväksyminen voi olla oikea päätös. Sen olettaminen jo päälle kytketyksi on se tapa, jolla ihmiset viettävät illan selvittäen tunnelia, joka ei koskaan ollut reitillä.
Seuraa pakettia sillalta pois
Sillalla oleva kontti lähettää pakettinsa oletusyhdyskäytävälleen, joka on isäntäkoneen siltaliitäntä. Sitten isäntäkone välittää paketin ja kääntää oletusasetuksissa lähdeosoitteen omakseen ennen kuin paketti lähtee. Juuri tuo käännösvaihe kumoaa käytännön hiljaa.
Kun paketti saapuu tunnelin päätepisteeseen, se kantaa isäntäkoneen osoitetta. Mikä tahansa sääntö, käytäntöreitti tai jaetun tunnelin päätös, joka perustuu kontin alkuperäiseen osoitteeseen, lakkaa täsmäämästä, eikä kahta eri uloskäynneistä lähteväksi tarkoitettua konttia voi erottaa pelkän lähteen perusteella. Jos tarvitset reititystä konttikohtaisesti, päätös on tehtävä ennen käännöstä tai nimiavaruudessa, jota hallitset.
Docker ylläpitää nämä säännöt itse, millä tahansa palomuuritaustalla daemon on määritetty. Käsin kirjoitetut säännöt välitetyn liikenteen tuetun koukun ulkopuolella, DOCKER-USER, voidaan järjestää uudelleen tai pudottaa, kun daemon käynnistyy uudelleen tai isäntäkone päivitetään. Dockerin pakettien suodatusta koskeva dokumentaatio näyttää ketjujen järjestyksen; käytännön pointti on, että jokainen sääntö tarvitsee omistajan ja uudelleenlatauspolun, jota olet oikeasti testannut.
Testaa kahta järjestelmää erikseen
Todisteet yhdestä nimiavaruudesta eivät kerro toisesta mitään. VPN-kontin sisällä ajettu pyyntö todistaa, että tunneli toimii kyseiselle kontille. Se ei ole todiste isäntäkoneesta, eikä sama komento --network host-kontista ole todiste sillasta.
# host namespace
ip route get 1.1.1.1
ip -brief addr show
# a fresh container on the same bridge network
docker run --rm --network appnet alpine sh -c 'ip route; cat /etc/resolv.conf; ip -6 route'Toista sitten testi varsinaisen sovelluskontin sisällä eikä samankaltaisessa imagessa. Sovellus voi kantaa ylimääräistä reittiä, välityspalvelimen ympäristömuuttujaa tai erilaista resolveria, ja jokainen niistä muuttaa vastausta. Tarkista nimien selvitys ja toinen osoiteperhe joka kerta: käyttäjän määrittämillä silloilla olevat kontit selvitetään Dockerin sisäänrakennetun resolverin kautta osoitteessa 127.0.0.11, ja sillan IPv6-oletusreitti voi viedä liikennettä ulos, kun olet kiireinen testaamassa vain IPv4-tunnelia.
Lue kuvio ennen kuin kosket tunnistetietoja
Kun isäntäkone toimii ja kontti ei, syy on lähes aina rakenteellinen, ja avainten vaihtaminen tai asiakasohjelman uudelleenasennus tuhlaa iltapäivän. Lajittele ensin oire, ja korjaus nimeää yleensä itsensä.
| What you see | Usual cause | First check |
|---|---|---|
| Host exits through the VPN, container shows the ISP address | The container never entered the tunnel | Default route inside the container |
| Container works until the daemon restarts, then stops | Rules outside the supported hook, or a changed backend | Daemon's reported firewall backend and DOCKER-USER |
| Container loses internal hosts after the tunnel comes up | VPN prefix overlaps the Docker bridge subnet | ip route on the host, then docker network inspect |
| Small replies arrive, large ones hang | Tunnel MTU or missing MSS clamping | Link MTU on both ends of the tunnel |
| Container falls back to the ISP address when the tunnel drops | Nothing enforces the kill switch for forwarded traffic | Stop the tunnel with a request in flight |
Päällekkäisyysrivi ansaitsee oman lauseensa. VPN-profiili, joka työntää reitin 172.17.0.0/16:lle tai 10.0.0.0/8:lle, joka sattuu sisältämään siltasi etuliitteen, saa tunnelin vaatimaan konttien aliverkon, ja käännetyille osoitteille menevät vastaukset lähtevät väärään suuntaan tai katoavat. Docker-verkon uudelleennumerointi on yleensä siistimpää kuin poikkeusten kerääminen.
Tee kattavuudesta nimenomainen ja riko se sitten tahallasi
Kaksi suunnittelua kestää tarkastelun. Jaa VPN-kontin nimiavaruus, jolloin jokainen katettu työkuorma käyttää yhtä tunnelia ja yhtä uudelleenkäynnistyksen rajaa, mikä on yksinkertaista kunnes jokin palvelu tarvitsee eri uloskäynnin tai oman DNS-polun. Tai reititä konttiverkko isäntäkoneen VPN-yhdyskäytävälle: välitys päällä, sillan etuliite osoittaa tunneliin, paluuliikenne käsitellään nimenomaisesti. Se ostaa hallinnan verkkokohtaisesti ja maksaa sinulle sääntöjoukon, jota on ylläpidettävä daemonin ja asiakasohjelman päivitysten läpi.
Kummassakin tapauksessa ratkaiseva testi on vikatilanne. Pysäytä tunneli, kun kontin pyyntö on matkalla, ja katso mihin paketti menee. Jos se putoaa takaisin suoralle polulle, kattavuutta ei koskaan pakotettu, koska asiakasohjelman kill switch ohjaa asiakasohjelman omaa liikennettä eikä sillalta välitettyjä paketteja. Käynnistä sen jälkeen daemon ja isäntäkone uudelleen ja vahvista tulos toisen kerran; juuri silloin käsin kirjoitetut säännöt katoavat.
Ennen kuin sanot sen valmiiksi, vahvista neljä asiaa: tunneliliitäntä on samassa nimiavaruudessa kuin liikenne, konttitesti ajettiin oikean kontin sisällä, nimien selvitys ja molemmat osoiteperheet tarkistettiin, ja tunnelin vikatesti epäonnistuu edelleen suljetusti. Kirjaa sitten palomuuritausta, asiakasohjelman versio ja jokaisen säännön omistaja. Juuri tuo kirjaus estää seuraavaa päivitystä jättämästä paikalleen dokumentoimatonta sekoitusta vanhoista oletuksista.