VPN-ul cade după o reînnoire DHCP? Comparați adresele

Reînnoirea bailului și eșecul VPN apar împreună în jurnale destul de des încât oamenii să concluzioneze că unul îl cauzează pe celălalt. Coincidența temporală este reală; cauzalitatea de obicei nu. O reînnoire este o cerere unicast către serverul care a emis bailul, de a continua să folosească aceeași legătură, iar serverul o poate prelungi fără ca clientul să schimbe o singură adresă. Examinarea valorilor proprii ale clientului în jurul evenimentului separă un bail reînnoit în liniște de o rețea care s-a schimbat cu adevărat sub un tunel în funcțiune.

Începeți cu clientul care a căzut

Deschideți mai întâi jurnalul de conexiuni al clientului și notați ora căderii până la secundă. Apoi deschideți jurnalul de rețea al sistemului de operare pentru același minut și citiți în ordine ce a făcut interfața. Această ordine este întreaga investigație: un eveniment DHCP înainte de deconectare, o deconectare înainte de evenimentul DHCP și două evenimente fără nimic între ele sunt trei constatări diferite. O linie de jurnal care doar menționează bailul în timp ce tunelul se reconecta deja este decor, nu dovadă.

Scrieți cronologia pe parcurs în loc să o țineți în memorie. Marcajele de timp din instrumente diferite coincid rar perfect, iar diferența în sine este uneori explicația.

Comparați cele patru valori din jurul evenimentului

Patru valori descriu partea locală a unei conexiuni suficient de bine pentru a prinde o schimbare reală: adresa interfeței, gateway-ul implicit, lista de resolvere și starea operațională a interfeței. Capturați-le în minutul următor căderii și comparați cu o captură făcută când tunelul era sănătos.

ip -4 -brief addr show dev wlan0
ip -4 route show default
resolvectl status | grep -A3 'DNS Servers'
journalctl -u NetworkManager --since -10m --no-pager | grep -i dhcp

O adresă neschimbată cu un gateway neschimbat și o listă de resolvere schimbată indică rezolvarea numelor, nu rutarea, iar tunelul poate a supraviețuit în timp ce aplicațiile au încetat să mai găsească gazde. Un gateway schimbat înseamnă că drumul din rețeaua locală s-a mutat, ceea ce este suficient pentru a invalida o rută care indica spre cel anterior. Dacă toate cele patru valori corespund capturii sănătoase, bailul nu este cauza dumneavoastră și logica de reconectare a clientului devine subiectul. Capturați comparația cât timp defectul este vizibil, pentru că o captură sănătoasă făcută după o repornire are un istoric de adrese diferit și nu va corespunde.

Ce poate și ce nu poate schimba o reînnoire

RFC 2131 descrie reînnoirea ca o cerere către serverul original la jumătatea duratei bailului, cu religare la orice server la șapte optimi dacă prima încercare rămâne fără răspuns. Niciunul dintre pași nu cere clientului să obțină o altă adresă, iar un server cooperant prelungește de obicei legătura existentă. O schimbare reală de adresă vine de obicei pe alt drum: un server refuză reînnoirea, un client și-a pierdut starea și a luat-o de la capăt, sau o rețea a mutat dispozitivul într-un alt segment.

Partea publică a conexiunii se poate schimba fără nicio modificare locală. În spatele unei traduceri de nivel operator, adresa văzută de partenerul VPN poate fi realocată independent de orice a făcut bailul local, iar acea realocare arată identic cu o defecțiune de rețea locală din interiorul clientului. Compararea unei adrese raportate local cu o observație din partea partenerului este singura cale de a le separa.

Când clientul nu reușește să se adapteze

Un client care și-a legat transportul de adresa veche, a stocat în cache o rută învechită către partener sau a salvat o identitate de interfață poate continua să încerce o cale care nu mai există. Acesta este un defect de adaptare, vizibil ca retransmisii repetate către o adresă la care gazda nu mai poate ajunge. Unii clienți o rezolvă prin proiectare: WireGuard, de exemplu, actualizează punctul final al unui partener când un pachet autentificat corect sosește dintr-o sursă nouă.

O repornire manuală care restaurează serviciul este un indiciu despre unde a eșuat adaptarea, nu o dovadă că bailurile și tunelurile sunt incompatibile. Păstrați politica de blocare în timpul testării, altfel testul însuși devine o întrerupere cu altă cauză. Notați dacă clientul s-a recuperat singur, cât a durat și ce adresă a reîncercat; acea secvență vă spune mai mult decât motivul deconectării afișat în interfață.

Repetați evenimentul înainte de a-l învinui

Reproduceți condiția în loc să așteptați programul: eliberați și reînnoiți bailul sau forțați evenimentul controlat echivalent și urmăriți dacă tunelul supraviețuiește. Într-o rețea administrată, coordonați orice schimbare de adresă cu proprietarul rețelei, pentru că o atribuire statică arbitrară poate intra în conflict cu un dispozitiv care deține deja acea adresă.

După o corecție acceptată, repetați același eveniment și apoi testați o aplicație și o interogare de nume, pentru că un tunel care se reconectează dar rupe DNS trece un test mai slab decât cel care contează. Raportați schimbarea specifică pe care ați observat-o, cu marcajul ei de timp, în loc să numiți bailul programat drept cauză. Diferența dintre cele două rapoarte este dacă următoarea persoană poate reproduce defectul sau doar zvonul.