WAN-IP har ändrats och tunneln föll: kontrollerna i ordning

Tunneln faller, routern loggar en återanslutning och ingenting på LANet har flyttat sig. En ny WAN-adress ogiltigförklarar den yttre förbindelsen utan att ändra något inuti: klientens källadress har ändrats, det gamla NAT-tillståndet pekar på en källa som inte längre finns, och den avlägsna peeren skickar kanske fortfarande till den föregående adressen. Återställning är normalt beteende, och den användbara frågan är vilket tillstånd som inte uppdaterades.

Namnge händelsen innan du läser loggen

Undersök vad som faktiskt hände på åtkomstlagret. En förnyelse av ISP-leasen är en händelse. En PPPoE-session som återanslöt är en annan. Ett fibermodem som startades om, eller en WAN-failover från en uplink till en annan, ändrar den yttre adressen eller dess väg på ett tredje sätt. De är inte samma händelse och de lämnar inte samma rest.

En återanslutningsrad i VPN-loggen är inte heller bevis på en WAN-ändring. En inaktivitetstimeout, ett intervall för omautentisering och detektering av död peer ger alla återanslutningar utan någon adressändring. Jämför tidsstämplar från åtkomstloggen med VPN-loggen innan du drar någon slutsats, och håll jämförelsefönstret brett nog att fånga en ändring som skedde under natten.

Roaming och återanslutning är olika protokoll

WireGuard har autentiserad roaming inbyggd i protokollet: när en peer tar emot ett korrekt autentiserat paket från en ny källadress uppdaterar den den peerns ändpunkt. WireGuards snabbstart beskriver den peer-konfiguration som gör detta möjligt, och därför återhämtar sig en klient på en skiftande adress ofta utan en synlig omstart.

OpenVPN beter sig annorlunda som standard. En UDP-session kan avslutas och återansluta, och det valfria float-beteendet låter en autentiserad peer fortsätta från en ny adress där konfigurationen tillåter det. TCP-baserade tunnlar är strängare, eftersom själva anslutningen är bunden till adressparet. Den skillnaden avgör om återställningen ser osynlig ut eller meddelar sig i loggen varje gång.

Inget av beteendena säger något om applikationerna inuti. En återställd tunnel återställer inte en TCP-session som peeren redan ansåg vara död.

Tillstånd som tunneln inte äger

Översättnings- och routingtillstånd överlever återanslutningen på sätt som förvånar folk. En conntrack-post skapad för den gamla källan håller svarsvägen förankrad vid en adress som inte längre finns, och den löper ut enligt sitt eget schema, inte när tunneln kom tillbaka. Omstart av tunnel-tjänsten förkortar inte den väntetiden, så en reparerad länk kan fortfarande se trasig ut ett tag.

Rutter och policyregler kan referera till den gamla gatewayen eller gränssnittet. En regeluppsättning som var korrekt före ett WAN-byte kan peka på en enhet som nu är nere, vilket ger en tunnel som rapporterar sig ansluten och trafik som inte kommer någonstans. Dynamisk DNS för en server du hostar är ett separat problem från en klient som får en ny källa. Posten måste uppdateras för att fjärrklienter ska hitta dig, och ingen konfiguration på klientsidan kompenserar för en adress som översättningen längre upp inte vidarebefordrar.

Ordna kontrollerna utifrån och in

Ordningen nedan går från den yttre förbindelsen och inåt, och det är stoppet vid första misslyckade steg som gör den användbar: varje kontroll utesluter lagret ovanför. Håll den ordningen även när felet ser uppenbart 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

Det första kommandot visar aktuell ändpunkt och handskakningens ålder för varje peer. Det andra och tredje visar om det yttre gränssnittet och rutten till ändpunkten fortfarande är meningsfulla. conntrack-talet är en grov kontroll av tillstånd kvar från den föregående adressen, och journalen är där orsaken till återanslutningen registreras.

Testa sedan från en LAN-klient i stället för från routern. Ett ping som skickas av routern själv använder en annan väg än vidarebefordrad trafik, så ett lyckat ping från routern bevisar att tunneln finns och ingenting om klientens nåbarhet.

Bestäm det förväntade beteendet och skriv ned det

Återanslutning är korrekt beteende för de flesta utrullningar, så målet är inte att förhindra det. Bestäm i stället vad som ska hända med trafiken under gapet: stoppa den, hålla den eller växla till en annan väg. Det beslutet hör till brandväggen och routingpolicyn, inte till VPN-profilen.

Registrera åtkomsthändelserna och återanslutningstiderna tillsammans i en vecka. Upprepade ändringar utan en matchande åtkomsthändelse pekar på åtkomsttjänsten, och att byta VPN-profil åtgärdar inte en uplink som ständigt förhandlar om. Ett enda par poster i samma minut avgör frågan för den händelsen och ger nästa en baslinje.