DPD-svar beviser, at IKE-peer'en lever, ikke at dine data flyder
Livstidssvar, en padding-meddelelse og indsnævrede selektorer beskriver tre forskellige ting. Læs dem hver for sig, før du giver en af dem skylden for en pause.
IPsec-logfiler kan vise livstidssvar, mens applikationen foran dem går i stå, og begge fakta kan være sande på samme tid. Et DPD-svar fastslår, at peer'ens IKE-behandling svarede i det øjeblik; det siger intet om, hvorvidt child SA'en bærer den pakke, du bekymrer dig om. At behandle enhver advarsel nær et udfald som årsagen til udfaldet er, hvordan et selektorproblem bliver diagnosticeret som en protokolfejl. Tre observationer bliver oftest forvekslet, og de besvarer tre forskellige spørgsmål. Læs dem efter sammenhæng og formål, før du læser dem efter tidsstempel.
Hvad hver observation beviser
Tabellen adskiller, hvad hver observation fastslår, fra hvad den blot ledsager.
| 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 af de tre er en fejl i sig selv. Hver af dem bliver først interessant ved siden af den strøm, du fejlretter, og en række, der ikke kan knyttes til en bestemt strøm, er kontekst snarere end bevis.
Livstid er ikke datasundhed
DPD kører som en INFORMATIONAL-udveksling, en kontrolplanssamtale mellem IKE-dæmoner. Et svar beviser, at peer'ens IKE-proces kan nås og er villig til at svare, og en timeout beviser, at den ikke er. Ingen af resultaterne afprøver child SA'en, selektorerne, videresendelsesvejen eller applikationens svar, så et sundt DPD ved siden af en fastlåst overførsel er et sammenhængende billede snarere end en modsigelse.
Derfor er livstidslinjerne den mindst nyttige del af en dataplane-billet, uanset hvor beroligende de ser ud øverst i loggen.
Padding-meddelelsen er en udtalelse om padding
TFC-padding er den mest overlæste linje i disse logs. Den siger, at padding for trafikstrømsfortrolighed ikke vil blive accepteret for den child SA, hvilket er en udtalelse om en valgfri paddingfunktion snarere end en afvisning af ESP-beskyttelse. At finde den nær en fejl er som regel en tilfældighed af ordrigdom, og at slå padding til eller fra ændrer intet ved selektordækningen.
Den IKEv2-specifikation definerer både meddelelsen og selektorforhandlingen, og en implementerings advarselsetikette erstatter ikke protokolbetydningen i nogen af de to tilfælde.
Indsnævring er mere stille og mere sandsynligt vigtig
En responder kan acceptere en delmængde af de tilbudte selektorer, og det accepterede sæt kan være udskrevet over flere poster, én portkvalificeret og en anden, der dækker alle porte. At læse kun den første portkvalificerede linje undervurderer, hvad der blev accepteret; at læse kun den brede linje overvurderer det. Sammenlign det udskrevne forslag med den installerede politik, fordi forslaget er, hvad peer'erne sagde, og politikken er, hvad kernen vil matche. Når de er uenige, findes tunnelen, og trafikken gør ikke, hvilket er den klassiske periodiske klage. Vend det lokale og det fjernede perspektiv, når du sammenligner peers, fordi hver sides lokale er den andens fjernede.
Værtspecifikke poster med en portbegrænsning er værd at læse to gange, fordi det er dem, der udelukker ICMP eller en anden port, mens en ping til gatewayen bliver ved med at virke.
Byg én registrering for den fejlende strøm
Registrer kilde, destination, adressefamilie, protokol og port, som de ses ved beskyttelsesbeslutningen, inklusive enhver bevidst oversættelse. Det er de værdier, der skal matche en selektor, og det er også de værdier, folk skriver igen fra hukommelsen, når billetten når et tredje sæt hænder.
Identificér derefter child SA'en og dens retningsbestemte tællere: swanctl --list-sas giver associeringsoversigten på en strongSwan-vært, og ip -s xfrm state giver tællerne. Læs dem efter en frisk tilladt anmodning i stedet for mens systemet er inaktivt. Ingen stigning i udgående trafik peger på selektion eller den lokale vej; udgående uden tilsvarende indgående peger på peer'en, dens videresendelse eller dens svar.
En fuldført applikationsudveksling vejer tungere end nogen af tællerne, hvorfor testen bør slutte ved applikationen snarere end ved tunnelindikatoren.
Vælg rettelsen bagefter
Først når den registrering findes, er der en rettelse at vælge: accepterede selektorer, rute, filtrering, peer-implementering eller en grænse, du nu har demonstreret. At nulstille peer'en ændrer flere tilstande på én gang og gendanner ofte trafikken uden at forklare, hvilken der var forkert, så udfaldet vender tilbage. Hold kernetilstands-dumps ude af billetterne også, fordi de kan indeholde nøgler, og det korte resumé er nok for enhver, der skal hjælpe.
Når registreringen modsiger din første teori, tro på registreringen og skriv teorien om; den vane er mere værd end nogen enkelt loglinje, der diskuteres her.