IP-ul WAN s-a schimbat și tunelul a căzut: verificările în ordine

Tunelul cade, routerul înregistrează o reconectare și nimic din LAN nu s-a mișcat. O adresă WAN nouă invalidează conexiunea exterioară fără să schimbe nimic în interior: adresa sursă a clientului s-a schimbat, vechea stare NAT indică o sursă care nu mai există, iar peer-ul îndepărtat poate încă trimite la adresa anterioară. Recuperarea este un comportament normal, iar întrebarea utilă este care stare nu a fost actualizată.

Numiți evenimentul înainte de a citi jurnalul

Verificați ce s-a întâmplat de fapt la nivelul de acces. O reînnoire a lease-ului de la ISP este un eveniment. O sesiune PPPoE care s-a reconectat este altul. Un modem de fibră repornit, sau un failover WAN de pe un uplink pe altul, schimbă adresa exterioară sau calea ei într-un al treilea mod. Nu sunt același eveniment și nu lasă același reziduu.

O linie de reconectare în jurnalul VPN nu este nici ea dovada unei schimbări WAN. Un timeout de inactivitate, un interval de reautentificare și detectarea unui peer mort produc toate reconectări fără nicio schimbare de adresă. Comparați marcajele de timp din jurnalul de acces cu jurnalul VPN înainte de a trage vreo concluzie și păstrați fereastra de comparație destul de largă pentru a prinde o schimbare petrecută peste noapte.

Roamingul și reconectarea sunt protocoale diferite

WireGuard are roaming autentificat integrat în protocol: când un peer primește un pachet autentificat corect de la o adresă sursă nouă, actualizează punctul final al acelui peer. Ghidul rapid WireGuard descrie configurația peer-ului care face acest lucru posibil, motiv pentru care un client pe o adresă care se schimbă se recuperează adesea fără o repornire vizibilă.

OpenVPN se comportă diferit implicit. O sesiune UDP se poate încheia și reconecta, iar comportamentul float opțional permite unui peer autentificat să continue de la o adresă nouă acolo unde configurația permite. Tunelurile bazate pe TCP sunt mai stricte, deoarece conexiunea în sine este legată de perechea de adrese. Această diferență decide dacă recuperarea pare invizibilă sau se anunță în jurnal de fiecare dată.

Niciunul dintre comportamente nu spune nimic despre aplicațiile din interior. Un tunel recuperat nu restaurează o sesiune TCP pe care peer-ul o considera deja moartă.

Starea pe care tunelul nu o deține

Starea de traducere și de rutare supraviețuiește reconectării în moduri care surprind oamenii. O intrare conntrack creată pentru sursa veche ține calea de răspuns ancorată la o adresă care nu mai există și expiră după propriul program, nu când tunelul a revenit. Repornirea serviciului de tunel nu scurtează acea așteptare, așa că o legătură reparată poate încă părea stricată o vreme.

Rutele și regulile de politică pot face referire la gateway-ul sau interfața veche. Un set de reguli care era corect înainte de o schimbare WAN poate indica un dispozitiv care acum este oprit, ceea ce produce un tunel care raportează că este conectat și trafic care nu ajunge nicăieri. DNS-ul dinamic pentru un server pe care îl găzduiți este o problemă separată de cea a unui client care obține o sursă nouă. Înregistrarea trebuie actualizată pentru ca clienții la distanță să vă găsească, iar nicio configurație de pe partea clientului nu compensează o adresă pe care traducerea din amonte nu o va trimite mai departe.

Ordonați verificările dinspre exterior spre interior

Ordinea de mai jos merge de la conexiunea exterioară spre interior, iar oprirea la primul pas care eșuează este ceea ce o face utilă: fiecare verificare exclude stratul de deasupra. Păstrați această ordine chiar și când defectul pare evident.

wg show
ip -br addr show
ip route get 198.51.100.7
conntrack -L 2>/dev/null | grep -c ESTABLISHED
journalctl -u openvpn-client@home --since '-2 hours' | tail -n 40

Prima comandă arată punctul final actual și vârsta handshake-ului pentru fiecare peer. A doua și a treia arată dacă interfața exterioară și ruta către punctul final mai au sens. Numărul conntrack este o verificare grosieră a stării rămase de la adresa anterioară, iar jurnalul este locul unde este înregistrat motivul reconectării.

Apoi testați de la un client din LAN, nu de la router. Un ping trimis de routerul însuși folosește o cale diferită de traficul redirecționat, așa că un ping reușit de la router demonstrează că tunelul există și nimic despre accesibilitatea clientului.

Decideți comportamentul așteptat și scrieți-l

Reconectarea este comportamentul corect pentru majoritatea implementărilor, așa că scopul nu este să o împiedicați. Decideți în schimb ce ar trebui să se întâmple cu traficul în timpul întreruperii: să fie oprit, reținut sau mutat pe o altă cale. Acea decizie aparține firewall-ului și politicii de rutare, nu profilului VPN.

Înregistrați evenimentele de acces și orele reconectării împreună timp de o săptămână. Schimbările repetate fără un eveniment de acces corespunzător indică serviciul de acces, iar înlocuirea profilului VPN nu va repara un uplink care renegociază constant. O singură pereche de intrări în același minut lămurește întrebarea pentru acel incident și dă o linie de bază pentru următorul.