DPD-svar beviser at IKE-motparten lever, ikke at dataene dine flyter
Livstidssvar, en padding-melding og innsnevrede selektorer beskriver tre forskjellige ting. Les dem hver for seg før du gir en av dem skylden for en stans.
IPsec-logger kan vise livstidssvar mens applikasjonen foran dem står, og begge fakta kan være sanne samtidig. Et DPD-svar fastslår at motpartens IKE-behandling svarte i det øyeblikket; det sier ingenting om hvorvidt barn-SA-en bærer pakken du bryr deg om. Å behandle hver advarsel nær et utfall som årsaken til utfallet er hvordan et selektorproblem blir diagnostisert som en protokollfeil. Tre observasjoner blir oftest forvekslet, og de svarer på tre forskjellige spørsmål. Les dem etter sammenheng og formål før du leser dem etter tidsstempel.
Hva hver observasjon beviser
Tabellen skiller hva hver observasjon fastslår fra hva den bare følger med.
| 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 |
Ingen av de tre er en feil i seg selv. Hver av dem blir først interessant ved siden av strømmen du feilsøker, og en rad som ikke kan knyttes til en bestemt strøm, er kontekst snarere enn bevis.
Livstid er ikke datahelse
DPD kjører som en INFORMATIONAL-utveksling, en kontrollplansamtale mellom IKE-daemoner. Et svar beviser at motpartens IKE-prosess er nåbar og villig til å svare, og en tidsavbrudd beviser at den ikke er det. Ingen av resultatene prøver barn-SA-en, selektorene, videresendingsveien eller applikasjonens svar, så en sunn DPD ved siden av en fastlåst overføring er et sammenhengende bilde snarere enn en motsigelse.
Derfor er livstidslinjene den minst nyttige delen av en dataplanbillett, uansett hvor beroligende de ser ut øverst i loggen.
Padding-meldingen er en uttalelse om padding
TFC-padding er den mest overlesste linjen i disse loggene. Den sier at padding for trafikkstrømkonfidensialitet ikke vil bli akseptert for den barn-SA-en, noe som er en uttalelse om en valgfri paddingfunksjon snarere enn en avvisning av ESP-beskyttelse. Å finne den nær en feil er som regel en tilfeldighet av ordrikdom, og å slå padding på eller av endrer ingenting ved selektordekningen.
Den IKEv2-spesifikasjonen definerer både meldingen og selektorforhandlingen, og en implementasjons advarselsetikett erstatter ikke protokollbetydningen i noen av de to tilfellene.
Innsnevring er stillere og mer sannsynlig viktig
En responder kan godta en delmengde av de tilbudte selektorene, og det aksepterte settet kan skrives ut over flere oppføringer, én portkvalifisert og en annen som dekker alle porter. Å lese bare den første portkvalifiserte linjen undervurderer det som ble akseptert; å lese bare den brede linjen overvurderer det. Sammenlign det utskrevne forslaget med den installerte policyen, fordi forslaget er det motpartene sa, og policyen er det kjernen vil matche. Når de ikke stemmer overens, finnes tunnelen og trafikken ikke, som er den klassiske periodiske klagen. Snu det lokale og det fjerne perspektivet når du sammenligner motparter, fordi hver sides lokale er den andres fjerne.
Vertsspesifikke oppføringer med en portbegrensning er verdt å lese to ganger, fordi det er dem som utelukker ICMP eller en annen port mens en ping til gatewayen fortsatt virker.
Bygg én registrering for strømmen som feiler
Registrer kilde, mål, adressefamilie, protokoll og port slik de ses ved beskyttelsesbeslutningen, inkludert enhver bevisst oversettelse. Det er verdiene som må matche en selektor, og det er også verdiene folk skriver inn på nytt fra hukommelsen når billetten når et tredje par hender.
Identifiser deretter barn-SA-en og dens retningsbestemte tellere: swanctl --list-sas gir assosiasjonsoversikten på en strongSwan-vert, og ip -s xfrm state gir tellerne. Les dem etter en fersk tillatt forespørsel i stedet for mens systemet er inaktivt. Ingen økning i utgående trafikk peker på seleksjonen eller den lokale veien; utgående uten tilsvarende inngående peker på motparten, videresendingen eller svarene.
En fullført applikasjonsutveksling veier tyngre enn noen av tellerne, og derfor bør testen slutte ved applikasjonen snarere enn ved tunnelindikatoren.
Velg korreksjonen etterpå
Først når den registreringen finnes, er det en korreksjon å velge: aksepterte selektorer, rute, filtrering, motpartens implementasjon eller en grense du nå har demonstrert. Å tilbakestille motparten endrer flere tilstander på én gang og gjenoppretter ofte trafikken uten å forklare hvilken som var feil, så utfallet kommer tilbake. Hold kjerntilstands-dumper ute av billettene også, fordi de kan inneholde nøkler, og det korte sammendraget er nok for alle som må hjelpe.
Når registreringen motsier din første teori, tro på registreringen og skriv teorien på nytt; den vanen er mer verdt enn noen enkelt logglinje som diskuteres her.