Kvifor ein IPsec-tryggleikspolicy ikkje er ei oppføring i rutetabellen

Ping 10.20.0.5 gjennom tunnelen, og ingenting kjem tilbake, medan rutetabellen insisterer på at det subnettet er nåbart. Ruting og IPsec svarar på ulike spørsmål, og berre eitt av dei handlar om nåbarheit. Videresøket vel ein veg, deretter avgjer databasen for tryggleikspolicy om den vegen skal vernast, latast i fred eller avvisast. Når dei to er usamde, døyr pakken stille, så les dei i den rekkjefølgja.

Byrja med oppslaget, ikkje tabellen

Spør kjernen kva han faktisk ville gjere: ip route get 10.20.0.5 skriv ut den valde ruta, utgåande grensesnitt og kjeldeadressa han ville bruke. Eit prefiks, ein policyregel, ei merking eller ei føretrekt kjelde kan alle endre svaret, og difor slår det levande oppslaget det å lese tabellen med auga.

Test ein destinasjon innanfor det verna området, ikkje gatewayadressa. Å nå gatewayen på hi sida provar berre at det finst ei rute; det seier ingenting om subnettet du faktisk treng. Stadfest deretter at grensesnittet oppslaget valde, er det du ventar at tunnelen brukar.

Match selektorane på begge sider

Policydatabasen har sine eigne oppføringar, og kvar av dei nemner ei retning, ei kjelde, ein destinasjon og ein protokoll, og seier deretter kva som skal skje med pakkar som passar. Bruk ip xfrm policy for å liste dei; flagga viser om handlinga er vern, omgåing eller blokkering. Ein policy der selektorane er breiare eller smalare enn testflyten din vil ikkje matche han, og pakken forlèt ukryptert. Det er feilen du jagar, ikkje ei manglande rute.

Samanlikn dei faktiske verdiane: kjelde, destinasjon, protokoll og portar. Viss oppslaget løyste eitt adressepar medan policyoppføringa dekkjer eit anna, skildrar dei to visingane ulik trafikk. Køyr begge på nytt med same tuppel før du dreg ein konklusjon, elles redigerer du ein policy som aldri var på vegen.

Eit policytreff er ikkje installert tilstand

Ein matchande policy seier berre at pakken må vernast; kjernen treng framleis ein tryggleiksassosiasjon for å utføre vernet. List dei med ip xfrm state, eller med swanctl --list-sas når strongSwan forhandlar, og les selektorane og teljarane på kvar oppføring.

Når ein policy matchar og ingen assosiasjon dekkjer dei same selektorane, blir pakken droppa i staden for send i klartekst. Det er droppet du skal sjå etter når tunnelen er oppe, men eitt einskilt subnett feilar. Teljarane seier resten: ein assosiasjon som aldri aukar vart aldri vald, medan ein som aukar og likevel endar i eit dropp, peikar på fjernsida. Å rette selektorane og å fornye nøklar er ulike reparasjonar, så avgjer kva du treng før du rører konfigurasjonen.

Kva ein routebasert tunnel framleis krev

Eit XFRM-grensesnitt får tunnelen til å sjå ut som eining du kan rute inn i, noko som er verkeleg nyttig. Det fjernar ikkje policyen og tilstanden som avgjer kva som skjer når pakken kjem dit. Ruta bidreg med eit neste hopp og ingenting meir.

Viss eininga finst og ruta peikar inn i ho medan ingen assosiasjon matchar dei indre selektorane, blir pakken forkasta, og inga mengd ruteredigering produserer nøklar eller selektorar. Kontroller grensesnittet med same kjelde og destinasjon som du ruta, og samanlikn det deretter med tilstandslista.

Avklar eigarskapet før du redigerer noko

Ein vertsbrannmur legg til ei tredje avgjerd som ingen av dei to databasane kjenner. Ei korrekt rute pluss ein matchande policy pluss ein installert assosiasjon kan framleis ende i ein droppa pakke, og applikasjonen rapporterer berre tidsavbrotet. Stadfest at brannmuren tillèt den verna trafikken før du klandrar IPsec. Opptak på tunneleininga og på det fysiske grensesnittet viser kva side av krypteringa pakken forsvann på.

Konfigurasjonseigarskap avgjer om rettinga di overlever ein omstart. Éin komponent kan installere tilstand medan ein annan styrer ruter, og ei handredigering av den andre blir overskriven neste gong tunnelen kjem opp. Endre den eigde konfigurasjonen, og les deretter begge visingane på nytt; RFC 4301 held dei to databasane åtskilde når du må forklare splittinga for nokon andre.