IP-ul public s-a schimbat și VPN-ul a încetat să mai treacă trafic

O reconectare la furnizor sau o modificare în traducerea din amonte schimbă sursa publică a unei sesiuni VPN, în timp ce adresa privată locală a clientului rămâne de obicei exact așa cum era. Tunelul pare atunci conectat, deși nimic util nu trece prin el. Ambele observații sunt adevărate simultan, și exact asta face raportul confuz.

Parcurgeți cele patru verificări în ordine și opriți-vă la prima care eșuează.

Ce adresă s-a schimbat de fapt

Comparați starea interfeței locale cu sursa pe care o vede un punct final îndepărtat, într-un punct în care aveți autorizare să priviți. O adresă publică nouă nu implică o poartă locală nouă, iar o schimbare a interfeței locale nu garantează nici ea că sursa publică s-a mutat. Traducerea dintre ele înseamnă că sunt două fapte independente. Notați calea exactă și momentul în care ați observat-o, pentru că o etichetă de geolocalizare copiată dintr-un raport vechi răspunde la altă întrebare.

Întrebați specific dacă s-a schimbat sursa exterioară, adresa interioară a tunelului sau ambele. Doar prima explică un partener care continuă să trimită pe o cale ce nu mai există.

Lăsați protocolul să gestioneze mutarea

Protocoalele diferă în felul în care află că un partener s-a mutat, iar diferența contează pentru întrebarea dacă ar trebui să interveniți deloc. WireGuard actualizează punctul final al unui partener când primește un pachet autentificat cu cheia acelui partener, motiv pentru care o schimbare de adresă poate fi absorbită fără nicio configurație. IKEv2 are MOBIKE în același scop acolo unde ambele capete îl acceptă. Proiectele mai vechi se refac reconstruind tunelul.

Ce nu ar trebui să faceți este să acceptați un mesaj neautentificat drept dovadă că identitatea unui partener s-a mutat. Falsificarea unui datagram care pretinde o adresă nouă este trivială, iar un client care crede că poate fi direcționat către punctul final al atacatorului. Protocolul autentificat este mecanismul; o notificare nu este.

wg show wg0 endpoints
wg show wg0 latest-handshakes
conntrack -L -p udp --dport 51820 | head -n 10

Ștergeți legătura exterioară învechită

Când protocolul acceptă roaming și traficul tot eșuează, obstacolul este adesea echipament care păstrează stare pe traseu sau o politică la capătul îndepărtat. Un firewall care urmărea fluxul vechi poate păstra intrarea învechită, iar o regulă de acces pe partea de server legată de sursa veche o va elimina pe cea nouă în tăcere. Curățarea mapării și reverificarea regulii sunt mai rapide decât înlocuirea acreditărilor.

Păstrați blocarea necesară cât timp investigați. Deschiderea largă a politicii pentru a testa dacă tunelul se reface nu vă învață nimic despre cauză și lasă implementarea mai rea decât ați găsit-o.

Testați din nou cu o cerere nouă

O sesiune de aplicație stabilită înainte de schimbare nu o supraviețuiește, pentru că cvadruplul pe care se baza nu mai există. Generați o cerere nouă după recuperare și confirmați că se finalizează, în loc să priviți o descărcare veche blocată la zero și să concluzionați că tunelul este încă stricat. Exact această distincție rezolvă o mare parte din aceste rapoarte.

Apoi notați ambele jumătăți ale diagnosticului: ce s-a schimbat în amonte și care pas de recuperare acceptat a readus fluxul. Următoarea apariție va fi mai rapidă, iar nota este ceea ce o face mai rapidă.

Dacă o cerere nouă reușește, iar cea veche nu se reia niciodată, tunelul a fost reparat și aplicația trebuie doar să se reconecteze.