Varför en IPsec-säkerhetspolicy inte är en post i routingtabellen
En fungerande rutt bevisar ingenting om IPsec. Läs ruttuppslaget och policyselektorerna för samma flöde och bekräfta sedan att en association täcker det.
Pinga 10.20.0.5 genom tunneln och ingenting kommer tillbaka, medan routingtabellen insisterar på att subnätet är nåbart. Routning och IPsec svarar på olika frågor, och bara en av dem handlar om nåbarhet. Framåtsökningen väljer en väg, sedan avgör databasen för säkerhetspolicy om den vägen ska skyddas, lämnas som den är eller avvisas. När de två är oense dör paketet tyst, så läs dem i den ordningen.
Börja med uppslaget, inte tabellen
Fråga kärnan vad den egentligen skulle göra: ip route get 10.20.0.5 skriver ut den valda rutten, utgående gränssnitt och källadressen den skulle använda. Ett prefix, en policyregel, en markering eller en föredragen källa kan ändra svaret, och därför slår det levande uppslaget att läsa tabellen med ögat.
Testa en destination inom det skyddade intervallet, inte gatewayadressen. Att nå gatewayen på andra sidan bevisar bara att det finns en rutt; det säger ingenting om subnätet du faktiskt behöver. Bekräfta sedan att gränssnittet uppslaget valde är det du förväntar dig att tunneln använder.
Matcha selektorerna på båda sidor
Policydatabasen har egna poster, och var och en anger en riktning, en källa, en destination och ett protokoll, och säger sedan vad som ska hända med matchande paket. Använd ip xfrm policy för att lista dem; flaggorna visar om åtgärden är skydda, kringgå eller blockera. En policy vars selektorer är bredare eller smalare än ditt testflöde matchar det inte, och paketet lämnar oskyddat. Det är felet du jagar, inte en saknad rutt.
Jämför de faktiska värdena: källa, destination, protokoll och portar. Om uppslaget löste ett adresspar medan policyposten täcker ett annat, beskriver de två vyerna olika trafik. Kör om båda med samma tupel innan du drar en slutsats, annars redigerar du en policy som aldrig var på vägen.
En policytreff är inte installerat tillstånd
En matchande policy säger bara att paketet måste skyddas; kärnan behöver fortfarande en säkerhetsassociation för att utföra skyddet. Lista dem med ip xfrm state, eller med swanctl --list-sas när strongSwan förhandlar, och läs selektorerna och räknarna på varje post.
När en policy matchar och ingen association täcker samma selektorer, släpps paketet i stället för att skickas i klartext. Det är släppet du ska leta efter när tunneln är uppe men ett enda subnät misslyckas. Räknarna säger resten: en association som aldrig ökar valdes aldrig, medan en som ökar och ändå slutar i ett släpp pekar på fjärrsidan. Att rätta selektorer och att förnya nycklar är olika reparationer, så bestäm vilken du behöver innan du rör konfigurationen.
Vad en ruttbaserad tunnel fortfarande kräver
Ett XFRM-gränssnitt får tunneln att se ut som en enhet du kan routa in i, vilket verkligen är användbart. Det tar inte bort policyn och tillståndet som avgör vad som händer när paketet kommer dit. Rutten bidrar med ett nästa hopp och ingenting mer.
Om enheten finns och rutten pekar in i den medan ingen association matchar de inre selektorerna, kastas paketet, och ingen mängd ruttredigering producerar nycklar eller selektorer. Kontrollera gränssnittet med samma källa och destination som du routade, och jämför det sedan med tillståndslistan.
Klargör ägarskapet innan du redigerar något
En brandvägg på värden lägger till ett tredje beslut som ingen av de två databaserna känner till. En korrekt rutt plus en matchande policy plus en installerad association kan fortfarande sluta i ett släppt paket, och programmet rapporterar bara tidsgränsen. Bekräfta att brandväggen tillåter den skyddade trafiken innan du skyller på IPsec. Avlyssning på tunnelenheten och på det fysiska gränssnittet visar på vilken sida av krypteringen paketet försvann.
Konfigurationens ägarskap avgör om din rättelse överlever en omstart. En komponent kan installera tillstånd medan en annan hanterar rutter, och en handredigering av den andra skrivs över nästa gång tunneln kommer upp. Ändra den ägande konfigurationen och läs sedan om båda vyerna; RFC 4301 håller de två databaserna åtskilda när du måste förklara uppdelningen för någon annan.