ESP descifrează corect și pachetul interior tot nu ajunge nicăieri
Contoarele ESP cresc în timp ce aplicația nu vede nimic. Următorul antet din trailer trebuie să corespundă pachetului interior, o defecțiune diferită de un selector ratat.
Contorul de recepție ESP crește, tunelul rămâne activ, iar aplicația nu vede niciodată pachetul. Descifrarea a rulat, verificarea integrității a trecut, apoi receptorul a trebuit să decidă ce este de fapt sarcina utilă protejată. Exact la acel ultim pas apare o nepotrivire de format, iar din exterior nu seamănă deloc cu o problemă de firewall.
Ce vezi când eticheta minte
Nimic din jurnalul clientului nu distinge asta de o gaură neagră de rutare. Ambele produc un timeout al aplicației lângă un tunel sănătos, de aceea contoarele sunt învinuite primele.
Un contor de recepție în creștere este într-adevăr o veste bună: pachetele sosesc și sunt autentificate. Nu este dovada că pachetul interior avea sens pentru ceva deasupra stratului criptografic.
Tipul locuiește în trailer
În modul tunel IPsec obișnuit, sarcina utilă protejată de ESP conține un pachet IP interior complet. Câmpul de antet următor din trailer identifică ce este această sarcină, iar el nu este un port TCP, nu este un număr de protocol din antetul exterior și nu face parte din câmpul inițial SPI și număr de secvență. RFC 4303 secțiunea 2.6 îl definește drept câmpul de tip al sarcinii, ceea ce este un nume precis pentru o sarcină precisă.
Valorile pe care le veți întâlni sunt mici și merită reținute: IPv4 este 4 (0x04), iar IPv6 este 41 (0x29).
Acele numere provin din alocările de numere de protocol ale IANA, nu din convenții locale. Un expeditor care declară IPv4 în timp ce împachetează un pachet IPv6 a produs o inconsistență de format, iar nicio regulă de firewall nu repară octeți care contrazic propria etichetă.
Cum îl deosebești de suspecții obișnuiți
Majoritatea pachetelor lipsă nu sunt defecte de codare. Verifică mai întâi selectoarele, pentru că un selector de trafic care exclude prefixul IPv6 aruncă traficul înainte ca ceva să fie încapsulat. Apoi verifică rutarea, apoi filtrarea locală pe gazda receptoare. Numai după ce acestea sunt excluse, o nepotrivire de format a sarcinii devine o explicație plauzibilă.
O captură criptată nu va lămuri lucrurile, pentru că antetul următor protejat se află în interiorul sarcinii criptate. Ai nevoie de diagnostice ale implementării sau de un punct de observare decriptat acceptat, iar ambele necesită autorizare înainte de utilizare.
Dacă nimeni nu poate produce acea dovadă, nu ai un defect de format. Ai o teorie, iar selectoarele rămân pariul mai bun.
Ce nu este reparația
Nu dezactiva verificările de integritate ca să treacă traficul. Nu rescrie pachete criptate pe un router intermediar, pentru că asta nu poate funcționa și va corupe fluxul în timp ce pare util într-o captură. Nu deschide o regulă de firewall de aplicație mai largă pe teoria că un port este blocat. Niciuna dintre ele nu atinge nepotrivirea de etichetă.
Dacă o nepotrivire confirmată vine de la o implementare parteneră, păstrează o reproducere minimă și curățată și du-o la canalul acceptat al acelei implementări.
Verifică fluxul, nu contorul
După corecție, testează fluxul IPv6 real de la un capăt la altul: o cerere a aplicației prin tunel, răspunsul ei și perechea de adrese pe care o observă fiecare parte. Un contor ESP în creștere dovedește doar că pachetele sunt primite și autentificate. Nu spune nimic despre dacă pachetul interior a fost utilizabil.
Notează ambele rezultate în tichet. Mișcarea contorului plus un flux funcțional înseamnă reparație; mișcarea contorului singură este exact ce aveai înainte să începi.