Trafiku i kontejnerëve Docker anashkalon VPN-në e hostit: si ta verifikoni
Një VPN e hostit mbulon vetëm hapësirën e emrave të rrjetit të hostit. Përdorni këto kontrolle për të zbuluar nëse trafiku i kontejnerëve në urë hyn në tunel apo del drejtpërdrejt.
Shfletuesi juaj në host shfaq adresën e daljes së VPN-së, kontejneri raporton lidhjen tuaj të shtëpisë dhe dikush e quan atë rrjedhje. Asgjë nuk rrjedhi. Tuneli i hostit është një tufë ndërfaqesh, rrugësh dhe rregullash që i përkasin hapësirës së emrave të rrjetit të hostit, dhe një kontejner në një urë është një hapësirë tjetër emrash me rrugën e vet të paracaktuar. Kam ndenjur në një stack Compose ku klienti VPN kishte qenë i lidhur për javë dhe asnjë paketë kontejneri nuk kishte hyrë kurrë në të.
Kontrolloni hapësirën e emrave përpara ikonës në shirit
Hapësirat e emrave janë i gjithë argumenti. Kur Docker nis një kontejner në një rrjet ure, krijon një hapësirë emrash rrjeti, lidh një skaj të një çifti veth brenda saj dhe i jep asaj hapësire një adresë dhe një rrugë të paracaktuar. Ndërfaqja e tunelit, siçdo qoftë emri i saj, jeton në hapësirën e emrave të hostit. Trafiku brenda kontejnerit nuk mund ta shohë atë, dhe asnjë cilësim i klientit nuk e ndryshon këtë nga jashtë.
Dy lëvizje të mbështetura ju nxjerrin nga izolimi. --network host e vendos kontejnerin brenda hapësirës së emrave të hostit, kështu që ai trashëgon rrugët e hostit dhe për rrjedhojë tunelin. --network container:vpn ndan hapësirën e emrave të një kontejneri tjetër, dhe kështu shumica e modeleve sidecar dërgojnë një ngarkesë pune përmes një kontejneri VPN. Të dyja janë zgjedhje të qarta; zakonisht vetëm njëra prej tyre është ajo që kishte ndër mend personi që vendos në punë.
Modaliteti host nuk është një përmirësim falas. Kontejneri pushon së pasuri adresën e vet, publikimi i porteve pushon së zbatuari, dhe një proces që mban NET_ADMIN atje mund të rishkruajë rrugëtimin e hostit. Pranimi i kësaj mund të jetë vendimi i duhur. Supozimi se është tashmë i ndezur është mënyra se si njerëzit kalojnë një mbrëmje duke korrigjuar një tunel që nuk ishte kurrë në rrugë.
Ndiqni paketën jashtë urës
Një kontejner në urë e dërgon paketën e vet te porta e tij e paracaktuar, që është ndërfaqja e urës në host. Host-i pastaj e përcjell paketën dhe, në konfigurimin e paracaktuar, e përkthen adresën e burimit në të vetën përpara se paketa të dalë. Është pikërisht ky hap përkthimi që e mposht politikën në heshtje.
Kur paketa arrin pikën fundore të tunelit, ajo mban adresën e hostit. Çdo rregull, rrugë politike ose vendim për tunel të ndarë i bazuar në adresën origjinale të kontejnerit pushon së përputhuri, dhe dy kontejnerë të destinuar të dalin nga dalje të ndryshme nuk dallohen vetëm nga burimi. Nëse ju nevojitet rrugëtim për çdo kontejner, vendimi duhet të merret përpara përkthimit ose brenda një hapësire emrash që ju kontrolloni.
Docker i mirëmban vetë këto rregulla, përmes atij backend-i të murit të zjarrit me të cilin u konfigurua daemon-i. Rregullat e shkruara me dorë jashtë grepave të mbështetur për trafikun e përcjellë, DOCKER-USER, mund të rirenditen ose të hidhen kur daemon-i riniset ose host-i përmirësohet. Dokumentacioni i Docker për filtrimin e paketave tregon rendin e zinxhirëve; pika praktike është se çdo rregull ka nevojë për një pronar dhe një rrugë ringarkimi që e keni testuar vërtet.
Testoni dy sistemet veçmas
Provat nga një hapësirë emrash nuk thonë asgjë për tjetrën. Një kërkesë e ekzekutuar brenda kontejnerit VPN provon se tuneli funksionon për atë kontejner. Nuk është provë për hostin, dhe i njëjti komandë i ekzekutuar nga një kontejner --network host nuk është provë për urën.
# 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'Pastaj përsëritni testin brenda kontejnerit të vërtetë të aplikacionit dhe jo në një imazh të ngjashëm. Aplikacioni mund të mbajë një rrugë shtesë, një variabël mjedisi për proxy ose një zgjidhës tjetër, dhe secila prej tyre e ndryshon përgjigjen. Kontrolloni zgjidhjen e emrave dhe familjen e dytë të adresave çdo herë: kontejnerët në urat e përcaktuara nga përdoruesi zgjidhen përmes zgjidhësit të integruar të Docker në 127.0.0.11, dhe një rrugë e paracaktuar IPv6 në urë mund të nxjerrë trafik jashtë ndërsa ju jeni i zënë duke testuar një tunel vetëm IPv4.
Lexoni modelin përpara se të prekni kredencialet
Kur host-i funksionon dhe kontejneri jo, shkaku është pothuajse gjithmonë strukturor, dhe rrotullimi i çelësave ose riinstalimi i klientit humb një pasdite. Rendisni së pari simptomën dhe rregullimi zakonisht e emërton vetveten.
| 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 |
Rreshti i mbivendosjes meriton fjalinë e vet. Një profil VPN që shtyn një rrugë për 172.17.0.0/16, ose për një 10.0.0.0/8 që përmban rastësisht prefiksin e urës tuaj, e bën tunelin të pretendojë nënrjetin e kontejnerëve, dhe përgjigjet drejt adresave të përkthyera do të shkojnë në drejtimin e gabuar ose do të zhduken. Rinumërimi i rrjetit Docker është zakonisht më i pastër se grumbullimi i përjashtimeve.
Bëjeni mbulimin të qartë, pastaj thyeni qëllimisht
Dy modele i rezistojnë një rishikimi. Ndani hapësirën e emrave të kontejnerit VPN dhe çdo ngarkesë e mbuluar përdor një tunel të vetëm me një kufi të vetëm rinisjeje, gjë që është e thjeshtë derisa një shërbim të ketë nevojë për një dalje tjetër ose rrugën e vet DNS. Ose drejtoni rrjetin e kontejnerëve drejt një porte VPN në host: përcjellja e aktivizuar, prefiksi i urës i drejtuar drejt tunelit, trafiku i kthimit i trajtuar në mënyrë të qartë. Kjo blen kontroll për çdo rrjet dhe ju kushton një grup rregullash për t'i mirëmbajtur gjatë përmirësimeve të daemon-it dhe klientit.
Sido që të jetë, testi që ka rëndësi është rasti i dështimit. Ndaloni tunelin me një kërkesë kontejneri në fluturim dhe shikoni ku shkon paketa. Nëse kthehet në rrugën e drejtpërdrejtë, mbulimi nuk u zbatua kurrë, sepse një kill switch i klientit qeveris trafikun e vetë klientit dhe jo paketat e përcjella nga një urë. Pastaj rinisni daemon-in dhe host-in dhe konfirmoni rezultatin për herë të dytë; ai është momenti kur rregullat e shkruara me dorë zhduken.
Përpara se ta shpallni të përfunduar, konfirmoni katër gjëra: ndërfaqja e tunelit është në të njëjtën hapësirë emrash si trafiku, testi i kontejnerit u ekzekutua brenda kontejnerit të vërtetë, zgjidhja e emrave dhe të dyja familjet e adresave u kontrolluan, dhe testi i dështimit të tunelit vazhdon të dështojë i mbyllur. Pastaj shkruani backend-in e murit të zjarrit, versionin e klientit dhe pronarin e çdo rregulli. Ai regjistrim është ai që e pengon përmirësimin e radhës të lërë një përzierje të pambuluar të supozimeve të vjetra.