OpenVPN faller efter en DHCP-förnyelse: behåll rutten till slutpunkten

Tunneln ansluter, sedan dödar en leaseförnyelse på åtkomstlänken den, och loggen skyller på en timeout i stället för en rutt. Ingenting i VPN-konfigurationen har ändrats, och det är själva ledtråden: något utanför den har ändrats. En DHCP-händelse skrev om adressen eller gatewayen, och värdrutten som höll tunnelns slutpunkt nåbar pekar nu på ett nästa hopp som inte finns längre. Det här är ett ägarproblem innan det är ett routingproblem.

Jämför symtomet med halvstandardrutterna

Med redirect-gateway def1 installerar OpenVPN 0.0.0.0/1 och 128.0.0.0/1 i stället för att ersätta standardrutten. Tillsammans täcker de två hela adressutrymmet, och de slår 0.0.0.0/0 bara på prefixlängden. Därför går varje destination utan en mer specifik träff in i tunneln.

Slutpunkten behöver ett undantag. OpenVPN lägger till en värdrutt till serveradressen via den ursprungliga åtkomstgatewayen innan halvstandarderna läggs in, så att inkapslade paket kan komma ut. När undantaget försvinner, eller behåller ett nästa hopp som inte finns längre, matchar tunnelns egna yttre paket en halvstandard och skickas tillbaka in i tunneln. Resultatet är en anslutning som dör vid nästa keepalive eller handskakning, utan något i loggen som ser ut som ett routingfel.

Bekräfta tabellens form innan du rör något annat. ip route show bör lista båda halvorna plus en värdrutt för serveradressen; när värdrutten saknas har resten av utredningen en uppenbar startpunkt.

Varför halvstandarderna vinner utan en metrikändring

Ett lägre metrikvärde slår inte ett längre prefix. Rutterna /1 vinner eftersom kärnan först matchar den mest specifika rutten, så att höja ett metrikvärde på standardrutten ändrar ingenting för vart trafik mot tunneln tar vägen. Att jaga metrikvärden är den vanligaste felaktiga svängen i den här diagnosen.

Kontrollera valet med ip route get 203.0.113.10, och sätt in den riktiga serveradressen. Svaret namnger gränssnittet och nästa hopp som kärnan faktiskt skulle använda, vilket är mer informativt än att läsa en tabell och resonera om den.

Kör det kommandot innan tunneln startar, medan den är uppe och efter leasehändelsen. Tre svar från ett kommando, och divergenspunkten blir synlig.

Ta tre ögonblicksbilder, inte en

Samla åtkomstadressen, åtkomstgatewayen, slutpunktens destination, den valda rutten och eventuella policyregler vid tre tillfällen: efter att åtkomstlänken konfigurerats, efter att VPN anslutit och efter lease- eller operatörshändelsen. Varje ögonblicksbild är en handfull kommandon, och de betyder bara något tillsammans. En enda ögonblicksbild efter felet registrerar tillståndet i stället för övergången. Skriv kommandona i ett litet skript så att varje ögonblicksbild tas på samma sätt.

Håll ögonblicksbilderna i en fil med tidsstämplar, för den intressanta frågan senare är ordningen. Kom DHCP-händelsen före eller efter att OpenVPN förnyade sin rutt? Svaret avgör vem som måste rätta det. En tidsstämpel från en felaktig klocka är sämre än ingen, så ta den från värden som äger routingtabellen.

När slutpunkten är konfigurerad som ett namn i stället för en adress, lös upp det också i varje ögonblicksbild. En DNS-ändring på åtkomstlänken kan flytta slutpunkten utan att någon rutt rörs.

Bestäm vilken komponent som förnyar undantaget

På ett dhcpcd-system körs krokar från krok-katalogen och från exit-kroken, och hanterarläget skiljer sig i omfattning från läget per gränssnitt. Vad kroken än gör måste den vara idempotent, eftersom förnyelser kan komma i skurar.

Den pålitliga ägaren är integrationen som redan känner båda sidor: en nätverkshanterare som hanterar VPN-anslutningen, eller en unit ordnad efter att åtkomstlänken kommer upp. En statisk rutt som en krok lägger till fungerar till nästa gatewayändring och misslyckas sedan på exakt samma sätt. Om du ändå använder en krok, låt den läsa den aktuella gatewayen vid körning i stället för att hårdkoda den du såg i dag.

Anteckna ägaren i konfigurationen. Nästa person som felsöker en återanslutning behöver veta att det är en krok, inte VPN, som ansvarar för undantagsrutten.

Testa livscykeln, inte bara återanslutningen

Tvinga en förnyelse med dhcpcd -n eth0 eller genom att släppa och förnya leasen, och kontrollera sedan ip route get igen för slutpunkten. Gör det två gånger, eftersom den andra körningen fångar krokar som lägger till dubbla rutter. Starta sedan om, eftersom persistens är en annan egenskap än korrekthet.

En tunnel som överlever en förnyelse och en omstart har en ägare och ett fungerande undantag. En som bara överlever en manuell omstart har inget av dem, och kommer att misslyckas vid nästa händelse som du inte kan schemalägga.