Promet Docker kontejnera zaobilazi VPN hosta: kako to provjeriti

Vaš preglednik na hostu pokazuje izlaznu adresu VPN-a, kontejner prijavljuje vašu kućnu vezu, a netko to naziva curenjem. Ništa nije iscurilo. Tunel hosta je skup sučelja, ruta i pravila koji pripadaju mrežnom prostoru imena hosta, a kontejner na mostu je drugi prostor imena s vlastitom zadanom rutom. Sjedio sam na Compose stacku gdje je VPN klijent bio povezan tjednima, a ni jedan paket kontejnera nikada nije ušao u njega.

Provjerite prostor imena prije ikone u traci

Prostori imena su cijeli argument. Kada Docker pokrene kontejner na mreži s mostom, stvara mrežni prostor imena, priključuje jedan kraj veth para unutar njega i daje tom prostoru adresu i zadanu rutu. Sučelje tunela, kako god se zvalo, živi u prostoru imena hosta. Promet unutar kontejnera ga ne vidi, i nijedna postavka klijenta to ne mijenja izvana.

Dva podržana poteza vade vas iz izolacije. --network host smješta kontejner unutar prostora imena hosta, pa on nasljeđuje rute hosta i time tunel. --network container:vpn dijeli prostor imena drugog kontejnera, a tako većina sidecar dizajna šalje radno opterećenje kroz VPN kontejner. Oba su eksplicitni izbori; obično je samo jedan od njih ono što je osoba koja postavlja imala na umu.

Način rada hosta nije besplatna nadogradnja. Kontejner prestaje imati vlastitu adresu, objavljivanje portova prestaje vrijediti, a proces koji tamo drži NET_ADMIN može prepisati usmjeravanje hosta. Prihvatiti to može biti ispravan potez. Pretpostaviti da je već uključeno jest način na koji ljudi provedu večer otklanjajući pogreške na tunelu koji nikada nije bio na putu.

Pratite paket s mosta

Kontejner na mostu šalje svoj paket svom zadanom gatewayu, a to je sučelje mosta na hostu. Host zatim prosljeđuje paket i, u zadanoj konfiguraciji, prevodi izvornu adresu u svoju prije nego paket izađe. Upravo taj korak prevođenja tiho poništava politiku.

Dok paket stigne do krajnje točke tunela, nosi adresu hosta. Svako pravilo, politička ruta ili odluka o podijeljenom tunelu vezana uz izvornu adresu kontejnera prestaje se podudarati, a dva kontejnera namijenjena različitim izlazima ne mogu se razlikovati samo po izvoru. Ako vam treba usmjeravanje po kontejneru, odluka mora pasti prije prevođenja ili unutar prostora imena koji kontrolirate.

Docker sam održava ta pravila, kroz koji god firewall backend daemon bio konfiguriran. Ručno napisana pravila izvan podržane kuke za proslijeđeni promet, DOCKER-USER, mogu biti preuređena ili odbačena kada se daemon ponovno pokrene ili host nadogradi. Docker dokumentacija o filtriranju paketa pokazuje redoslijed lanaca; praktična poanta je da svako pravilo treba vlasnika i put za ponovno učitavanje koji ste zaista testirali.

Testirajte dva sustava odvojeno

Dokazi iz jednog prostora imena ne govore ništa o drugom. Zahtjev pokrenut unutar VPN kontejnera dokazuje da tunel radi za taj kontejner. To nije dokaz o hostu, a ista naredba pokrenuta iz kontejnera s --network host nije dokaz o mostu.

# 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'

Zatim ponovite test unutar stvarnog kontejnera aplikacije, a ne slične slike. Aplikacija može nositi dodatnu rutu, varijablu okruženja za proxy ili drugačiji resolver, i svaka od toga mijenja odgovor. Provjerite razrješavanje imena i drugu obitelj adresa svaki put: kontejneri na korisnički definiranim mostovima razrješavaju se kroz Dockerov ugrađeni resolver na 127.0.0.11, a zadana ruta IPv6 na mostu može iznijeti promet van dok ste zauzeti testiranjem tunela samo za IPv4.

Pročitajte obrazac prije nego što dotaknete vjerodajnice

Kada host radi, a kontejner ne, uzrok je gotovo uvijek strukturni, a rotiranje ključeva ili ponovna instalacija klijenta gubi poslijepodne. Prvo sortirajte simptom i popravak se obično sam imenuje.

Redak o preklapanju zaslužuje vlastitu rečenicu. VPN profil koji gura rutu za 172.17.0.0/16, ili za 10.0.0.0/8 koja slučajno sadrži vaš prefiks mosta, tjera tunel da prisvoji podmrežu kontejnera, a odgovori na prevedene adrese krenut će u pogrešnom smjeru ili nestati. Prenumeriranje Docker mreže obično je čišće od gomilanja izuzetaka.

Učinite pokrivenost eksplicitnom, pa je namjerno pokvarite

Dva dizajna izdržavaju pregled. Podijelite prostor imena VPN kontejnera i svako pokriveno radno opterećenje koristi jedan tunel s jednom granicom ponovnog pokretanja, što je jednostavno dok jednoj usluzi ne zatreba drugačiji izlaz ili vlastita DNS putanja. Ili usmjerite mrežu kontejnera na VPN gateway na hostu: prosljeđivanje uključeno, prefiks mosta usmjeren na tunel, povratni promet eksplicitno obrađen. To kupuje kontrolu po mreži i košta vas skup pravila koja morate održavati kroz nadogradnje daemona i klijenta.

Bilo kako bilo, test koji je važan je slučaj kvara. Zaustavite tunel sa zahtjevom kontejnera u letu i gledajte kuda paket ide. Ako se vrati na izravnu putanju, pokrivenost nikada nije bila nametnuta, jer kill switch klijenta upravlja vlastitim prometom klijenta, a ne proslijeđenim paketima s mosta. Nakon toga ponovno pokrenite daemon i host i potvrdite rezultat drugi put; to je trenutak kada ručno napisana pravila nestaju.

Prije nego što to nazovete gotovim, potvrdite četiri stvari: sučelje tunela je u istom prostoru imena kao promet, test kontejnera pokrenut je unutar stvarnog kontejnera, razrješavanje imena i obje obitelji adresa su provjerene, i test kvara tunela još uvijek pada zatvoreno. Zatim zapišite firewall backend, verziju klijenta i vlasnika svakog pravila. Taj zapis je ono što sprječava sljedeću nadogradnju da ostavi nedokumentiranu mješavinu starih pretpostavki na mjestu.