Værten når IPsec-partneren, Docker-containeren gør ikke

Du pinger den fjernede vært fra Linux-boksen, og den svarer, så tunnelen virker. Containeren ved siden af dig timer stadig ud, og det naturlige næste skridt er at genstarte Docker. En container på et bronetværk starter normalt med en anden kildeadresse og kommer ind til værten via videresendelse i stedet for gennem værtens egen programs udgangsvej, så målte den vellykkede test en anden pakke. For en politikbaseret strongSwan-tunnel er en almindelig rute mod det fjernede subnet ikke nok, når den videresendte pakke ikke matcher den installerede IPsec-politik.

Gennemgangen nedenfor følger én destination gennem to kilder og læser tilstanden, før noget ændres.

Start med én destination og to kilder

Vælg først en kendt tjeneste efter IP, så du ikke fejlretter DNS samtidig. Notér tre fakta: containerens broprefix, kildeadressen for den værtsanmodning, der virkede, og de forhandlede lokale og fjernede trafikselektorer for tunnelen. De tre tal forklarer næsten alle tilfælde af dette symptom.

Gentag derefter den mislykkede anmodning inde fra containeren, og fang den kilde, den faktisk bruger. Er den adresse ikke dækket af den lokale selektor, kender du allerede resultatet, og ingen genskabelse af containeren ændrer det.

Læs politikkerne, før du rører Docker

Skrivebeskyttede værtstjek dækker routingbeslutningerne, politikdatabasen og de regler, der vælger mellem dem:

ip rule show
ip route show table all
ip xfrm policy

Politiklisten viser selektorer og retning uden at kræve et IPsec-tilstandsudtræk fuldt af nøglemateriale, og derfor er det sikkert at indsætte den i en sag. Led efter en lokal selektor, der dækker værtens adresse, men ikke broprefixet. Kontroller også overlap: en containerrute, der behandler den fjernede destination som lokal, vil aldrig frembringe den videresendte pakke, du forventer, og tunnelen får skylden. Gem listen ved siden af containerens kildeadresse, for de to ting er tilsammen hele sammenligningen.

Mangler containerprefixet, så stop og beslut arkitekturen, før du redigerer noget andet. Resten af gennemgangen forudsætter, at I er enige om, hvilken kildeadresse der skal optræde på ledningen.

Kontroller filtrering og oversættelse i rækkefølge

Dockers Linux-brofirewall kan blokere videresendelse uafhængigt af IPsec. Med iptables-backendet skal du undersøge FORWARD-vejen og DOCKER-USER-beslutningerne og huske, at en regel tilføjet efter en tidligere dom måske aldrig kører. nftables-backendet integrerer anderledes, så opret ikke en DOCKER-USER-kæde, blot fordi et iptables-eksempel navngav den; kontroller, hvilket backend din daemon faktisk bruger.

Kontroller derefter kildeoversættelse. En bred MASQUERADE-regel kan forvandle en pakke, der tidligere matchede en IPsec-selektor, til en, der ikke længere gør, og fejlen ser præcis ud som et routingproblem. Den strongSwan-videresendelsesguide dokumenterer den NAT-undtagelse, der er nødvendig før en sådan oversættelse for trafik, der allerede matcher en politik.

Undtagelsen er ikke en måde at føje en udækket containerkilde til tunnelen. Den beskytter kun trafik, der allerede passer i designet, så afklar først selektor- og returvejsspørgsmålene, og få derefter NAT og filtrering til at stemme med svaret. Hvis du i stedet begynder at udvide undtagelsen, er det selektoren, der skal ændres, ikke NAT-reglen.

Beslut derefter routet eller oversat

Et routet containersubnet kræver, at begge parter accepterer det subnet og en fjern returvej dertil, hvilket normalt betyder en selektorændring i begge ender og en samtale med ejeren af den fjerne side. Et bevidst oversat design skal i stedet fremvise en adresse, der er dækket af politikken, på det relevante opslagstrin, hvilket normalt betyder en snæver, dokumenteret regel i stedet for en standard-MASQUERADE.

Ingen af de to ordninger følger automatisk af værtens fungerende tunnel, og valget mellem dem er en designbeslutning med en ejer. Skriv ned, hvilken du valgte, for den næste ingeniør vil ellers udlede det igen fra firewalltællerne.

Vær også opmærksom på den hybride fejl: halvdelen af regelsættet oversat og halvdelen ikke, hvilket giver sporadisk succes, der afhænger af destinationsporten og ikke af noget ved netværket.

Verificer med en frisk forbindelse, ikke en genstart

Brug en frisk programforbindelse, mens du holder øje med snævre firewalltællere og den fjernede modtager, så hver iagttagelse har en kilde. En Docker-genstart kan ændre regeltilstand og vil også forstyrre arbejdsbelastninger, hvilket koster dig det rene signal, du forsøgte at få.

Det holdbare resultat er fire udsagn, du kan vise: containerkilden, den matchende beskyttede vej, tilladt videresendelse og et svar, der kommer tilbage. Når alle fire holder, når containeren partneren af samme grund som værten.