IKE-SA er etableret, CHILD-SA mangler: hvor data stopper

Klienten siger, at den blev autentificeret, IKE-status ser sund ud, og pakketællerne bliver på nul. Den kombination er ikke en modsætning: IKEv2 holder et kontrolforhold og et dataforhold adskilt, og det første kan lykkes, mens det andet aldrig kommer op. Forælderen tager sig af forhandlingen; barnet tager sig af trafikken. Læs de to lag hver for sig, før du kalder tunnelen nede.

Hvad de to SA’er gør

IKE-SA’en er kontrolforholdet: den autentificerer parterne og bærer de udvekslinger, der forhandler, erstatter og fjerner beskyttelse. Den bærer aldrig dine applikationspakker. En sund forælder beviser derfor kun, at de to ender kan blive enige om en sikkerhedspolitik, og intet mere.

En CHILD-SA er dataforholdet, oprettet under forælderen, med trafikselektorer og nøglemateriale til ét beskyttet sæt. Det er retningsbestemt, så statusoutput lister en indgående og en udgående association med separate id’er og som regel separate tællere for hver retning. Netop den parring forklarer, hvorfor én retning kan virke, mens den anden falder, og hvorfor sætningen tunnelen er oppe intet siger om trafik. En forælder kan også holde flere børn, og det er sådan én enkelt forbindelsesetikette skjuler den, du har brug for.

Læs child-posterne, ikke forbindelsesetiketten

Åbn forælderens status og child-listen sammen, og find det child, hvis selektorer matcher den strøm, du tester. Notér dets trafikselektorer, de forhandlede algoritmer, dets levetid og tællerne i begge retninger. Hvis der findes flere børn, så match på selektorer i stedet for på position, for positionen ændrer sig efter en nøglefornyelse. Skriv id’erne ned, før du ændrer noget.

Hvis forælderen viser et andet trafikssæt end det, du tester, læser du det forkerte child. Det er et selektorproblem, ikke en brudt tunnel.

Notér også tidsstempler. Nøglefornyelse kan erstatte et lag, mens det andet forbliver etableret, og et child, der ser nyt ud, kan være erstatningen for det, du overvågede. Sammenlign id’erne, før du konkluderer, at et child er forsvundet.

Når der ikke findes noget child

Autentificering kan lykkes, mens datatilbuddet eller selektorerne fejler, og så står forælderen helt uden child. Den sædvanlige årsag er uenighed om algoritmen eller om trafikselektorerne, og begge parter logger det afviste tilbud. Læs begge ender, for den side, du kan nå, viser måske kun afvisningen. Ret uenigheden i stedet for at genstarte forælderen, som gentager den samme mislykkede forhandling og tilføjer et afbrud til beviserne.

En forælder, der hele tiden genetableres, er en anden fejl end en forælder, der står uden child. I det andet tilfælde navngiver loggene det afviste tilbud, så indsaml det tilbud fra begge ender, før du retter en politik.

Når childet findes, men tællerne bliver på nul

Send en ny anmodning, der matcher childets selektorer. En anmodning til en destination uden for den politik flytter ikke dets tællere, hvor vellykket den end ser ud.

Kontrollér den rute, der skal skubbe strømmen ind i tunnelen, for et child uden trafik er ofte et child, som intet routes til. Tællere, der kun bevæger sig i én retning, peger på uenighed om selektorer eller politik på returvejen. Se på den fjerne parts returselektorer, før du rører den lokale side. En ny anmodning giver dig også et tidsstempel at korrelere med begge enders statusoutput.

Navngiv laget i rapporten

Rapportér fejlen som tre felter i stedet for en dom: laget, der fejlede, den udveksling eller det child, du undersøgte, og det bevis, du har. Laget er et af tre: forælderen blev aldrig etableret, child-forhandlingen blev afvist, eller der findes et child, og trafikken når ikke frem til det. Beviset er childets id med dets selektorer og tællere, eller det afviste tilbud citeret fra begge logs. Enhver, der læser det, kan gå direkte til den udveksling, der betyder noget, i stedet for at spørge, hvilken VPN du mener.

Dokumentationen for strongSwan om IKEv2 viser, hvordan disse lag ser ud i statusoutput. Vedlæg det child-output, du testede, ikke kun forælderens resumé.