WAN-i IP muutus ja tunnel katkes: kontrollid järjekorras

Tunnel katkeb, ruuter logib taasühenduse ja LAN-is ei ole miski liikunud. Uus WAN-i aadress muudab välisühenduse kehtetuks, muutmata midagi sees: kliendi lähteaadress on muutunud, vana NAT-i olek osutab allikale, mida enam ei ole, ja kaugem peer võib endiselt saata eelmisele aadressile. Taastumine on tavaline käitumine ja kasulik küsimus on, milline olek jäi uuendamata.

Nimetage sündmus enne logi lugemist

Kontrollige, mis juhtus tegelikult juurdepääsukihis. ISP liisingu uuendamine on üks sündmus. Taasühendatud PPPoE sessioon on teine. Taaskäivitatud fiibermodem või WAN-i ümberlülitus ühelt ühenduselt teisele muudab välisaadressi või selle teed kolmandal viisil. Need ei ole sama sündmus ja need ei jäta sama jääki.

Taasühenduse rida VPN-i logis ei ole samuti WAN-i muutuse tõestus. Tühikäigu ajalõpp, uuesti autentimise intervall ja surnud peeri tuvastus tekitavad kõik taasühendusi ilma igasuguse aadressimuutuseta. Enne järelduste tegemist võrrelge juurdepääsulogi ajatempleid VPN-i logiga ja hoidke võrdlusaken piisavalt lai, et tabada öösel toimunud muutust.

Rändlus ja taasühendamine on erinevad protokollid

WireGuardil on autenditud rändlus protokolli sisse ehitatud: kui peer saab uuelt lähteaadressilt õigesti autenditud paketi, uuendab see selle peeri lõpp-punkti. WireGuardi kiirstart kirjeldab peeri konfiguratsiooni, mis selle võimalikuks teeb, mistõttu muutuval aadressil olev klient taastub sageli ilma nähtava taaskäivituseta.

OpenVPN käitub vaikimisi teisiti. UDP sessioon võib lõppeda ja uuesti ühenduda ning valikuline float-käitumine lubab autenditud peeril jätkata uuelt aadressilt seal, kus konfiguratsioon seda lubab. TCP-põhised tunnelid on rangemad, sest ühendus ise on seotud aadressipaariga. See erinevus otsustab, kas taastumine näib nähtamatu või teatab end logis iga kord.

Kumbki käitumine ei ütle midagi sees olevate rakenduste kohta. Taastatud tunnel ei taasta TCP sessiooni, mida peer pidas juba surnuks.

Olek, mida tunnel ei oma

Tõlke- ja marsruutimisolek elab taasühenduse üle viisil, mis inimesi üllatab. Vana allika jaoks loodud conntrack-kirje hoiab vastusetee kinnitatuna aadressile, mida enam ei ole, ja see aegub oma ajakava järgi, mitte siis, kui tunnel tagasi tuli. Tunneliteenuse taaskäivitamine ei lühenda seda ootust, nii et parandatud link võib mõnda aega ikka katki näida.

Marsruudid ja poliitikareeglid võivad viidata vanale lüüsile või liidesele. Reeglistik, mis oli enne WAN-i lülitust õige, võib osutada seadmele, mis on nüüd maas, mis tekitab tunneli, mis teatab end ühendatuna, ja liikluse, mis ei lähe kuhugi. Dünaamiline DNS serverile, mida majutate, on eraldi probleem kliendist, kes saab uue allika. Kirje tuleb uuendada, et kaugkliendid teid leiaksid, ja ükski kliendipoolne konfiguratsioon ei korva aadressi, mida ülalvoolu tõlge edasi ei saada.

Järjestage kontrollid väljast sissepoole

Allpool olev järjekord liigub välisühendusest sissepoole, ja just esimesel ebaõnnestunud sammul peatamine teeb selle kasulikuks: iga läbivaatus välistab selle kohal oleva kihi. Pidage sellest järjekorrast kinni ka siis, kui rike tundub ilmne.

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

Esimene käsk näitab iga peeri praegust lõpp-punkti ja käepigistuse vanust. Teine ja kolmas näitavad, kas välimine liides ja marsruut lõpp-punktini on endiselt mõistlikud. conntrack-i arv on jäme kontroll eelmisest aadressist järele jäänud oleku kohta ja logi on koht, kuhu taasühenduse põhjus kirjutatakse.

Seejärel testige LAN-i kliendist, mitte ruuterist. Ruuteri enda saadetud ping kasutab edasisaadetud liiklusest erinevat teed, seega õnnestunud ruuteri ping tõestab, et tunnel on olemas, ja ei midagi kliendi kättesaadavuse kohta.

Otsustage oodatav käitumine ja kirjutage see üles

Taasühendamine on enamiku juurutuste jaoks õige käitumine, seega eesmärk ei ole seda takistada. Otsustage selle asemel, mis peaks liiklusega lünga ajal juhtuma: see peatada, kinni hoida või teisele teele üle lülitada. See otsus kuulub tulemüüri ja marsruutimispoliitika juurde, mitte VPN-profiili.

Kirjutage juurdepääsusündmused ja taasühenduse ajad nädal aega koos üles. Korduvad muutused ilma vastava juurdepääsusündmuseta osutavad juurdepääsuteenusele, ja VPN-profiili vahetamine ei paranda ühendust, mis pidevalt uuesti läbirääkimisi peab. Üks paar kirjeid samas minutis lahendab küsimuse selle juhtumi jaoks ja annab järgmisele baasjoone.