Răspunsurile DPD dovedesc că partenerul IKE este viu, nu că datele dumneavoastră curg
Răspunsuri de viață, o notificare de umplere și selectori îngustați descriu trei lucruri diferite. Citiți-le separat înainte de a da vina pe unul dintre ele pentru o oprire.
Jurnalele IPsec pot arăta răspunsuri de viață în timp ce aplicația din fața lor este blocată, iar ambele fapte pot fi adevărate în același timp. Un răspuns DPD stabilește că procesarea IKE a partenerului a răspuns în acel moment; nu spune nimic despre dacă SA copil transportă pachetul care vă interesează. Tratarea fiecărui avertisment de lângă o defecțiune ca fiind cauza sa este modul în care o problemă de selector ajunge diagnosticată ca eroare de protocol. Trei observații sunt confundate cel mai des și răspund la trei întrebări diferite. Citiți-le după asociere și scop înainte de a le citi după marcajul temporal.
Ce dovedește fiecare observație
Tabelul separă ceea ce stabilește fiecare observație de ceea ce doar o însoțește.
| 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 |
Niciuna dintre cele trei nu este o eroare în sine. Fiecare devine interesantă doar lângă fluxul pe care îl depanați, iar un rând care nu poate fi legat de un flux anume este context, nu dovadă.
Viața nu este sănătatea datelor
DPD rulează ca un schimb INFORMATIONAL, o conversație de plan de control între demonii IKE. Un răspuns dovedește că procesul IKE al partenerului este accesibil și dispus să răspundă, iar un timeout dovedește că nu este. Niciun rezultat nu testează SA copil, selectorii, calea de transmitere sau răspunsul aplicației, așa că un DPD sănătos lângă un transfer blocat este o imagine coerentă, nu o contradicție.
De aceea liniile de viață sunt partea cea mai puțin utilă a unui tichet de plan de date, oricât de liniștitoare par în partea de sus a jurnalului.
Notificarea de umplere este o afirmație despre umplere
Umplerea TFC este rândul cel mai supralecturat din aceste jurnale. Spune că umplerea pentru confidențialitatea fluxului de trafic nu va fi acceptată pentru acea SA copil, ceea ce este o afirmație despre o funcție opțională de umplere, nu o respingere a protecției ESP. Găsirea ei lângă o defecțiune este de obicei o coincidență a verbozității, iar pornirea sau oprirea umplerii nu schimbă nimic în acoperirea selectorilor.
Specificația IKEv2 definește atât notificarea, cât și negocierea selectorilor, iar eticheta de avertizare a unei implementări nu înlocuiește sensul protocolului în niciunul dintre cele două cazuri.
Îngustarea este mai silențioasă și mai probabil importantă
Un respondător poate accepta un subset al selectorilor oferiți, iar setul acceptat poate fi tipărit pe mai multe intrări, una calificată prin port și alta care acoperă toate porturile. Citirea doar a primei linii calificate prin port subestimează ce a fost acceptat; citirea doar a liniei largi îl supraestimează. Comparați propunerea tipărită cu politica instalată, pentru că propunerea este ce au spus partenerii, iar politica este ce va potrivi nucleul. Când nu coincid, tunelul există și traficul nu, ceea ce este reclamația intermitentă clasică. Inversați perspectiva locală și distantă când comparați partenerii, deoarece localul fiecărei părți este distantul celeilalte.
Intrările specifice gazdei cu restricție de port merită citite de două ori, pentru că ele sunt cele care exclud ICMP sau un al doilea port lăsând un ping către poartă să funcționeze.
Construiți o înregistrare pentru fluxul care eșuează
Înregistrați sursa, destinația, familia de adrese, protocolul și portul așa cum apar la decizia de protecție, inclusiv orice traducere deliberată. Acestea sunt valorile care trebuie să corespundă unui selector și sunt totodată valorile pe care oamenii le rescriu din memorie când tichetul ajunge la o a treia pereche de mâini.
Apoi identificați SA copil și contoarele sale direcționale: swanctl --list-sas oferă rezumatul asocierii pe o gazdă strongSwan, iar ip -s xfrm state oferă contoarele. Citiți-le după o cerere permisă recentă, nu în timp ce sistemul este inactiv. Nicio creștere a traficului de ieșire nu indică selecția sau calea locală; ieșirea fără o intrare corespunzătoare indică partenerul, transmiterea sa sau răspunsurile sale.
Un schimb de aplicație finalizat depășește oricare dintre contoare, de aceea testul ar trebui să se încheie la aplicație, nu la indicatorul tunelului.
Alegeți corecția după aceea
Numai când acea înregistrare există există o corecție de ales: selectori acceptați, rută, filtrare, implementarea partenerului sau o limită pe care tocmai ați demonstrat-o. Resetarea partenerului schimbă mai multe stări deodată și deseori readuce traficul fără a explica care era greșită, așa că defecțiunea revine. Țineți dump-urile de stare ale nucleului în afara tichetelor, pentru că pot conține chei, iar rezumatul îngust este suficient pentru oricine trebuie să ajute.
Când înregistrarea contrazice prima dumneavoastră teorie, credeți înregistrarea și rescrieți teoria; acel obicei valorează mai mult decât orice singură linie de jurnal discutată aici.