Ping 10.20.0.5 gjennom tunnelen, og ingenting kommer tilbake, mens rutetabellen insisterer på at det subnettet er nåbart. Ruting og IPsec svarer på ulike spørsmål, og bare ett av dem handler om nåbarhet. Videresøket velger en vei, deretter avgjør databasen for sikkerhetspolicy om den veien skal beskyttes, la stå eller avvises. Når de to er uenige, dør pakken stille, så les dem i den rekkefølgen.

Begynn med oppslaget, ikke tabellen

Spør kjernen hva den faktisk ville gjøre: ip route get 10.20.0.5 skriver ut den valgte ruten, utgående grensesnitt og kildeadressen den ville bruke. Et prefiks, en policyregel, en markering eller en foretrukket kilde kan alle endre svaret, og derfor slår det levende oppslaget det å lese tabellen med øyet.

Test en destinasjon innenfor det beskyttede området, ikke gatewayadressen. Å nå gatewayen på den andre siden beviser bare at det finnes en rute; det sier ingenting om subnettet du faktisk trenger. Bekreft deretter at grensesnittet oppslaget valgte, er det du forventer at tunnelen bruker.

Match selektorene på begge sider

Policydatabasen har sine egne oppføringer, og hver av dem angir en retning, en kilde, en destinasjon og en protokoll, og sier deretter hva som skal skje med pakker som passer. Bruk ip xfrm policy for å liste dem; flaggene viser om handlingen er beskytt, omgå eller blokker. En policy der selektorene er bredere eller smalere enn testflyten din vil ikke matche den, og pakken forlater ukryptert. Det er feilen du jager, ikke en manglende rute.

Sammenlign de faktiske verdiene: kilde, destinasjon, protokoll og porter. Hvis oppslaget løste ett adressepar mens policyoppføringen dekker et annet, beskriver de to visningene ulik trafikk. Kjør begge på nytt med samme tuppel før du trekker en konklusjon, ellers redigerer du en policy som aldri var på veien.

En policytreff er ikke installert tilstand

En matchende policy sier bare at pakken må beskyttes; kjernen trenger fortsatt en sikkerhetsassosiasjon for å utføre beskyttelsen. List dem med ip xfrm state, eller med swanctl --list-sas når strongSwan forhandler, og les selektorene og tellerne på hver oppføring.

Når en policy matcher og ingen assosiasjon dekker de samme selektorene, blir pakken droppet i stedet for sendt i klartekst. Det er droppet du skal se etter når tunnelen er oppe, men ett enkelt subnett feiler. Tellerne sier resten: en assosiasjon som aldri øker ble aldri valgt, mens en som øker og likevel ender i et dropp, peker på fjernsiden. Å rette selektorene og å fornye nøkler er forskjellige reparasjoner, så avgjør hvilken du trenger før du rører konfigurasjonen.

Hva en rutebasert tunnel fortsatt krever

Et XFRM-grensesnitt får tunnelen til å se ut som en enhet du kan rute inn i, noe som er virkelig nyttig. Det fjerner ikke policyen og tilstanden som avgjør hva som skjer når pakken kommer dit. Ruten bidrar med et neste hopp og ingenting mer.

Hvis enheten finnes og ruten peker inn i den mens ingen assosiasjon matcher de indre selektorene, blir pakken forkastet, og ingen mengde ruteredigering produserer nøkler eller selektorer. Kontroller grensesnittet med samme kilde og destinasjon som du rutet, og sammenlign det deretter med tilstandslisten.

Avklar eierskapet før du redigerer noe

En vertsbrannmur legger til en tredje beslutning som ingen av de to databasene kjenner. En korrekt rute pluss en matchende policy pluss en installert assosiasjon kan fortsatt ende i en droppet pakke, og applikasjonen rapporterer bare tidsavbruddet. Bekreft at brannmuren tillater den beskyttede trafikken før du klandrer IPsec. Opptak på tunnelenheten og på det fysiske grensesnittet viser hvilken side av krypteringen pakken forsvant på.

Konfigurasjonseierskap avgjør om rettelsen din overlever en omstart. Én komponent kan installere tilstand mens en annen styrer ruter, og en håndredigering av den andre overskrives neste gang tunnelen kommer opp. Endre den eide konfigurasjonen, og les deretter begge visningene på nytt; RFC 4301 holder de to databasene atskilt når du må forklare splittelsen for noen andre.

Relaterte artikler