Kas VPN kukub pärast DHCP uuendust? Võrrelge aadresse

Rendilepingu uuendus ja VPN-i tõrge esinevad logides koos piisavalt sageli, et inimesed järeldavad, nagu põhjustaks üks teist. Ajaline kokkusattumus on tõeline; põhjuslikkus tavaliselt mitte. Uuendus on üksiksaadetav päring serverile, kes rendilepingu väljastas, paludes jätkata sama sidumise kasutamist, ja server saab seda pikendada, ilma et klient muudaks ühtegi aadressi. Kliendi enda väärtuste läbivaatamine sündmuse ümber eristab vaikselt uuendatud rendilepingut võrgust, mis töötava tunneli all tõesti muutus.

Alustage kliendist, mis kukkus

Avage kõigepealt kliendi ühenduslogi ja kirjutage katkestuse aeg sekundi täpsusega üles. Seejärel avage operatsioonisüsteemi võrgulogi sama minuti kohta ja lugege järjekorras, mida liides tegi. See järjekord on kogu uurimine: DHCP sündmus enne lahtiühendust, lahtiühendus enne DHCP sündmust ja kaks sündmust, mille vahel pole midagi, on kolm erinevat leidu. Logirida, mis ainult mainib rendilepingut, kui tunnel juba uuesti ühendus, on dekoratsioon, mitte tõestus.

Kirjutage ajajoon jooksvalt üles, selle asemel et seda mälus hoida. Erinevate tööriistade ajatemplid langevad harva täpselt kokku ja nihke ise on mõnikord seletus.

Võrrelge sündmuse ümber nelja väärtust

Neli väärtust kirjeldavad ühenduse kohalikku poolt piisavalt hästi, et tabada tõelist muutust: liidese aadress, vaikelüüs, resolverite loend ja liidese tööolek. Fikseerige need minuti jooksul pärast katkestust ja võrrelge salvestusega, mis tehti tunnel tervena.

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

Muutumatu aadress muutumatu lüüsiga ja muutunud resolverite loendiga viitab nime lahendamisele, mitte marsruutimisele, ja tunnel võis ellu jääda, samal ajal kui rakendused lõpetasid hostide leidmise. Muutunud lüüs tähendab, et tee kohalikust võrgust välja liikus, millest piisab, et muuta kehtetuks marsruut, mis osutas eelmisele. Kui kõik neli väärtust ühtivad terve salvestusega, ei ole rendileping teie põhjus ja teemaks saab kliendi enda taasühendumisloogika. Tehke võrdlus siis, kui rike on nähtav, sest pärast taaskäivitust tehtud tervel salvestusel on teistsugune aadressiajalugu ja see ei ühti.

Mida uuendus saab ja mida ei saa muuta

RFC 2131 kirjeldab uuendust päringuna algsele serverile poolel rendiajal, uuestisidumisega ükskõik millisele serverile seitsmel kaheksandikul, kui esimene katse jääb vastuseta. Kumbki samm ei nõua, et klient hangiks teistsuguse aadressi, ja koostööaldis server pikendab tavaliselt olemasolevat sidumist. Tõeline aadressimuutus tuleb tavaliselt teist teed: server keeldub uuendusest, klient kaotas oma oleku ja alustas uuesti, või võrk viis seadme teise segmenti.

Ühenduse avalik pool võib muutuda ilma igasuguse kohaliku muutuseta. Operaatoritasandi tõlke taga võib VPN-i partneri nähtav aadress olla ümber määratud sõltumata sellest, mida kohalik rendileping tegi, ja see ümbermääramine näeb kliendi seest välja täpselt nagu kohalik võrgutõrge. Kohapeal teatatud aadressi võrdlemine partneri poolel tehtud vaatlusega on ainus viis neid eristada.

Kui klient ei suuda kohaneda

Klient, kes sidus oma transportkihi vana aadressiga, vahemällu salvestas partneri aegunud marsruudi või hoidis liidese identiteeti, võib jätkata tee proovimist, mida enam ei ole. See on kohanemisviga ja see avaldub korduvate ülekannetena aadressile, mida host enam kätte ei saa. Mõned kliendid käsitlevad seda konstruktsiooni järgi: näiteks WireGuard uuendab partneri lõpp-punkti, kui uuelt allikalt saabub korrektselt autenditud pakett.

Käsitsi taaskäivitamine, mis teenuse taastab, on vihje selle kohta, kus kohanemine ebaõnnestus, mitte tõestus, et rendilepingud ja tunnelid ei sobi kokku. Hoidke blokeerimispoliitika testimise ajal jõus, muidu muutub test ise teistsuguse põhjusega katkestuseks. Kirjutage üles, kas klient taastus ise, kui kaua see võttis ja millist aadressi see uuesti proovis; see jada ütleb teile rohkem kui liideses näidatud lahtiühenduse põhjus.

Korrake sündmust enne süüdistamist

Taasesitage tingimus, selle asemel et oodata graafikut: vabastage ja uuendage rendileping või sundige esile samaväärne kontrollitud sündmus, ja jälgige, kas tunnel jääb püsima. Hallatavas võrgus kooskõlastage igasugune aadressimuutus võrgu omanikuga, sest meelevaldne staatiline määramine võib kokku põrgata seadmega, millel see aadress juba on.

Pärast toetatud parandust korrake sama sündmust ja seejärel testige rakendust ja nimepäringut, sest tunnel, mis ühendub uuesti, kuid rikub DNS-i, läbib nõrgema testi kui see, millel on tähtsust. Teatage konkreetsest muutusest, mida täheldasite, koos selle ajatempliga, selle asemel et nimetada plaanitud rendilepingut põhjuseks. Nende kahe aruande vahe on see, kas järgmine inimene suudab riket taasesitada või ainult kuulujuttu.