VPN nutrūksta po DHCP atnaujinimo? Palyginkite adresus

Nuomos atnaujinimas ir VPN gedimas loguose taip dažnai pasirodo kartu, kad žmonės daro išvadą, jog vienas sukelia kitą. Laiko sutapimas tikras; priežastingumas paprastai ne. Atnaujinimas yra unicast užklausa serveriui, išdavusiam nuomą, prašanti tęsti tą patį susiejimą, ir serveris gali jį pratęsti klientui nepakeitus nė vieno adreso. Kliento pačių verčių apie įvykį peržiūra atskiria tyliai atnaujintą nuomą nuo tinklo, kuris iš tiesų pasikeitė po veikiančiu tuneliu.

Pradėkite nuo kliento, kuris nutrūko

Pirmiausia atidarykite kliento ryšio žurnalą ir užrašykite nutrūkimo laiką sekundės tikslumu. Tada atidarykite operacinės sistemos tinklo žurnalą tai pačiai minutei ir iš eilės perskaitykite, ką darė sąsaja. Ši tvarka yra visas tyrimas: DHCP įvykis prieš atsijungimą, atsijungimas prieš DHCP įvykį ir du įvykiai be nieko tarp jų yra trys skirtingi radiniai. Žurnalo eilutė, kuri tik mini nuomą, kai tunelis jau buvo jungiamasi iš naujo, yra dekoracija, o ne įrodymas.

Užrašinėkite laiko juostą eigoje, o ne laikykite jos atmintyje. Skirtingų įrankių laiko žymos retai sutampa visiškai, ir pats skirtumas kartais yra paaiškinimas.

Palyginkite keturias vertes apie įvykį

Keturios vertės pakankamai gerai apibūdina lokaliąją ryšio pusę, kad pagautų tikrą pokytį: sąsajos adresas, numatytasis šliuzas, sprendiklių sąrašas ir sąsajos veikimo būsena. Užfiksuokite jas per minutę po nutrūkimo ir palyginkite su fiksacija, padaryta tuneliui esant sveikam.

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

Nepakitęs adresas su nepakitusiu šliuzu ir pasikeitusiu sprendiklių sąrašu rodo vardų sprendimą, o ne maršrutizavimą, ir tunelis galėjo išgyventi, kol programos nustojo rasti mazgus. Pasikeitęs šliuzas reiškia, kad kelias iš vietinio tinklo pasistūmė, ir to pakanka maršrutui, kuris rodė į ankstesnį, panaikinti. Jei visos keturios vertės atitinka sveiką fiksaciją, nuoma nėra jūsų priežastis ir tema tampa paties kliento pakartotinio prisijungimo logika. Fiksuokite palyginimą, kol gedimas matomas, nes sveika fiksacija po perkrovimo turi kitą adresų istoriją ir nesutaps.

Ką atnaujinimas gali ir ko negali pakeisti

RFC 2131 apibūdina atnaujinimą kaip užklausą pradiniam serveriui per pusę nuomos laiko, su persiejimu su bet kuriuo serveriu ties septyniomis aštuntosiomis, jei pirmas bandymas lieka be atsakymo. Nė vienas žingsnis nereikalauja, kad klientas gautų kitą adresą, o bendradarbiaujantis serveris paprastai pratęsia esamą susiejimą. Tikras adreso pokytis paprastai ateina kitu keliu: serveris atsisako atnaujinti, klientas prarado būseną ir pradėjo iš naujo, arba tinklas perkėlė įrenginį į kitą segmentą.

Viešoji ryšio pusė gali pasikeisti be jokio vietinio pokyčio. Už operatoriaus lygio vertimo, adresas, kurį mato VPN partneris, gali būti perskiriamas nepriklausomai nuo to, ką darė vietinė nuoma, ir tas perskyrimas iš kliento vidaus atrodo identiškai kaip vietinis tinklo gedimas. Vietiškai pranešto adreso palyginimas su partnerio pusės stebėjimu yra vienintelis būdas juos atskirti.

Kai klientas nesugeba prisitaikyti

Klientas, susiejęs savo transportą su senu adresu, podėlyje laikęs pasenusį maršrutą į partnerį arba išsaugojęs sąsajos tapatybę, gali toliau bandyti kelią, kurio nebėra. Tai prisitaikymo defektas, ir jis matomas kaip kartotiniai persiuntimai į adresą, kurio mazgas nebegali pasiekti. Kai kurie klientai tai sprendžia konstrukciškai: pavyzdžiui, WireGuard atnaujina partnerio galinį tašką, kai iš naujo šaltinio atvyksta teisingai autentifikuotas paketas.

Rankinis perkrovimas, atstatantis paslaugą, yra užuomina, kur prisitaikymas nepavyko, o ne įrodymas, kad nuomos ir tuneliai nesuderinami. Testuodami palikite blokavimo politiką galioti, kitaip pats testas taps kliūtimi dėl kitos priežasties. Užrašykite, ar klientas atsistatė pats, kiek tai truko ir kokį adresą jis bandė dar kartą; ši seka pasako daugiau nei sąsajoje rodoma atsijungimo priežastis.

Pakartokite įvykį prieš kaltindami

Atkurkite sąlygą, o ne laukite grafiko: atleiskite ir atnaujinkite nuomą arba priverstinai sukurkite lygiavertį kontroliuojamą įvykį ir stebėkite, ar tunelis išgyvena. Valdomame tinkle bet kokį adreso pakeitimą derinkite su tinklo savininku, nes savavališkas statinis priskyrimas gali susidurti su įrenginiu, kuris jau turi tą adresą.

Po palaikomo taisymo pakartokite tą patį įvykį, tada išbandykite programą ir vardo užklausą, nes tunelis, kuris prisijungia iš naujo, bet sugadina DNS, praeina silpnesnį testą nei tas, kuris svarbus. Praneškite apie konkretų pastebėtą pokytį su jo laiko žyma, o ne įvardykite suplanuotą nuomą priežastimi. Skirtumas tarp šių dviejų ataskaitų yra tai, ar kitas žmogus gali atkurti gedimą, ar tik gandą.