Docker konteineru trafiks apiet resursdatora VPN: kā to pārbaudīt
Resursdatora VPN aptver tikai resursdatora tīkla vārdu telpu. Ar šīm pārbaudēm noskaidrojiet, vai tiltiņa konteineru trafiks nonāk tunelī vai iziet tieši.
Pārlūkprogramma uz resursdatora rāda VPN izejas adresi, konteiners ziņo par jūsu mājas savienojumu, un kāds to sauc par noplūdi. Nekas nenoplūda. Resursdatora tunelis ir saskarņu, maršrutu un noteikumu kopums, kas pieder resursdatora tīkla vārdu telpai, un konteiners uz tiltiņa ir cita vārdu telpa ar savu noklusējuma maršrutu. Esmu sēdējis pie Compose kaudzes, kur VPN klients bija savienots nedēļām un neviens konteinera pakete tajā nekad nebija iekļuvusi.
Pārbaudiet vārdu telpu pirms paplātes ikonas
Vārdu telpas ir viss arguments. Kad Docker palaiž konteineru tiltiņa tīklā, tas izveido tīkla vārdu telpu, pievieno tajā vienu veth pāra galu un piešķir šai telpai adresi un noklusējuma maršrutu. Tuneļa saskarne, lai kā tā sauktos, dzīvo resursdatora vārdu telpā. Trafiks konteinera iekšienē to neredz, un neviens klienta iestatījums to nemaina no ārpuses.
Divi atbalstīti gājieni izved jūs no izolācijas. --network host ievieto konteineru resursdatora vārdu telpā, tāpēc tas manto resursdatora maršrutus un līdz ar to tuneli. --network container:vpn kopīgo cita konteinera vārdu telpu, un tā vairums sidecar risinājumu sūta darba slodzi caur VPN konteineru. Abi ir skaidras izvēles; parasti tikai viens no tiem ir tas, ko domāja izvietotājs.
Resursdatora režīms nav bezmaksas jauninājums. Konteiners pārstāj būt ar savu adresi, ostu publicēšana vairs nav spēkā, un process, kuram tur ir NET_ADMIN, var pārrakstīt resursdatora maršrutēšanu. To pieņemt var būt pareizais lēmums. Pieņemt, ka tas jau ir ieslēgts, ir veids, kā cilvēki pavada vakaru atkļūdojot tuneli, kas nekad nav bijis ceļā.
Sekojiet paketei prom no tiltiņa
Tiltiņa konteiners sūta savu paketi uz savu noklusējuma vārteju, kas ir tiltiņa saskarne uz resursdatora. Pēc tam resursdators pārsūta paketi un noklusējuma konfigurācijā pirms paketes iziešanas pārtulko avota adresi uz savu. Tieši šis tulkošanas solis klusi izjauc politiku.
Kad pakete sasniedz tuneļa galapunktu, tā nes resursdatora adresi. Jebkurš noteikums, politikas maršruts vai sadalītā tuneļa lēmums, kas balstīts uz konteinera sākotnējo adresi, pārstāj sakrist, un divus konteinerus, kuriem jāiziet pa dažādām izejām, nevar atšķirt tikai pēc avota. Ja jums nepieciešama maršrutēšana katram konteineram, lēmums jāpieņem pirms tulkošanas vai vārdu telpā, kuru jūs kontrolējat.
Docker pats uztur šos noteikumus, izmantojot to ugunsmūra backend, ar kuru tika konfigurēts dēmons. Ar roku rakstīti noteikumi ārpus atbalstītā pārsūtītā trafika āķa, DOCKER-USER, var tikt pārkārtoti vai izmesti, kad dēmons restartējas vai resursdators tiek jaunināts. Docker dokumentācija par pakešu filtrēšanu parāda ķēžu secību; praktiskā būtība ir tāda, ka katram noteikumam vajadzīgs īpašnieks un pārlādes ceļš, kuru jūs tiešām esat pārbaudījis.
Pārbaudiet abas sistēmas atsevišķi
Pierādījumi no vienas vārdu telpas neko nepasaka par otru. Pieprasījums, kas izpildīts VPN konteinerā, pierāda, ka tunelis darbojas šim konteineram. Tie nav pierādījumi par resursdatoru, un tā pati komanda, izpildīta --network host konteinerā, nav pierādījums par tiltiņu.
# 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'
Pēc tam atkārtojiet testu īstajā lietojumprogrammas konteinerā, nevis līdzīgā attēlā. Lietojumprogramma var saturēt papildu maršrutu, starpniekservera vides mainīgo vai citu atrisinātāju, un katrs no tiem maina atbildi. Katru reizi pārbaudiet nosaukumu atrisināšanu un otro adrešu saimi: konteineri lietotāja definētos tiltiņos tiek atrisināti ar Docker iebūvēto atrisinātāju adresē 127.0.0.11, un tiltiņa IPv6 noklusējuma maršruts var iznest trafiku ārā, kamēr jūs esat aizņemts ar tikai IPv4 tuneļa testēšanu.
Izlasiet modeli pirms pieskaraties akreditācijas datiem
Kad resursdators strādā un konteiners ne, cēlonis gandrīz vienmēr ir strukturāls, un atslēgu rotācija vai klienta pārinstalēšana izšķiež pēcpusdienu. Vispirms sakārtojiet simptomu, un labojums parasti pats sevi nosauc.
| 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ārklāšanās rindai pienākas savs teikums. VPN profils, kas spiež maršrutu 172.17.0.0/16 vai 10.0.0.0/8, kurā nejauši ir jūsu tiltiņa prefikss, liek tunelim pretendēt uz konteineru apakštīklu, un atbildes uz pārtulkotajām adresēm dosies nepareizā virzienā vai pazudīs. Docker tīkla pārnumurēšana parasti ir tīrāka nekā izņēmumu uzkrāšana.
Padariet pārklājumu skaidru un pēc tam apzināti salauziet to
Divi risinājumi iztur pārskatīšanu. Kopīgojiet VPN konteinera vārdu telpu, un katra pārklātā darba slodze izmanto vienu tuneli ar vienu restartēšanas robežu, kas ir vienkārši, līdz kādam servisam vajag citu izeju vai savu DNS ceļu. Vai arī novirziet konteineru tīklu uz VPN vārteju resursdatorā: pārsūtīšana iespējota, tiltiņa prefikss vērsts uz tuneli, atgaitas trafiks apstrādāts skaidri. Tas nopērk kontroli katram tīklam un izmaksā noteikumu kopumu, kas jāuztur dēmona un klienta jauninājumu laikā.
Lai kā arī būtu, svarīgais tests ir atteices gadījums. Apturiet tuneli, kamēr konteinera pieprasījums ir ceļā, un vērojiet, kur pakete aiziet. Ja tā atkrīt atpakaļ uz tiešo ceļu, pārklājums nekad netika piemērots, jo klienta kill switch pārvalda paša klienta trafiku, nevis no tiltiņa pārsūtītās paketes. Pēc tam restartējiet dēmonu un resursdatoru un apstipriniet rezultātu otro reizi; tas ir mirklis, kad ar roku rakstītie noteikumi pazūd.
Pirms saucat to par pabeigtu, apstipriniet četras lietas: tuneļa saskarne ir tajā pašā vārdu telpā kā trafiks, konteinera tests notika īstajā konteinerā, nosaukumu atrisināšana un abas adrešu saimes tika pārbaudītas, un tuneļa atteices tests joprojām neizdodas slēgti. Pēc tam pierakstiet ugunsmūra backend, klienta versiju un katra noteikuma īpašnieku. Tieši šis ieraksts neļauj nākamajam jauninājumam atstāt nedokumentētu veco pieņēmumu maisījumu.