DPD-antwoorden bewijzen dat de IKE-peer leeft, niet dat uw data stromen
Levendigheidsantwoorden, een padding-melding en versmalde selectors beschrijven drie verschillende dingen. Lees ze apart voordat u een ervan de schuld geeft van een stagnatie.
IPsec-logboeken kunnen levendigheidsantwoorden tonen terwijl de toepassing ervoor vastloopt, en beide feiten kunnen tegelijk waar zijn. Een DPD-antwoord stelt vast dat de IKE-verwerking van de peer op dat moment antwoordde; het zegt niets over de vraag of de child-SA het pakket vervoert dat u belangrijk vindt. Elke waarschuwing bij een storing als de oorzaak ervan behandelen is de manier waarop een selectorprobleem als een protocolfout wordt gediagnosticeerd. Drie observaties worden het vaakst verward, en ze beantwoorden drie verschillende vragen. Lees ze op samenhang en doel voordat u ze op tijdstempel leest.
Wat elke observatie bewijst
De tabel scheidt wat elke observatie vaststelt van wat ze slechts vergezelt.
| Observation | What it establishes | What it leaves open |
|---|---|---|
| DPD replies arrive | The peer's IKE process answered | The child SA, forwarding path and application reply |
| TFC padding notification | The peer will not accept padding for that child SA | Whether ordinary ESP protection still works, which it does |
| Selectors reported as narrowed | The accepted traffic set is a subset of the offer | Whether the subset includes the flow the user needs |
Geen van de drie is op zichzelf een fout. Elk wordt pas interessant naast de stroom die u debugt, en een rij die niet aan een specifieke stroom kan worden gekoppeld is context, geen bewijs.
Levendigheid is geen datagezondheid
DPD draait als een INFORMATIONAL-uitwisseling, een gesprek op de controlevlakte tussen IKE-daemons. Een antwoord bewijst dat het IKE-proces van de peer bereikbaar is en bereid is te antwoorden, en een time-out bewijst dat het dat niet is. Geen van beide resultaten test de child-SA, de selectors, het doorstuurpad of het antwoord van de toepassing, dus een gezonde DPD naast een vastgelopen overdracht is een samenhangend beeld en geen tegenspraak.
Daarom zijn de levendigheidsregels het minst nuttige deel van een datavlak-ticket, hoe geruststellend ze bovenaan het log ook lijken.
De padding-melding is een uitspraak over padding
TFC-padding is de meest overgelezen regel in deze logboeken. Hij zegt dat padding voor verkeersstroomvertrouwelijkheid niet wordt geaccepteerd voor die child-SA, wat een uitspraak is over een optionele paddingfunctie en geen afwijzing van ESP-bescherming. Hem bij een fout vinden is meestal een toevalligheid van breedsprakigheid, en padding aan- of uitzetten verandert niets aan de selectordekking.
De IKEv2-specificatie definieert zowel de melding als de selectoronderhandeling, en het waarschuwingslabel van een implementatie vervangt in geen van beide gevallen de protocolbetekenis.
Versmalling is stiller en waarschijnlijker van belang
Een responder kan een deelverzameling van de aangeboden selectors accepteren, en de geaccepteerde verzameling kan over meerdere vermeldingen worden afgedrukt, één poortgekwalificeerd en een ander die alle poorten dekt. Alleen de eerste poortgekwalificeerde regel lezen onderschat wat is geaccepteerd; alleen de brede regel lezen overschat het. Vergelijk het afgedrukte voorstel met het geïnstalleerde beleid, want het voorstel is wat de peers zeiden en het beleid is wat de kernel gaat matchen. Als ze van elkaar afwijken, bestaat de tunnel en het verkeer niet, wat de klassieke periodieke klacht is. Draai het lokale en het externe perspectief om wanneer u peers vergelijkt, want het lokale van elke kant is het externe van de ander.
Hostspecifieke vermeldingen met een poortbeperking zijn een tweede lezing waard, want dat zijn de vermeldingen die ICMP of een tweede poort uitsluiten terwijl een ping naar de gateway blijft werken.
Bouw één registratie voor de stroom die mislukt
Noteer bron, bestemming, adresfamilie, protocol en poort zoals ze bij de beschermingsbeslissing te zien zijn, inclusief elke bewuste vertaling. Dat zijn de waarden die met een selector moeten overeenkomen, en het zijn ook de waarden die mensen uit het geheugen opnieuw typen wanneer het ticket bij een derde paar handen aankomt.
Identificeer dan de child-SA en zijn gerichte tellers: swanctl --list-sas geeft de associatie-samenvatting op een strongSwan-host, en ip -s xfrm state geeft de tellers. Lees ze na een verse toegestane aanvraag en niet terwijl het systeem inactief is. Geen toename in uitgaand verkeer wijst op selectie of het lokale pad; uitgaand zonder bijbehorend inkomend wijst op de peer, zijn doorsturing of zijn antwoorden.
Een voltooide toepassingsuitwisseling weegt zwaarder dan elk van de tellers, daarom zou de test bij de toepassing moeten eindigen en niet bij de tunnelindicator.
Kies daarna de correctie
Pas als die registratie bestaat, is er een correctie te kiezen: geaccepteerde selectors, route, filtering, peer-implementatie of een grens die u nu heeft aangetoond. Het resetten van de peer verandert meerdere toestanden tegelijk en herstelt vaak het verkeer zonder uit te leggen welke fout was, waardoor de storing terugkomt. Houd kernel-toestandsdumps ook buiten tickets, want ze kunnen sleutels bevatten en de smalle samenvatting is voldoende voor iedereen die moet helpen.
Wanneer de registratie uw eerste theorie tegenspreekt, geloof de registratie en herschrijf de theorie; die gewoonte is meer waard dan welke enkele logregel dan ook die hier wordt besproken.