WAN-IP er ændret, og tunnelen faldt: kontrollerne i rækkefølge

Tunnelen falder, routeren logger en genforbindelse, og intet på LAN'et har flyttet sig. En ny WAN-adresse ugyldiggør den ydre forbindelse uden at ændre noget indeni: klientens kildeadresse er ændret, den gamle NAT-tilstand peger på en kilde, der ikke længere findes, og den fjerne peer sender måske stadig til den forrige adresse. Genopretning er normal adfærd, og det nyttige spørgsmål er, hvilken tilstand der ikke blev opdateret.

Navngiv hændelsen, før du læser loggen

Undersøg, hvad der faktisk skete på adgangslaget. En fornyelse af ISP-leasingen er én hændelse. En PPPoE-session, der blev genoprettet, er en anden. Et fibermodem, der blev genstartet, eller en WAN-failover fra én uplink til en anden, ændrer den ydre adresse eller dens vej på en tredje måde. De er ikke den samme hændelse, og de efterlader ikke det samme restprodukt.

En genforbindelseslinje i VPN-loggen er heller ikke bevis på en WAN-ændring. En inaktivitetstimeout, et interval for genautentificering og registrering af døde peers giver alle genforbindelser uden nogen adresseændring. Sammenlign tidsstempler fra adgangsloggen med VPN-loggen, før du konkluderer noget, og hold sammenligningsvinduet bredt nok til at fange en ændring, der skete om natten.

Roaming og genforbindelse er forskellige protokoller

WireGuard har autentificeret roaming indbygget i protokollen: når en peer modtager en korrekt autentificeret pakke fra en ny kildeadresse, opdaterer den peerens endpoint. WireGuards hurtigstart beskriver den peer-konfiguration, der gør dette muligt, og derfor kommer en klient på en skiftende adresse ofte tilbage uden en synlig genstart.

OpenVPN opfører sig anderledes som standard. En UDP-session kan afsluttes og genoprettes, og den valgfrie float-adfærd lader en autentificeret peer fortsætte fra en ny adresse, hvor konfigurationen tillader det. TCP-baserede tunneler er strengere, fordi selve forbindelsen er bundet til adresseparret. Den forskel afgør, om genopretningen ser usynlig ud, eller om den melder sig i loggen hver gang.

Ingen af adfærdene siger noget om applikationerne indeni. En genoprettet tunnel genskaber ikke en TCP-session, som peeren allerede anså for død.

Tilstand, som tunnelen ikke ejer

Oversættelses- og routingtilstand overlever genforbindelsen på måder, der overrasker folk. En conntrack-post oprettet til den gamle kilde holder svarvejen forankret til en adresse, der ikke længere findes, og den udløber efter sin egen tidsplan, ikke når tunnelen kom tilbage. Genstart af tunnel-tjenesten forkorter ikke den ventetid, så et repareret link kan stadig se brudt ud et stykke tid.

Ruter og politikregler kan referere til den gamle gateway eller det gamle interface. Et regelsæt, der var korrekt før et WAN-skift, kan pege på en enhed, der nu er nede, hvilket giver en tunnel, der rapporterer som forbundet, og trafik, der ikke kommer nogen vegne. Dynamisk DNS for en server, du hoster, er et separat problem fra en klient, der får en ny kilde. Posten skal opdateres, for at fjerne klienter kan finde dig, og ingen konfiguration på klientsiden opvejer en adresse, som oversættelsen længere oppe ikke vil videresende.

Sæt kontrollerne i rækkefølge udefra og ind

Rækkefølgen nedenfor går fra den ydre forbindelse og indad, og det er stoppen ved det første fejlende trin, der gør den nyttig: hvert gennemløb udelukker laget ovenover. Hold den rækkefølge, selv når fejlen ser indlysende ud.

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 kommando viser det aktuelle endpoint og håndtrykkets alder for hver peer. Den anden og tredje viser, om det ydre interface og ruten til endpointet stadig giver mening. conntrack-tallet er en grov kontrol for tilstand tilbage fra den forrige adresse, og journalen er stedet, hvor årsagen til genforbindelsen registreres.

Test derefter fra en LAN-klient i stedet for fra routeren. Et ping sendt af routeren selv bruger en anden vej end videresendt trafik, så et vellykket router-ping beviser, at tunnelen findes, og intet om klientens rækkevidde.

Beslut den forventede adfærd, og skriv den ned

Genforbindelse er korrekt adfærd for de fleste udrulninger, så målet er ikke at forhindre det. Beslut i stedet, hvad der skal ske med trafikken i hullet: stoppe den, holde den, eller skifte til en anden vej. Den beslutning hører til firewallen og routingpolitikken, ikke i VPN-profilen.

Registrér adgangshændelserne og genforbindelsestidspunkterne sammen i en uge. Gentagne ændringer uden en matchende adgangshændelse peger på adgangstjenesten, og udskiftning af VPN-profilen retter ikke en uplink, der bliver ved med at genforhandle. Et enkelt par poster i samme minut afgør spørgsmålet for den hændelse og giver den næste en baseline.