IPsec-barn-SA är uppe men paketräknarna står kvar på noll

Du fick upp tunneln, omnycklingstimern räknar ner och båda riktningarna läser fortfarande noll paket. Ingenting i det talparet säger att peer-n avvisade din tunnel: en installerad CHILD SA med vilande räknare är det normala tillståndet för en association som ingenting har matchat ännu. Arbetet är att bevisa att ett paket borde ha matchat och sedan hitta punkten där det lämnade den väg som selektorerna beskriver. Gör det en gång, i ordning, och håll förfrågan identisk mellan körningarna.

Vad en nollräknare faktiskt bevisar

En CHILD SA är ett selektorpar plus nycklarna och SPI:n som krypterar trafik som faller inom dessa intervall. Att installera en betyder bara att båda peer-n kom överens om intervallen och de härledda nycklarna; kärnan håller den i timmar utan att ett enda paket anländer. Frågan är därför aldrig om tunneln finns, utan om något paket som ditt test skickade föll inom de intervall som de två peer-n förhandlade fram. Om inget gjorde det står räknarna kvar på noll och associationen löper ut oanvänd vid slutet av sin livstid.

Den skillnaden ändrar vad du undersöker först. Ett avvisat förslag, ett autentiseringsfel eller en döende IKE SA dyker alla upp i loggen eller i SA-listan, inte som en tyst nolla. En tunnel som förhandlar rent och sedan blir vilande pekar i stället på matchning, routing eller ursprunget för testtrafiken.

Skicka ett flöde du kan beskriva innan du skickar det

Välj ett mål inne i det skyddade subnätet och öppna en ny anslutning till det; en sida du laddade för en timme sedan kan komma från cachen, och ett cachat svar rör aldrig tunneln. Skriv sedan ner fyra värden medan förfrågan fortfarande är hypotetisk: källadressen som applikationen kommer att binda, målet, adressfamiljen och namnet eller selektorparet för barnet du bevakar. Den anteckningen är det som förvandlar en platt räknare till ett testbart påstående.

Källadressen är värdet folk hoppar över, och det är den som oftast förstör testet. En laptop med en trådbunden adress, en Wi-Fi-adress och en tunneladress kan binda vilken som helst av dem beroende på ruttuppslaget, och bara en kan ligga inom det förhandlade intervallet. Använd ett verktyg som låter dig nåla källan, till exempel ping -I 10.1.0.5 10.2.0.9 eller curl --interface 10.1.0.5, så att paketet inte tyst kan välja en annan adress. När den nålades körning flyttar räknarna och den onålades inte gör det, har du hittat ett routingproblem och inte ett IPsec-problem.

Vilka tal du ska läsa, och var de bor

På Linux skriver ip -s xfrm state ut varje association med en lifetime current:-rad vars byte- och paketsumma tillhör just den SA:n, följd av en stats:-rad för replay- och felräkningar. Hos en strongSwan-peer skriver swanctl --list-sas ut en in-rad och en out-rad per installerat barn, var och en slutar med en byte- och en paketräkning; de äldre stroke-verktygen kallar samma par bytes_i och bytes_o. Läs de två riktningarna separat, för den som blev stående platt är fyndet. Att lägga ihop dem döljer precis den asymmetri du letar efter.

Båda vyerna är per association, så en omnyckling installerar ett nytt SPI-par och din baslinje går tillbaka till noll utan att något är trasigt. Anteckna SPI:n du bevakar innan omnycklingstimern slår till, annars jämför du en ny SA med ett gammalt tal. Om utgående stiger medan ingående står stilla har selektorn matchat och svaret kom aldrig tillbaka, vilket flyttar utredningen till peer-ns vidarebefordran och dess egen policy. strongSwans IKEv2-konfigurationsdokumentation täcker barn-SA:ns livscykel och omnycklingstidpunkten bakom dessa siffror.

Observationspunkten är en separat variabel från paketets ursprung. En hårdvaruavlastning kan öka associationens räknare medan en mjukvarufångst på gränssnittet inte visar något, eftersom avlastade paket hoppar över kroken som fångsten sitter på, och ingående trafik kan avvika på samma sätt. När de två inte är överens, använd räknarna för att svara på om något matchade och fångsten för att svara på hur paketet såg ut.

Rutt, selektorer och var paketet föddes

Jämför tre saker sida vid sida: rutten som kärnan väljer för ditt mål, policyn som styr trafik in i tunneln och selektorparet som barnet förhandlade fram. ip route get 10.2.0.9 from 10.1.0.5 namnger gränssnittet och källan som kärnan skulle använda, vilket ofta inte är paret du antog. ip xfrm policy visar mallarna och selektorerna som installerats lokalt, medan swanctl --list-sas visar vad peer-n gick med på. Ett uppslag som skickar paketet ut genom det fysiska gränssnittet når aldrig policyn, så räknarna kan inte flytta sig.

Felaktiga matchningar kommer i flera former som ser identiska ut från en räknare. Ett IPv6-mål utanför en IPv4-selektor, en källadress från fel subnät och en policy som är snävare än barnet ger alla samma nolla. Åtgärda den snävaste orsaken först, för att vidga en selektor bara för att flytta ett tal ändrar vad tunneln skyddar.

Sedan finns paketets ursprung, fällan som en gateway lägger ut för sin egen operatör. Trafik som gatewayen själv genererar matchas mot output-policyn, medan ett paket den vidarebefordrar för en klient matchas mot forward-policyn, så en ping från lådan kan lyckas på en väg som ingen klient någonsin tar.

En enda reversibel ändring och en rapport som tål granskning

Ändra ett enda element, upprepa den identiska förfrågan och läs samma räknare. Att rensa alla brandväggsregler eller byta ut alla selektorer på en gång kommer att flytta ett tal och förstöra beviset som berättade varför. Om den andra körningen fortfarande visar noll har du uteslutit en hypotes i stället för att slösa bort eftermiddagen.

Skriv fyndet i en form som någon annan kan återskapa: barnets namn, accepterade intervall, källan du nålades, målet du testade, riktningen som stannade på noll och SPI:n du läste. Den meningen skiljer en association som ingen använde från en fjärrapplikation som tog emot trafiken och avvisade den. Rulla tillbaka ändringen när den inte flyttade räknarna och behåll anteckningen; nästa person börjar där du slutade. Ingenting i tunneln behövde byggas om för något av detta, och det är poängen med att kontrollera matchning innan du rör konfigurationen.