Hvorfor en IPsec-sikkerhedspolitik ikke er en post i rutetabellen

Ping 10.20.0.5 gennem tunnelen, og der kommer intet tilbage, mens rutetabellen insisterer på, at det undernet er tilgængeligt. Routing og IPsec svarer på forskellige spørgsmål, og kun det ene handler om tilgængelighed. Det fremadrettede opslag vælger en vej, og derefter afgør sikkerhedspolitikkens database, om den vej skal beskyttes, lades i fred eller afvises. Når de to er uenige, dør pakken stille, så læs dem i den rækkefølge.

Begynd med opslaget, ikke tabellen

Spørg kernen, hvad den virkelig ville gøre: ip route get 10.20.0.5 viser den valgte rute, udgangsgrænsefladen og den kildeadresse, den ville bruge. Et præfiks, en politikregel, et mærke eller en foretrukken kilde kan ændre svaret, og derfor slår det levende opslag det at læse tabellen med øjet.

Test en destination inde i det beskyttede område, ikke gateway-adressen. At nå gatewayen på den anden side beviser kun, at der findes en rute; det siger intet om det undernet, du faktisk har brug for. Bekræft derefter, at den grænseflade, opslaget valgte, er den, du forventer, tunnelen bruger.

Match selektorerne på begge sider

Politikdatabasen har sine egne poster, og hver af dem angiver en retning, en kilde, en destination og en protokol og siger derefter, hvad der skal ske med matchende pakker. Brug ip xfrm policy til at liste dem; flagene viser, om handlingen er beskyttelse, omgåelse eller blokering. En politik, hvis selektorer er bredere eller smallere end dit testflow, matcher det ikke, og pakken forlader ukrypteret. Det er den fejl, du jagter, ikke en manglende rute.

Sammenlign de faktiske værdier: kilde, destination, protokol og porte. Hvis opslaget opløste ét adressepar, mens politikposten dækker et andet, beskriver de to visninger forskellig trafik. Kør begge igen med samme tuple, før du drager en konklusion, ellers redigerer du en politik, der aldrig var på vejen.

Et politikhit er ikke installeret tilstand

En matchende politik siger kun, at pakken skal beskyttes; kernen har stadig brug for en sikkerhedsassociation for at udføre beskyttelsen. List dem med ip xfrm state eller med swanctl --list-sas, når strongSwan forhandler, og læs selektorerne og tællerne på hver post.

Når en politik matcher, og ingen association dækker de samme selektorer, droppes pakken i stedet for at blive sendt i klartekst. Det er det drop, du skal lede efter, når tunnelen er oppe, men et enkelt undernet fejler. Tællerne fortæller resten: en association, der aldrig stiger, blev aldrig valgt, mens en der stiger og alligevel ender i et drop, peger på den fjerne side. At rette selektorer og at forny nøgler er forskellige reparationer, så afgør, hvilken du har brug for, før du rører konfigurationen.

Hvad en rutebaseret tunnel stadig kræver

En XFRM-grænseflade får tunnelen til at ligne en enhed, du kan route ind i, hvilket er virkelig nyttigt. Den fjerner ikke den politik og tilstand, der afgør, hvad der sker, når pakken ankommer dertil. Ruten bidrager med et næste hop og intet mere.

Hvis enheden findes, og ruten peger ind i den, mens ingen association matcher de indre selektorer, kasseres pakken, og ingen mængde ruteændringer frembringer nøgler eller selektorer. Kontroller grænsefladen med samme kilde og destination, som du rutede, og sammenlign det derefter med tilstandslisten.

Afklar ejerskabet, før du redigerer noget

En firewall på værten tilføjer en tredje beslutning, som ingen af de to databaser kender. En korrekt rute plus en matchende politik plus en installeret association kan stadig ende i en droppet pakke, og applikationen rapporterer kun timeoutet. Bekræft, at firewallen tillader den beskyttede trafik, før du bebrejder IPsec. Optagelse på tunneleenheden og på den fysiske grænseflade viser, hvilken side af krypteringen pakken forsvandt på.

Konfigurationsejerskab afgør, om din rettelse overlever en genstart. En komponent kan installere tilstand, mens en anden styrer ruter, og en håndredigering af den anden overskrives, næste gang tunnelen kommer op. Ændr den ejende konfiguration, og læs derefter begge visninger igen; RFC 4301 holder de to databaser adskilt, når du skal forklare opdelingen for en anden.