Host-i arrin te partneri IPsec, kontejneri Docker jo

Ju bëni ping host-it të largët nga makina Linux dhe ai përgjigjet, pra tuneli funksionon. Kontejneri pranë jush ende skadon, dhe hapi tjetër i natyrshëm është të rinisni Docker. Një kontejner në rrjet urë zakonisht fillon me një adresë tjetër burimi dhe hyn në host përmes forwarding, jo përmes rrugës së daljes së vetë aplikacionit në host, ndaj testi i suksesshëm mati një paketë tjetër. Për një tunel strongSwan të bazuar në politikë, një rrugë e zakonshme drejt nënrrjetit të largët nuk mjafton kur paketa e përçuar nuk përputhet me politikën IPsec të instaluar.

Udhëzimi më poshtë ndjek një destinacion përmes dy burimeve, duke lexuar gjendjen përpara se të ndryshojë çdo gjë.

Filloni me një destinacion dhe dy burime

Zgjidhni së pari një shërbim të njohur sipas IP, që të mos korrigjoni njëkohësisht DNS. Shënoni tri fakte: prefiksin e urës së kontejnerit, adresën e burimit të kërkesës së host-it që funksionoi, dhe selektorët e trafikut lokal dhe të largët të negociuar për tunelin. Këto tri numra shpjegojnë pothuajse çdo rast të këtij simptomi.

Pastaj përsëritni kërkesën e dështuar nga brenda kontejnerit dhe kapni burimin që ai përdor në të vërtetë. Nëse ajo adresë nuk mbulohet nga selektori lokal, e dini tashmë rezultatin, dhe asnjë rikrijim i kontejnerit nuk do ta ndryshojë.

Lexoni politikat përpara se të prekni Docker

Kontrollimet e host-it vetëm për lexim mbulojnë vendimet e rrugëtimit, bazën e politikave dhe rregullat që zgjedhin midis tyre:

ip rule show
ip route show table all
ip xfrm policy

Lista e politikave tregon selektorët dhe drejtimin pa pasur nevojë për një dump gjendjeje IPsec plot material çelësi, prandaj është e sigurt ta ngjitni në një tiketë. Kërkoni një selektor lokal që mbulon adresën e host-it por jo prefiksin e urës. Kontrolloni edhe mbivendosjen: një rrugë kontejneri që e trajton destinacionin e largët si lokal nuk do të prodhojë kurrë paketën e përçuar që prisni, dhe tuneli fajësohet. Ruajeni atë listë pranë adresës së burimit të kontejnerit, sepse të dyja bashkë janë i gjithë krahasimi.

Nëse mungon prefiksi i kontejnerit, ndaloni dhe vendosni arkitekturën përpara se të redaktoni çdo gjë tjetër. Pjesa tjetër e udhëzimit supozon se jeni dakord se cila adresë burimi duhet të shfaqet në rrjet.

Kontrolloni filtrimin dhe përkthimin sipas radhës

Firewall-i i urës Linux të Docker mund të bllokojë forwarding-un pavarësisht nga IPsec. Me backend-in iptables, inspektoni rrugën FORWARD dhe vendimet DOCKER-USER, duke kujtuar se një rregull i shtuar pas një verdikti të mëparshëm mund të mos ekzekutohet kurrë. Backend-i nftables integrohet ndryshe, ndaj mos krijoni një zinxhir DOCKER-USER vetëm sepse një shembull iptables e quajti ashtu; kontrolloni cilin backend përdor në të vërtetë daemon-i juaj.

Pastaj kontrolloni përkthimin e burimit. Një rregull i gjerë MASQUERADE mund të kthejë një paketë që më parë përputhej me një selektor IPsec në një që nuk përputhet më, dhe dështimi duket saktësisht si problem rrugëtimi. udhëzuesi i forwarding-ut të strongSwan dokumenton përjashtimin NAT të nevojshëm përpara një përkthimi të tillë për trafikun që tashmë përputhet me një politikë.

Ai përjashtim nuk është mënyrë për të shtuar në tunel një burim kontejneri të pambuluar. Mbron vetëm trafikun që tashmë përshtatet me projektin, ndaj zgjidhni së pari çështjet e selektorit dhe të rrugës së kthimit, pastaj bëni NAT dhe filtrimin të pajtohen me përgjigjen. Nëse filloni të zgjeroni përjashtimin, selektori është gjëja që duhet ndryshuar, jo rregulli NAT.

Pastaj vendosni rrugëtuar apo përkthyer

Një nënrrjet kontejneri i rrugëtuar kërkon që të dy partnerët ta pranojnë atë nënrrjet dhe një rrugë kthimi të largët drejt tij, që zakonisht do të thotë një ndryshim selektori në të dy skajet dhe një bisedë me pronarin e anës së largët. Një projekt i përkthyer qëllimisht duhet përkundrazi të paraqesë një adresë të mbuluar nga politika në fazën përkatëse të kërkimit, që zakonisht do të thotë një rregull i ngushtë dhe i dokumentuar në vend të një MASQUERADE të paracaktuar.

Asnjëri prej dy rregullimeve nuk rrjedh automatikisht nga tuneli funksional i host-it, dhe zgjedhja midis tyre është një vendim projekti me pronar. Shkruani cilën zgjodhët, sepse përndryshe inxhinieri tjetër do ta nxjerrë përsëri nga numëruesit e firewall-it.

Vini re edhe dështimin hibrid: gjysma e grupit të rregullave e përkthyer dhe gjysma jo, që prodhon sukses të ndërprerë që varet nga porta e destinacionit dhe jo nga diçka në rrjet.

Verifikoni me një lidhje të re, jo me një rinisje

Përdorni një lidhje të re aplikacioni ndërsa vëzhgoni numërues të ngushtë të firewall-it dhe marrësin e largët, që çdo vëzhgim të ketë një burim. Një rinisje e Docker mund të ndryshojë gjendjen e rregullave dhe gjithashtu do të prishë ngarkesat e punës, gjë që ju kushton sinjalin e pastër që po përpiqeshit të merrnit.

Rezultati i qëndrueshëm janë katër pohime që mund t'i tregoni: burimi i kontejnerit, rruga e mbrojtur përkatëse, forwarding-u i lejuar dhe një përgjigje që kthehet. Kur të katërt vlejnë, kontejneri arrin partnerin për të njëjtën arsye si host-i.