Docker saobraćaj kontejnera zaobilazi VPN hosta: kako to provjeriti

Vaš preglednik na hostu pokazuje izlaznu adresu VPN-a, kontejner prijavljuje vašu kućnu vezu, a neko to naziva curenjem. Ništa nije iscurilo. Tunel hosta je skup interfejsa, ruta i pravila koji pripadaju mrežnom prostoru imena hosta, a kontejner na mostu je drugi prostor imena sa sopstvenom podrazumijevanom rutom. Sjedio sam na Compose stacku gdje je VPN klijent bio povezan sedmicama, 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 podrazumijevanu rutu. Interfejs tunela, kako god se zvao, živi u prostoru imena hosta. Saobraćaj unutar kontejnera ga ne vidi, i nijedna postavka klijenta to ne mijenja spolja.

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.

Režim hosta nije besplatna nadogradnja. Kontejner prestaje imati vlastitu adresu, objavljivanje portova prestaje važiti, a proces koji tamo drži NET_ADMIN može prepisati rutiranje hosta. Prihvatiti to može biti ispravan potez. Pretpostaviti da je već uključeno jeste način na koji ljudi provedu veče otklanjajući greške na tunelu koji nikada nije bio na putu.

Pratite paket s mosta

Kontejner na mostu šalje svoj paket svom podrazumijevanom gatewayu, a to je interfejs mosta na hostu. Host zatim prosljeđuje paket i, u podrazumijevanoj 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 tačke tunela, nosi adresu hosta. Svako pravilo, politička ruta ili odluka o podijeljenom tunelu vezana za originalnu adresu kontejnera prestaje se poklapati, a dva kontejnera namijenjena različitim izlazima ne mogu se razlikovati samo po izvoru. Ako vam treba rutiranje po kontejneru, odluka mora pasti prije prevođenja ili unutar prostora imena koji kontrolišete.

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

Testirajte dva sistema 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 komanda 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 porodicu adresa svaki put: kontejneri na korisnički definisanim mostovima razrješavaju se kroz Dockerov ugrađeni resolver na 127.0.0.11, a podrazumijevana ruta IPv6 na mostu može iznijeti saobraćaj van dok ste zauzeti testiranjem tunela samo za IPv4.

Pročitajte obrazac prije nego što dotaknete akreditive

Kada host radi, a kontejner ne, uzrok je gotovo uvijek strukturalan, a rotiranje ključeva ili ponovna instalacija klijenta gubi popodne. Prvo sortirajte simptom i popravka se obično sama imenuje.

Red 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. Prenumerisanje 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 restarta, š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 saobraćaj 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 direktnu putanju, pokrivenost nikada nije bila nametnuta, jer kill switch klijenta upravlja vlastitim saobraćajem klijenta, a ne proslijeđenim paketima s mosta. Nakon toga restartujte 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: interfejs tunela je u istom prostoru imena kao saobraćaj, test kontejnera je pokrenut unutar stvarnog kontejnera, razrješavanje imena i obje porodice 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 nedokumentovanu mješavinu starih pretpostavki na mjestu.