IKE SA etablert, CHILD SA mangler: der dataene stopper

Klienten sier at den er autentisert, IKE-statusen ser sunn ut, og pakketellerne blir stående på null. Denne kombinasjonen er ingen selvmotsigelse: IKEv2 holder en kontrollrelasjon og en datarelasjon atskilt, og den første kan lykkes mens den andre aldri kommer opp. Forelderen håndterer forhandlingen; barnet håndterer trafikken. Les de to lagene hver for seg før du kaller tunnelen nede.

Hva de to SA-ene gjør

IKE SA er kontrollrelasjonen: den autentiserer partene og bærer utvekslingene som forhandler, erstatter og fjerner beskyttelse. Den bærer aldri applikasjonspakkene dine. En sunn forelder beviser derfor bare at de to endene kan bli enige om sikkerhetspolicyen, og ikke noe mer.

En CHILD SA er datarelasjonen, opprettet under forelderen, med trafikkselektorer og nøkkelmateriale for ett beskyttet sett. Den er retningsbestemt, så statusutskriften viser en inngående og en utgående assosiasjon med separate identifikatorer, og vanligvis separate tellere for hver retning. Dette paret er grunnen til at én retning kan virke mens den andre faller, og til at uttrykket tunnelen er oppe ikke sier noe om trafikk. En forelder kan også holde flere barn, og slik skjuler én tilkoblingsetikett det du trenger.

Les barnets oppføringer, ikke tilkoblingsetiketten

Åpne forelderstatusen og barnelisten sammen, og finn barnet hvis selektorer samsvarer med flyten du tester. Noter trafikkselektorene, de forhandlede algoritmene, levetiden og tellerne i begge retninger. Hvis det finnes flere barn, match på selektorer og ikke på posisjon, fordi posisjonen endres etter en nøkkelreversering. Skriv ned identifikatorene før du endrer noe.

Hvis forelderen lister et annet trafikksett enn det du tester, leser du feil barn. Det er et selektorproblem, ikke en ødelagt tunnel.

Registrer tidsstempler også. En nøkkelreversering kan erstatte ett lag mens det andre forblir etablert, og et barn som ser nytt ut, kan være erstatningen for det du fulgte med på. Sammenlign identifikatorene før du konkluderer med at et barn forsvant.

Når det ikke finnes noe barn

Autentiseringen kan lykkes mens datatilbudet eller selektorene feiler, og da blir forelderen stående helt uten barn. Den vanlige årsaken er en algoritmeforskjell eller en forskjell i trafikkselektorene, og begge partene logger det avviste tilbudet. Les begge ender, fordi siden du når, kanskje bare viser avvisningen. Rett opp forskjellen i stedet for å starte forelderen på nytt, for det gjentar den samme mislykkede forhandlingen og legger en ny avbrudd til beviset.

En forelder som stadig etablerer seg på nytt, er en annen feil enn en forelder som blir stående uten barn. I det andre tilfellet navngir loggene tilbudet som ble avvist, så samle det tilbudet fra begge ender før du endrer en policy.

Når barnet finnes, men tellerne blir stående på null

Send en ny forespørsel som samsvarer med barnets selektorer. En forespørsel til en destinasjon utenfor den policyen flytter ikke tellerne, uansett hvor vellykket den ser ut.

Kontroller ruten som skal presse flyten inn i tunnelen, fordi et barn uten trafikk ofte er et barn ingenting rutes til. Tellere som bare beveger seg i én retning, peker på en selektor- eller policyforskjell på returveien. Se på den eksterne partens returselektorer før du rører den lokale siden. En ny forespørsel gir deg også et tidsstempel å korrelere mot begge enders statusutskrift.

Navngi laget i rapporten

Rapporter feilen som tre felt og ikke en dom: laget som feilet, utvekslingen eller barnet du undersøkte, og beviset du har. Laget er ett av tre: forelderen ble aldri etablert, barnets forhandling ble avvist, eller et barn finnes og trafikken når det ikke. Beviset er barnets identifikator med selektorene og tellerne, eller det avviste tilbudet sitert fra begge loggene. Den som leser det, kan gå rett til utvekslingen som betyr noe, i stedet for å spørre hvilken VPN du mener.

strongSwan IKEv2-dokumentasjonen viser hvordan disse lagene ser ut i statusutskriften. Legg ved barnets utskrift du testet, ikke bare forelderens sammendrag.