DPD-svar bevisar att IKE-partnern lever, inte att dina data flödar
Livsteckenssvar, en padding-avisering och insnävgade selektorer beskriver tre olika saker. Läs dem var för sig innan du skyller en av dem för ett stopp.
IPsec-loggar kan visa livsteckenssvar medan applikationen framför dem står stilla, och båda fakta kan vara sanna samtidigt. Ett DPD-svar fastställer att partnerns IKE-bearbetning svarade i det ögonblicket; det säger ingenting om huruvida barn-SA:n bär det paket du bryr dig om. Att behandla varje varning nära ett avbrott som dess orsak är hur ett selektorproblem diagnostiseras som ett protokollfel. Tre observationer förväxlas oftast, och de svarar på tre olika frågor. Läs dem efter samband och syfte innan du läser dem efter tidsstämpel.
Vad varje observation bevisar
Tabellen skiljer vad varje observation fastställer från vad den bara åtföljer.
| 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 är ett fel i sig. Var och en blir intressant först bredvid det flöde du felsöker, och en rad som inte kan knytas till ett visst flöde är kontext, inte bevis.
Livstecken är inte datahälsa
DPD körs som ett INFORMATIONAL-utbyte, ett kontrollplanssamtal mellan IKE-demoner. Ett svar bevisar att partnerns IKE-process är nåbar och villig att svara, och en timeout bevisar att den inte är det. Ingen av resultaten prövar barn-SA:n, selektorerna, vidarebefordringsvägen eller applikationens svar, så en frisk DPD bredvid en fastlåst överföring är en sammanhängande bild snarare än en motsägelse.
Därför är livsteckensraderna den minst användbara delen av en dataplansbiljett, hur lugnande de än ser ut högst upp i loggen.
Padding-aviseringen är ett uttalande om padding
TFC-padding är den mest överlästa raden i dessa loggar. Den säger att padding för trafikflödeskonfidentialitet inte kommer att accepteras för den barn-SA:n, vilket är ett uttalande om en valfri paddingfunktion snarare än en avvisning av ESP-skydd. Att hitta den nära ett fel är vanligen en tillfällighet av ordrikedom, och att slå på eller av padding ändrar ingenting i selektortäckningen.
Den IKEv2-specifikationen definierar både aviseringen och selektorförhandlingen, och en implementerings varningsetikett ersätter inte protokollbetydelsen i något av de två fallen.
Inskränkningen är tystare och mer sannolikt viktig
En svarande kan acceptera en delmängd av de erbjudna selektorerna, och den accepterade mängden kan skrivas ut över flera poster, en portkvalificerad och en annan som täcker alla portar. Att bara läsa den första portkvalificerade raden underskattar vad som accepterades; att bara läsa den breda raden överskattar det. Jämför det utskrivna förslaget med den installerade policyn, eftersom förslaget är vad parterna sade och policyn är vad kärnan kommer att matcha. När de inte stämmer överens finns tunneln och trafiken inte, vilket är det klassiska periodiska klagomålet. Vänd på det lokala och det avlägsna perspektivet när du jämför parter, eftersom varje sidas lokala är den andras avlägsna.
Värdsspecifika poster med en portbegränsning är värda att läsa två gånger, eftersom det är de som utesluter ICMP eller en andra port medan en ping till gatewayen fortsätter att fungera.
Bygg en registrering för flödet som misslyckas
Registrera källa, mål, adressfamilj, protokoll och port så som de ses vid skyddsbeslutet, inklusive varje avsiktlig översättning. Det är de värden som måste matcha en selektor, och det är också de värden som människor skriver in igen från minnet när biljetten når ett tredje par händer.
Identifiera sedan barn-SA:n och dess riktningsberoende räknare: swanctl --list-sas ger associationsöversikten på en strongSwan-värd, och ip -s xfrm state ger räknarna. Läs dem efter en färsk tillåten begäran i stället för medan systemet är inaktivt. Ingen ökning av utgående trafik pekar på valet eller den lokala vägen; utgående utan motsvarande inkommande pekar på partnern, dess vidarebefordran eller dess svar.
Ett slutfört applikationsutbyte väger tyngre än någon av räknarna, vilket är varför testet bör sluta vid applikationen snarare än vid tunnelindikatorn.
Välj korrigeringen efteråt
Först när den registreringen finns finns det en korrigering att välja: accepterade selektorer, rutt, filtrering, partnerns implementering eller en gräns du nu har demonstrerat. Att återställa partnern ändrar flera tillstånd på en gång och återställer ofta trafiken utan att förklara vilket som var fel, så avbrottet återkommer. Håll kärntillståndsdumpar utanför biljetterna också, eftersom de kan innehålla nycklar och den snäva sammanfattningen räcker för alla som behöver hjälpa till.
När registreringen motsäger din första teori, tro på registreringen och skriv om teorin; den vanan är värd mer än någon enskild loggrada som diskuteras här.