OpenVPN fortsätter att skicka gamla rutter? Kontrollera vad det laddade

Du lägger till en rutt, startar om tjänsten, ansluter igen, och klientens tabell ser exakt ut som förut. Två olika saker kan vara sanna: servern laddade aldrig din ändring, eller klienten installerade aldrig det den fick. De har inget gemensamt utom symptomet, så första steget är att ta reda på vilket av de två du har.

Jämförelsen nedan går från processen och utåt, eftersom processen är den enda auktoriteten för vilken fil som gäller.

Filen du redigerade och filen som processen läser

Börja med unit och den kommandorad den producerade. På en systemd-värd skriver systemctl cat openvpn@server ut raden ExecStart, och en instans-unit härleder vanligtvis sin konfigurationssökväg från instansnamnet, så en daemon som startats som openvpn@office läser en annan fil än en som startats som openvpn@server. Jämför det med argv för den körande processen. Ett konfigurationshanteringsverktyg lägger till ett annat sätt att förlora ändringen: det kan skriva en korrekt fil på en plats som unit aldrig nämner, och då ser en grön utrullning ut som ingenting.

Tidsstämplar avgör det snabbt: om filen är nyare än processens starttid kan processen inte ha läst den. Routerns firmware lägger till ett tredje fall, eftersom många modeller har sina inställningar i flash och bygger om konfigurationen vid uppstart, vilket gör en filändring på disken till helt fel lager.

Vad servern skickar och vad klienten installerar

En skickad rutt måste överleva två filter. På servern måste den stå i den laddade konfigurationen, inte i ett kommenterat block eller i en klientspecifik fil vars namn inte stämmer. På klienten måste pull vara påslaget och ingen pull-filter får kasta bort alternativet. Anslut med verbosity 4 och läs de skickade alternativ som klienten rapporterar: om rutten finns i den listan har servern gjort sitt, och klienten väljer att inte installera den.

Klientspecifika filer är en vanlig källa till förvirring. En fil som är uppkallad efter certifikatets common name skickar alternativ bara till den klienten, och en skillnad på ett tecken stoppar sändningen tyst, utan fel på någon av sidorna. Servern loggar det common name den såg vid anslutningen, så jämför det värdet med filnamnet, inte med vad du tror att klienten heter.

Det skickade prefixet och returvägen är olika problem

En klient som medvetet ignorerar redirect-gateway för att behålla sin lokala internetväg skapar en andra, orelaterad lucka. Serverns prober når tunneladressen men svaren kommer aldrig fram, eftersom ett svar adresserat till serverns tunnel-IP routas via klientens vanliga standardgateway. Den skickade subnät-rutten är inte skyldig här; det som saknas är en rutt som skickar trafik för serverns tunnelnät tillbaka genom tunnelenheten.

Att lägga till den rutten på klienten rättar svar på prober som servern startar. Den ersätter inte den skickade subnät-rutten, och det omvända gäller också, eftersom de två beskriver motsatta färdriktningar.

Jämför tabellerna i båda ändar

Efter varje ändring, anslut igen och läs klientens tabell för det skickade prefixet och för tunnelenheten. Testa sedan i båda riktningar: från klienten till en värd på det skickade subnätet, och från den värden tillbaka till klienten. En rutt som finns men inte bär trafik betyder en av tre saker: den andra sidan vidarebefordrar inte, en brandvägg släpper flödet, eller svaret har ingen väg tillbaka.

Håll tre identifierare tillsammans: konfigurationssökvägen, namnet på unit eller instans och klientidentiteten du testade med.

Dessa tre gör nästa händelse till en femminuterskontroll i stället för en ny utredning, och de är vad en kollega behöver när tunneln blir någon annans problem.

Ett ruttproblem som överlever en omstart är ofta inte ett routingproblem alls; felet sitter ovanför tabellen du fortsätter att läsa.