WAN-IP er endret og tunnelen falt: kontrollene i rekkefølge

Tunnelen faller, ruteren logger en gjenoppkobling, og ingenting på LAN-et har flyttet seg. En ny WAN-adresse ugyldiggjør den ytre forbindelsen uten å endre noe inni: kildeadressen til klienten er endret, den gamle NAT-tilstanden peker på en kilde som ikke lenger finnes, og den eksterne peeren sender kanskje fortsatt til den forrige adressen. Gjenoppretting er normal oppførsel, og det nyttige spørsmålet er hvilken tilstand som ikke ble oppdatert.

Navngi hendelsen før du leser loggen

Undersøk hva som faktisk skjedde på aksesslaget. En fornyelse av ISP-leasingen er én hendelse. En PPPoE-økt som ble gjenoppkoblet er en annen. Et fibermodem som ble startet på nytt, eller en WAN-failover fra én uplink til en annen, endrer den ytre adressen eller veien dens på en tredje måte. De er ikke samme hendelse, og de etterlater ikke samme rest.

En gjenoppkoblingslinje i VPN-loggen er heller ikke bevis på en WAN-endring. En inaktivitetstimeout, et intervall for reautentisering og påvisning av død peer gir alle gjenoppkoblinger uten noen adresseendring. Sammenlign tidsstempler fra aksessloggen med VPN-loggen før du konkluderer noe, og hold sammenligningsvinduet bredt nok til å fange en endring som skjedde om natten.

Roaming og gjenoppkobling er forskjellige protokoller

WireGuard har autentisert roaming innebygd i protokollen: når en peer mottar en korrekt autentisert pakke fra en ny kildeadresse, oppdaterer den endepunktet til den peeren. WireGuards hurtigstart beskriver peer-konfigurasjonen som gjør dette mulig, og derfor kommer en klient på en skiftende adresse ofte tilbake uten en synlig omstart.

OpenVPN oppfører seg annerledes som standard. En UDP-økt kan avsluttes og kobles til på nytt, og den valgfrie float-atferden lar en autentisert peer fortsette fra en ny adresse der konfigurasjonen tillater det. TCP-baserte tunneler er strengere, fordi selve forbindelsen er bundet til adresseparet. Den forskjellen avgjør om gjenopprettingen ser usynlig ut, eller om den melder seg i loggen hver gang.

Ingen av atferdene sier noe om applikasjonene inni. En gjenopprettet tunnel gjenoppretter ikke en TCP-økt som peeren allerede anså som død.

Tilstand som tunnelen ikke eier

Oversettelses- og rutertilstand overlever gjenoppkoblingen på måter som overrasker folk. En conntrack-oppføring opprettet for den gamle kilden holder svarveien forankret til en adresse som ikke lenger finnes, og den utløper etter sin egen tidsplan, ikke når tunnelen kom tilbake. Omstart av tunnel-tjenesten forkorter ikke den ventetiden, så en reparert lenke kan fortsatt se brutt ut en stund.

Ruter og policyregler kan referere til den gamle gatewayen eller grensesnittet. Et regelsett som var riktig før et WAN-bytte, kan peke på en enhet som nå er nede, noe som gir en tunnel som rapporterer som tilkoblet, og trafikk som ikke kommer noen vei. Dynamisk DNS for en server du hoster, er et separat problem fra en klient som får en ny kilde. Oppføringen må oppdateres for at eksterne klienter skal finne deg, og ingen konfigurasjon på klientsiden kompenserer for en adresse som oversettelsen lenger opp ikke vil videresende.

Sett kontrollene i rekkefølge utenfra og inn

Rekkefølgen nedenfor går fra den ytre forbindelsen og innover, og det er stoppen ved første feilende trinn som gjør den nyttig: hver gjennomgang utelukker laget over. Hold den rekkefølgen selv når feilen ser åpenbar ut.

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

Den første kommandoen viser gjeldende endepunkt og håndtrykkets alder for hver peer. Den andre og tredje viser om det ytre grensesnittet og ruten til endepunktet fortsatt gir mening. conntrack-tallet er en grov kontroll for tilstand tilbake fra den forrige adressen, og journalen er stedet der årsaken til gjenoppkoblingen registreres.

Test deretter fra en LAN-klient i stedet for fra ruteren. En ping sendt av ruteren selv bruker en annen vei enn videresendt trafikk, så en vellykket ruter-ping beviser at tunnelen finnes, og ingenting om klientens rekkevidde.

Bestem den forventede atferden og skriv den ned

Gjenoppkobling er riktig atferd for de fleste utrullinger, så målet er ikke å forhindre det. Bestem i stedet hva som skal skje med trafikken i hullet: stoppe den, holde den, eller bytte til en annen vei. Den beslutningen hører til brannmuren og ruterpolitikken, ikke i VPN-profilen.

Registrer aksesshendelsene og gjenoppkoblingstidene sammen i en uke. Gjentatte endringer uten en samsvarende aksesshendelse peker på aksesstjenesten, og å bytte VPN-profilen retter ikke en uplink som stadig forhandler på nytt. Ett enkelt par oppføringer i samme minutt avgjør spørsmålet for den hendelsen og gir den neste en basislinje.