Verten når IPsec-partneren, Docker-containeren gjør det ikke

Du pinger den eksterne verten fra Linux-boksen og den svarer, så tunnelen virker. Containeren ved siden av deg timer fortsatt ut, og det naturlige neste steget er å starte Docker på nytt. En container på et bronettverk starter vanligvis med en annen kildeadresse og kommer inn til verten via videresending i stedet for gjennom vertsapplikasjonens egen utgangsvei, så målte den vellykkede testen en annen pakke. For en policybasert strongSwan-tunnel er en vanlig rute mot det eksterne subnettet ikke nok når den videresendte pakken ikke samsvarer med den installerte IPsec-policyen.

Gjennomgangen nedenfor følger én destinasjon gjennom to kilder og leser tilstanden før noe endres.

Start med én destinasjon og to kilder

Velg først en kjent tjeneste etter IP, så du ikke feilsøker DNS samtidig. Noter tre fakta: containerens broprefiks, kildeadressen til vertsforespørselen som virket, og de forhandlede lokale og eksterne trafikkselektorene for tunnelen. De tre tallene forklarer nesten alle tilfeller av dette symptomet.

Gjenta deretter den mislykkede forespørselen fra containeren og fang kilden den faktisk bruker. Er adressen ikke dekket av den lokale selektoren, kjenner du utfallet allerede, og ingen gjenskaping av containeren endrer det.

Les policyene før du rører Docker

Skrivebeskyttede vertssjekker dekker rutingsbeslutningene, policydatabasen og reglene som velger mellom dem:

ip rule show
ip route show table all
ip xfrm policy

Policylisten viser selektorer og retning uten å trenge en IPsec-tilstandsutskrift full av nøkkelmateriale, derfor er den trygg å lime inn i en sak. Se etter en lokal selektor som dekker vertsadressen men ikke broprefikset. Sjekk også overlapp: en container-rute som behandler den eksterne destinasjonen som lokal vil aldri produsere den forventede videresendte pakken, og tunnelen får skylden. Lagre listen ved siden av containerens kildeadresse, for de to sammen er hele sammenligningen.

Mangler containerprefikset, stopp og avgjør arkitekturen før du redigerer noe annet. Resten av gjennomgangen forutsetter at dere er enige om hvilken kildeadresse som skal vises på nettet.

Kontroller filtrering og oversettelse i rekkefølge

Dockers Linux-brobrannmur kan blokkere videresending uavhengig av IPsec. Med iptables-backendet, undersøk FORWARD-veien og DOCKER-USER-beslutningene, og husk at en regel som legges til etter en tidligere dom kanskje aldri kjøres. nftables-backendet integreres annerledes, så ikke lag en DOCKER-USER-kjede bare fordi et iptables-eksempel kalte den det; sjekk hvilket backend daemonen din faktisk bruker.

Kontroller deretter kildeoversettelse. En bred MASQUERADE-regel kan gjøre en pakke som tidligere samsvarte med en IPsec-selektor om til en som ikke lenger gjør det, og feilen ser nøyaktig ut som et rutingsproblem. Den strongSwan-videresendingsveiledningen dokumenterer NAT-unntaket som trengs før slik oversettelse for trafikk som allerede samsvarer med en policy.

Unntaket er ikke en måte å legge en udekket containerkilde til tunnelen. Det beskytter bare trafikk som allerede passer designet, så avklar selektor- og returveisspørsmålene først, og få deretter NAT og filtrering til å stemme med svaret. Hvis du begynner å utvide unntaket i stedet, er det selektoren som skal endres, ikke NAT-regelen.

Avgjør deretter rutet eller oversatt

Et rutet containersubnett krever at begge parter godtar subnettet og en ekstern returvei dit, noe som vanligvis betyr en selektorendring i begge ender og en samtale med eieren av den fjerne siden. Et bevisst oversatt design må i stedet vise en adresse som dekkes av policyen på det relevante oppslagstrinnet, noe som vanligvis betyr en smal, dokumentert regel i stedet for en standard-MASQUERADE.

Ingen av de to ordningene følger automatisk av vertens fungerende tunnel, og valget mellom dem er en designbeslutning med en eier. Skriv ned hvilken du valgte, ellers vil neste ingeniør utlede det igjen fra brannmur-tellerne.

Se også etter den hybride feilen: halvparten av regelsettet oversatt og halvparten ikke, noe som gir sporadisk suksess som avhenger av destinasjonsporten og ikke av noe ved nettet.

Verifiser med en fersk tilkobling, ikke en omstart

Bruk en fersk applikasjonstilkobling mens du følger smale brannmur-tellere og den eksterne mottakeren, slik at hver observasjon har en kilde. En Docker-omstart kan endre regeltilstanden og vil også forstyrre arbeidslaster, noe som koster deg det rene signalet du prøvde å få.

Det varige resultatet er fire påstander du kan vise: containerkilden, den samsvarende beskyttede veien, tillatt videresending og et svar som kommer tilbake. Når alle fire holder, når containeren partneren av samme grunn som verten.