OpenVPN blijft oude routes pushen? Controleer wat het geladen heeft

Je voegt een route toe, herstart de dienst, verbindt opnieuw, en de tabel van de client ziet er precies zo uit als voorheen. Twee verschillende dingen kunnen waar zijn: de server heeft je wijziging nooit geladen, of de client heeft nooit geïnstalleerd wat hij ontving. Ze hebben niets gemeen behalve het symptoom, dus de eerste stap is uitzoeken welke van de twee je hebt.

De vergelijking hieronder loopt van het proces naar buiten, omdat het proces de enige autoriteit is over welk bestand geldt.

Het bestand dat je hebt bewerkt en het bestand dat het proces leest

Begin bij de unit en de commandoregel die hij heeft opgeleverd. Op een systemd-host drukt systemctl cat openvpn@server de regel ExecStart af, en een instance-unit leidt zijn configuratiepad meestal af van de instancenaam, dus een daemon die als openvpn@office is gestart, leest een ander bestand dan een die als openvpn@server is gestart. Vergelijk dat met de argv van het draaiende proces. Een configuratiebeheertool voegt nog een manier toe om de wijziging kwijt te raken: hij kan een correct bestand schrijven naar een locatie die de unit nooit noemt, en dan lijkt een groene deployment op niets.

Tijdstempels beslissen het snel: als het bestand nieuwer is dan de starttijd van het proces, kan het proces het niet hebben gelezen. Routerfirmware voegt een derde geval toe, omdat veel modellen hun instellingen in flash bewaren en de configuratie tijdens het opstarten opnieuw opbouwen, waardoor een bestandswijziging op schijf volledig de verkeerde laag is.

Wat de server pusht en wat de client installeert

Een gepushte route moet twee filters overleven. Op de server moet hij in de geladen configuratie staan, niet in een uitgecommentarieerd blok of in een cliëntspecifiek bestand waarvan de naam niet klopt. Op de client moet pull aan staan en geen enkele pull-filter mag de optie weggooien. Verbind met verbosity 4 en lees de gepushte opties die de client meldt: als de route in die lijst staat, heeft de server zijn werk gedaan en kiest de client ervoor hem niet te installeren.

Cliëntspecifieke bestanden zijn een veelvoorkomende bron van verwarring. Een bestand dat naar de common name van het certificaat is vernoemd, pusht opties alleen naar die client, en een verschil van één teken stopt het pushen stil, zonder fout aan beide kanten. De server logt de common name die hij bij het verbinden zag, dus vergelijk die waarde met de bestandsnaam, niet met wat je denkt dat de client heet.

Het gepushte prefix en de retourroute zijn verschillende problemen

Een client die redirect-gateway bewust negeert om zijn lokale internetpad te behouden, creëert een tweede, ongerelateerd gat. De probes van de server bereiken het tunneladres en de antwoorden komen nooit aan, omdat een antwoord aan het tunnel-IP van de server via de gewone standaardgateway van de client wordt gerouteerd. De gepushte subnetroute is hier niet schuldig; wat ontbreekt is een route die verkeer voor het tunnelnetwerk van de server terug door het tunnelapparaat stuurt.

Die route op de client toevoegen lost antwoorden op probes die de server start op. Het is geen vervanging van de gepushte subnetroute, en het omgekeerde geldt ook, omdat de twee tegengestelde reisrichtingen beschrijven.

Vergelijk de tabellen aan beide uiteinden

Na elke wijziging verbind je opnieuw en lees je de tabel van de client voor het gepushte prefix en voor het tunnelapparaat. Test daarna in beide richtingen: van de client naar een host op het gepushte subnet, en van die host terug naar de client. Een route die bestaat maar geen verkeer draagt, betekent een van drie dingen: de andere kant stuurt niet door, een firewall laat de stroom vallen, of het antwoord heeft geen weg terug.

Houd drie identificaties bij elkaar: het configuratiepad, de naam van de unit of instance, en de clientidentiteit waarmee je hebt getest.

Die drie maken van het volgende voorval een controle van vijf minuten in plaats van een nieuw onderzoek, en ze zijn wat een collega nodig heeft wanneer de tunnel iemands anders probleem wordt.

Een routeprobleem dat een herstart overleeft, is vaak helemaal geen routeringsprobleem; de fout zit boven de tabel die je blijft lezen.