Care hop NAT pierde maparea VPN inactivă și cum se observă
Un flux VPN inactiv poate muri la orice hop care ține stare. Repetați un test, comparați ce a văzut fiecare graniță și raportați rezultatul limitat în locul unui vinovat presupus.
După o perioadă liniștită tunelul se reconectează, niciun jurnal nu numește un vinovat, iar mișcarea evidentă este să alegeți dispozitivul cu cea mai impresionantă documentație a timpului limită. Aceasta este o presupunere îmbrăcată în diagnostic. Starea poate supraviețui o vreme într-un router de acasă, într-un traducător al operatorului și la marginea unui cloud, și oricare dintre ele poate scăpa un flux care devine tăcut. Ce puteți face în schimb este să cartografiați traseul, să marcați ce dispozitive puteți observa cu adevărat și să rulați un test de inactivitate care poate fi repetat.
Un test repetabil transformă o anecdotă într-o măsurătoare. Tot ce urmează presupune un client, un server și un protocol și presupune că rezistați tentației de a schimba două variabile deodată. Scopul este ca următoarea apariție să fie mai ieftină decât aceasta.
Rulați același test de inactivitate de fiecare dată
Notați când a fost fluxul ultima dată în regulă, cât timp a stat inactiv după aceea și dacă un singur pachet proaspăt l-a readus. Aceste trei fapte sunt măsurătoarea; fără ele aveți doar o poveste despre un laptop care a căzut. Folosiți același client, același server și același protocol la fiecare repetare și notați momentul în care a fost trimis primul pachet după tăcere.
Apoi comparați ce a văzut cu adevărat fiecare graniță pe care o dețineți. Distincția care decide investigația este dacă serverul nu a văzut nimic după pauză sau a văzut cererea și a răspuns într-o cale care nu mai ducea răspunsurile.
| What you observe | What it suggests | What it does not prove |
|---|---|---|
| server records no packet after the pause | state was lost upstream of the server | which hop dropped it |
| server answers, client never receives | return-path state or filtering | that the timer belongs to the client |
| client sends nothing at all | client-side timer or application behaviour | that the network path is healthy |
Compararea traseelor fără a schimba cinci lucruri
O a doua rețea de acces aprobată este o comparație legitimă, pentru că lanțul NAT diferă. Diferă și prin furnizor, condiții radio și poate familia de adrese, așa că rezultatul este o graniță, nu o atribuire. Înregistrați limitările împreună cu rezultatul în loc să le abandonați în tăcere când raportați. Notați și traseul: dispozitiv, rol și dacă starea lui poate fi citită deloc.
Ce cumpără o comparație de trasee este o întrebare limitată: fluxul supraviețuiește pe unul și moare pe celălalt după o tăcere similară, deci variabila se află undeva în părțile care diferă. Este un rezultat real chiar și când niciun dispozitiv nu este numit, și îi spune următorului inginer unde să petreacă o după-amiază și unde nu.
Merită citită starea locală înainte de a specula despre operatori. Pe o poartă Linux, conntrack -L listează fluxurile urmărite cu durata de viață rămasă, ceea ce transformă o presupunere despre un timer într-un număr pe care îl puteți vedea expirând. Citiți-l înainte și după perioada de inactivitate, nu doar după.
Ce va ține un semnal de menținere și ce nu
Un semnal de menținere acceptat ține o mapare deschisă, iar ținerea unei mapări deschise nu dovedește nimic despre serviciul din spate. Tunelul poate rămâne mapat în timp ce aplicația pe care o transportă a încetat să răspundă, iar dintr-un bec de stare aceste două situații arată la fel. Tratați semnalul de menținere ca o asigurare împotriva expirării din inactivitate, nu ca o verificare de sănătate.
Setați intervalul după cel mai scurt timp limită pe care l-ați măsurat efectiv, nu după un număr copiat de pe un forum. Un semnal de menținere reglat sub orice timer plauzibil este trafic de care nimeni nu avea nevoie și elimină și simptomul care v-ar fi spus care graniță expiră prima. Alegeți intervalul din numărul măsurat și lăsați tot restul în pace.
O singură schimbare, apoi măsurați din nou
Rezistați impulsului de a ridica toate timpurile limită și de a goli toate porțile în timpul unui test live. Aceasta șterge dovezile pentru care ați venit și întrerupe fluxuri ale altor persoane, ceea ce este un schimb prost pentru o ipoteză netestată. Schimbați o singură setare acceptată pe un singur dispozitiv, apoi repetați perioada de inactivitate și recuperarea aplicației.
Notați care observație de graniță s-a mișcat și notați-o chiar și când nimic nu s-a îmbunătățit. O setare care nu a reparat nimic este informație, și e mai ieftin să o observi o dată decât să o rostogolești prin tot parcul.
Scrierea unei constatări pe care o puteți apăra
Când un traducător din amonte nu poate fi inspectat, spuneți doar ce susțin dovezile: schimbul moare undeva de-a lungul acestui segment al traseului după atâta tăcere, iar hopul responsabil rămâne neatribuit. O afirmație limitată supraviețuiește revizuirii și îndrumă următoarea persoană către segmentul corect. Numirea unui router ascuns drept cauză nu face nici una, nici alta. Predați constatarea limitată celui care deține segmentul neobservabil, cu intervalul anexat.
RFC 4787 descrie de ce timerele de mapare UDP sunt greu de dedus dintr-un singur capăt, și tocmai această dificultate face constatarea limitată cinstită. Timerele sunt reale, și incertitudinea din jurul lor la fel.