Pachete IKE duplicate: găsiți tranziția lipsă
O cerere IKE repetată este un eveniment de temporizator, nu un diagnostic. Construiți un lanț de dovezi de la inițiator la răspuns, cu identificatorii de versiune corecți.
Jurnalul arată aceeași cerere IKE de două ori, cineva indică legătura mobilă și tichetul se închide cu o presupunere. Acea presupunere este mitul: un pachet repetat este o observație despre un singur schimb, nu un diagnostic al unei legături. Retransmisia este un comportament normal cu propriile reguli și apare pe căi sănătoase ori de câte ori un răspuns este lent. Urmați răspunsul înainte de a da vina pe o interfață.
Mitul: o cerere repetată dovedește pierdere pe o legătură
Două lucruri diferite produc un duplicat și niciunul nu numește un vinovat. Solicitantul poate repeta o cerere pentru că nu a primit răspuns, sau punctul de captură poate arăta același pachet de două ori din cauza locului unde este atașat la stivă. O sondă care vede intrarea și ieșirea pe același gazdă va înregistra bucuros un pachet ca două, iar operatorul care citește jurnalul nu are cum să facă diferența fără identificatorii schimbului. Tratați duplicatul ca un eveniment de temporizator până când puteți spune pe care dintre cele două îl țineți în mână.
Două legături mobile înrăutățesc confuzia în loc să o îmbunătățească. O singură linie de jurnal numește o interfață, în timp ce răspunsul poate fi plecat prin cealaltă, așa că interfața din mesaj descrie unde a fost văzut un pachet, nu forma conversației. De aceea prima întrebare este la ce schimb vă uitați, nu care legătură este defectă.
Ce vă spune de fapt retransmisia
În IKEv2, retransmisia funcționează astfel: solicitantul repetă o cerere când nu a sosit niciun răspuns, iar respondentul poate retrimite răspunsul memorat în loc să calculeze unul nou. Identificatorii mesajelor aparțin acelui schimb, și exact asta face ca o cerere repetată cu același identificator să fie recunoscută ca protocolul care lucrează, nu ca o încercare nouă. O încercare inițială are nevoie adesea de mai mult decât o adresă sursă sau un SPI de inițiator pentru a fi corelată, așa că înregistrarea de schimb a platformei bate o listă de pachete. IKEv1 urmează alte reguli cu alți identificatori, iar un avertisment al furnizorului despre un prim pachet duplicat nu înseamnă același lucru între versiuni.
Deci o marcă de timp a retransmisiei vă spune că un temporizator a expirat. Nu vă spune care salt a fost lent și cu siguranță nu vă spune că operatorul este vinovat. Sunt afirmații separate, și doar a doua este utilă într-un tichet.
Consecința practică este să înregistrați schimbul înainte de a trage o concluzie. Notați adresa locală de recepție, calea de răspuns aleasă de politică, tuplul perechii și identificatorii schimbului într-un singur loc, pentru că fiecare răspunde la o altă întrebare când înregistrarea este citită mai târziu.
Patru puncte de observație ca un singur lanț
Gândiți-vă la schimb ca la patru verigi ale unui lanț, nu ca la patru locuri separate de privit. O verigă ține dovezi sau rămâne necunoscută, iar lanțul este doar atât de informativ cât veriga sa cea mai slabă înregistrată. Tabelul de mai jos este inventarul: ce poate stabili fiecare poziție și ce lasă neatins.
| Poziție | Dovezi pe care le poate furniza | Ce lasă deschis |
|---|---|---|
| Inițiatorul trimite | O cerere a părăsit acest gazdă | Dacă a ajuns la pereche |
| Respondentul primește | Cererea a sosit | Dacă s-a produs un răspuns |
| Respondentul trimite | Un răspuns a părăsit poarta | Dacă a urmat calea dorită |
| Inițiatorul primește | Schimbul s-a încheiat | Dacă politica a acceptat rezultatul |
Completați lanțul doar acolo unde aveți acces și marcați restul ca necunoscut în loc să îl deduceți. Un cârlig care înregistrează pachete pe o singură mașină nu spune nimic despre ce a primit mașina îndepărtată, iar o linie de jurnal care notează că o cerere a fost văzută nu este dovada că a plecat vreodată un răspuns. Lacunele oneste sunt mai utile decât o înregistrare care pare completă și este construită din presupuneri.
Găsiți prima tranziție lipsă
Parcurgeți lanțul de la inițiator spre exterior și opriți-vă la prima verigă fără dovezi. Dacă poarta nu înregistrează niciodată cererea, defecțiunea se află pe calea dinaintea ei. Când poarta înregistrează aceeași cerere iar și iar, iar clientul nu înregistrează niciodată un răspuns, direcția de întoarcere este suspectă: adresa sursă, traducerea și filtrarea la fiecare graniță pe care o controlați. Dacă răspunsul sosește și clientul tot nu avansează, întrebarea a părăsit transportul și a devenit politică sau stare.
Țineți perechea și protocolul fixe în timp ce comparați și amintiți-vă că întârzierea, pierderea, politica și starea produc fiecare o altă cronologie. O rețea mobilă nu este automat cauza, iar o linie fixă nu este automat suficient de fiabilă pentru fiecare cerință. Capturați ambele direcții cât timp schimbul este viu:
tcpdump -ni any -vv 'udp port 500 or udp port 4500'
Când accesul se oprește înainte de capătul îndepărtat, înregistrarea ajută în continuare dacă spune unde se oprește. O captură doar pe inițiator poate arăta o cerere care pleacă și niciun răspuns care sosește, ceea ce restrânge defecțiunea la tot ce urmează după acel cârlig fără a pretinde că știm care salt a scăpat-o. Marcați verigile îndepărtate ca necunoscute și lăsați următoarea persoană cu acces să le completeze. Scris astfel, înregistrarea rămâne onestă și totuși scurtă.
Comparați înainte de a schimba ceva. Repetarea aceleiași cereri către aceeași pereche cu același protocol ține variabilele numărabile, în timp ce o resetare, o reînnoire de cheie sau o modificare de politică între capturi distruge comparația. Dacă schimbarea este inevitabilă, capturați din nou imediat după, astfel încât înainte și după să descrie încă același schimb.
Ce spune un raport util
Un raport care merită acțiune asociază o cerere cu răspunsul ei și numește primul pas în spatele căruia nu există dovezi. Acea propoziție supraviețuiește citirii o săptămână mai târziu de un inginer care nu a fost acolo și îi dă următoarei persoane un punct de plecare în loc de un suspect.
Nu slăbiți niciodată verificările de identitate și nu lărgiți setul de protocoale permis doar pentru a verifica o teorie de retransmisie. Salvați pachetele și înregistrările de evenimente originale înainte de orice resetare, pentru că o resetare distruge exact materialul pe care urma să îl colectați și șterge cronometrarea care arăta unde s-a blocat schimbul.
Mitul este că un duplicat dovedește vina operatorului. Realitatea este că un duplicat dovedește că un temporizator a expirat, iar răspunsul trăiește pe calea de răspuns.