IKE SA etablerad, CHILD SA saknas: där data stannar

Klienten säger att den är autentiserad, IKE-statusen ser frisk ut och paketräknarna står kvar på noll. Den kombinationen är ingen motsägelse: IKEv2 håller en kontrollrelation och en datarelation åtskilda, och den första kan lyckas medan den andra aldrig kommer upp. Föräldern sköter förhandlingen; barnet sköter trafiken. Läs de två lagren var för sig innan du kallar tunneln nere.

Vad de två SA:erna gör

IKE SA är kontrollrelationen: den autentiserar parterna och bär de utbyten som förhandlar, ersätter och tar bort skydd. Den bär aldrig dina programpaket. En frisk förälder bevisar därför bara att de två ändarna kan enas om säkerhetspolicyn, och inget mer.

En CHILD SA är datarelationen, skapad under föräldern, med trafikselektorer och nyckelmaterial för en skyddad mängd. Den är riktad, så statusutskriften listar en inkommande och en utgående association med separata identifierare och vanligtvis separata räknare för varje riktning. Det paret är skälet till att en riktning kan fungera medan den andra faller, och till att frasen tunneln är uppe inte säger något om trafik. En förälder kan också hålla flera barn, och så döljer en enda anslutningsetikett den du behöver.

Läs barnets poster, inte anslutningsetiketten

Öppna förälderns status och barnlistan tillsammans och hitta barnet vars selektorer matchar flödet du testar. Notera dess trafikselektorer, de förhandlade algoritmerna, dess livstid och räknarna i båda riktningarna. Om det finns flera barn, matcha på selektorer och inte på position, eftersom positionen ändras efter en nyckelomförhandling. Skriv ner identifierarna innan du ändrar något.

Om föräldern listar en annan trafikmängd än den du testar, läser du fel barn. Det är ett selektorproblem, inte en trasig tunnel.

Registrera tidsstämplar också. En nyckelomförhandling kan ersätta ett lager medan det andra förblir etablerat, och ett barn som ser nytt ut kan vara ersättaren för det du bevakade. Jämför identifierarna innan du drar slutsatsen att ett barn försvann.

När det inte finns något barn

Autentiseringen kan lyckas medan dataförslaget eller selektorerna misslyckas, och då blir föräldern stående helt utan barn. Den vanliga orsaken är en algoritmskillnad eller en skillnad i trafikselektorer, och båda parterna loggar det avvisade förslaget. Läs båda ändarna, eftersom sidan du når kanske bara visar avvisningen. Rätta till skillnaden i stället för att starta om föräldern, som upprepar samma misslyckade förhandling och lägger till ännu ett avbrott i beviset.

En förälder som ständigt etableras på nytt är ett annat fel än en förälder som står uppe utan barn. I det andra fallet namnger loggarna det avvisade förslaget, så samla det förslaget från båda ändarna innan du ändrar en policy.

När barnet finns men räknarna står kvar på noll

Skicka en ny begäran som matchar barnets selektorer. En begäran till ett mål utanför den policyn flyttar inte räknarna, hur lyckad den än ser ut.

Kontrollera rutten som ska pressa in flödet i tunneln, eftersom ett barn utan trafik ofta är ett barn som ingenting dirigeras till. Räknare som bara rör sig i en riktning pekar på en selektor- eller policyskillnad på returvägen. Titta på den avlägsna partens returselektorer innan du rör den lokala sidan. En ny begäran ger dig också en tidsstämpel att korrelera mot båda ändarnas statusutskrift.

Namnge lagret i rapporten

Rapportera felet som tre fält och inte som en dom: lagret som misslyckades, utbytet eller barnet du undersökte och beviset du har. Lagret är ett av tre: föräldern etablerades aldrig, barnets förhandling avvisades, eller ett barn finns och trafiken når det inte. Beviset är barnets identifierare med dess selektorer och räknare, eller det avvisade förslaget citerat från båda loggarna. Den som läser det kan gå rakt till utbytet som spelar roll i stället för att fråga vilken VPN du menar.

strongSwan IKEv2-dokumentationen visar hur de lagren ser ut i statusutskriften. Bifoga barnets utskrift du testade, inte bara förälderns sammanfattning.