Verten når IPsec-partnaren, Docker-containeren gjer det ikkje

Du pingar den eksterne verten frå Linux-boksen og han svarar, så tunnelen verkar. Containeren ved sida av deg går framleis ut på tid, og det naturlege neste steget er å starte Docker på nytt. Ein container på eit brunettverk startar vanlegvis med ei anna kjeldeadresse og kjem inn til verten via vidaresending i staden for gjennom eigen utgangsveg til vertsapplikasjonen, så målte den vellukka testen ein annan pakke. For ein policybasert strongSwan-tunnel er ei vanleg rute mot det eksterne subnettet ikkje nok når den vidaresende pakken ikkje samsvarar med den installerte IPsec-policyen.

Gjennomgangen nedanfor følgjer ein destinasjon gjennom to kjelder og les tilstanden før noko vert endra.

Start med ein destinasjon og to kjelder

Vel først ein kjend teneste etter IP, så du ikkje feilsøkjer DNS samstundes. Noter tre fakta: bruprefikset til containeren, kjeldeadressa til vertsførespurnaden som virka, og dei forhandla lokale og eksterne trafikkselektorane for tunnelen. Dei tre tala forklarer nesten kvart tilfelle av dette symptomet.

Gjenta deretter den mislukka førespurnaden frå containeren og fang kjelda han faktisk brukar. Er adressa ikkje dekt av den lokale selektoren, kjenner du utfallet alt, og ingen attskaping av containeren endrar det.

Les policyane før du rører Docker

Skriveverna vertssjekkar dekkjer rutingsavgjerdene, policydatabasen og reglane som vel mellom dei:

ip rule show
ip route show table all
ip xfrm policy

Policylista viser selektorar og retning utan å trengje ein IPsec-tilstandsutskrift full av nøkkelmateriale, difor er ho trygg å lime inn i ei sak. Sjå etter ein lokal selektor som dekkjer vertsadressa men ikkje bruprefikset. Sjekk også overlapp: ei container-rute som handsamar den eksterne destinasjonen som lokal vil aldri produsere den forventa vidaresende pakken, og tunnelen får skulda. Lagre lista ved sida av kjeldeadressa til containeren, for dei to saman er heile samanlikninga.

Manglar containerprefikset, stopp og avgjer arkitekturen før du redigerer noko anna. Resten av gjennomgangen føreset at de er samde om kva kjeldeadresse som skal visast på nettet.

Kontroller filtrering og omsetjing i rekkjefølgje

Linux-brannmuren til Docker kan blokkere vidaresending uavhengig av IPsec. Med iptables-backendet, undersøk FORWARD-vegen og DOCKER-USER-avgjerdene, og hugs at ei regel som vert lagd til etter ein tidlegare dom kanskje aldri køyrer. nftables-backendet integrerast annleis, så ikkje lag ei DOCKER-USER-kjede berre fordi eit iptables-døme kalla ho det; sjekk kva backend daemonen din faktisk brukar.

Kontroller deretter kjeldeomsetjing. Ei brei MASQUERADE-regel kan gjere ein pakke som tidlegare samsvara med ein IPsec-selektor om til ein som ikkje lenger gjer det, og feilen ser nøyaktig ut som eit rutingsproblem. Den strongSwan-vidaresendingsrettleiinga dokumenterer NAT-unntaket som trengst før slik omsetjing for trafikk som alt samsvarar med ein policy.

Unntaket er ikkje ein måte å leggje ei udekt containerkjelde til tunnelen. Det vernar berre trafikk som alt passar designet, så avklar selektor- og returvegsspørsmåla først, og få deretter NAT og filtrering til å stemme med svaret. Viss du byrjar å utvide unntaket i staden, er det selektoren som skal endrast, ikkje NAT-regelen.

Avgjer deretter ruta eller omsett

Eit ruta containersubnett krev at båe partar godtek subnettet og ein ekstern returveg dit, noko som vanlegvis betyr ei selektorendring i båe endar og ein samtale med eigaren av den fjerne sida. Eit medvite omsett design må i staden vise ei adresse som er dekt av policyen på det relevante oppslagstrinnet, noko som vanlegvis betyr ei smal, dokumentert regel i staden for ein standard-MASQUERADE.

Ingen av dei to ordningane følgjer automatisk av den fungerande tunnelen til verten, og valet mellom dei er ei designavgjerd med ein eigar. Skriv ned kva du valde, elles vil neste ingeniør utleie det igjen frå brannmur-teljarane.

Sjå også etter den hybride feilen: halvparten av regelsettet omsett og halvparten ikkje, noko som gjev sporadisk suksess som avheng av destinasjonsporten og ikkje av noko ved nettet.

Verifiser med ei fersk tilkopling, ikkje ein omstart

Bruk ei fersk applikasjonstilkopling medan du følgjer smale brannmur-teljarar og den eksterne mottakaren, slik at kvar observasjon har ei kjelde. Ein Docker-omstart kan endre regeltilstanden og vil også forstyrre arbeidslaster, noko som kostar deg den reine signalet du prøvde å få.

Det varige resultatet er fire påstandar du kan vise: containerkjelda, den samsvarande verna vegen, tillaten vidaresending og eit svar som kjem tilbake. Når alle fire held, når containeren partnaren av same grunn som verten.