OpenVPN fortsetter å dytte gamle ruter? Sjekk hva det lastet

Du legger til en rute, starter tjenesten på nytt, kobler til igjen, og tabellen til klienten ser nøyaktig ut som før. To forskjellige ting kan være sant: serveren lastet aldri endringen din, eller klienten installerte aldri det den fikk. De har ingenting til felles bortsett fra symptomet, så det første steget er å finne ut hvilke av de to du har.

Sammenligningen nedenfor går fra prosessen og utover, fordi prosessen er den eneste autoriteten på hvilken fil som gjelder.

Filen du redigerte, og filen prosessen leser

Start med unit og kommandolinjen den produserte. På en systemd-vert skriver systemctl cat openvpn@server ut linjen ExecStart, og en instans-unit utleder vanligvis konfigurasjonsstien sin fra instansnavnet, så en daemon startet som openvpn@office leser en annen fil enn en startet som openvpn@server. Sammenlign det med argv til prosessen som kjører. Et konfigurasjonsstyringsverktøy legger til en annen måte å miste endringen på: det kan skrive en korrekt fil på et sted unit aldri nevner, og da ser en grønn utrulling ut som ingenting.

Tidsstempler avgjør det raskt: hvis filen er nyere enn prosessens starttid, kan prosessen ikke ha lest den. Rutervare legger til et tredje tilfelle, fordi mange modeller holder innstillingene i flash og bygger konfigurasjonen på nytt under oppstart, noe som gjør en filredigering på disken til helt feil lag.

Hva serveren dytter, og hva klienten installerer

En dyttet rute må overleve to filtre. På serveren må den stå i den lastede konfigurasjonen, ikke i en kommentert blokk eller i en klientspesifikk fil der navnet ikke stemmer. På klienten må pull være slått på, og ingen pull-filter kan forkaste valget. Koble til med verbosity 4 og les de dyttede valgene klienten rapporterer: hvis ruten står på den listen, har serveren gjort jobben sin, og klienten velger å ikke installere den.

Klientspesifikke filer er en vanlig kilde til forvirring. En fil som er oppkalt etter sertifikatets common name, dytter valg bare til den klienten, og en forskjell på ett tegn stopper dyttingen stille, uten feil på noen av sidene. Serveren logger common name den så ved tilkobling, så sammenlign den verdien med filnavnet, ikke med det du tror klienten heter.

Det dyttede prefikset og returveien er forskjellige problemer

En klient som bevisst ignorerer redirect-gateway for å beholde den lokale internettveien sin, lager et andre, urelatert gap. Probene til serveren når tunneladressen, og svarene kommer aldri fram, fordi et svar adressert til serverens tunnel-IP rutes via klientens vanlige standardgateway. Den dyttede subnett-ruten har ikke skylden her; det som mangler, er en rute som sender trafikk for tunnel-nettet til serveren tilbake gjennom tunnelenheten.

Å legge til den ruten på klienten retter svar på prober serveren starter. Den erstatter ikke den dyttede subnett-ruten, og det motsatte gjelder også, fordi de to beskriver motsatte reiseretninger.

Sammenlign tabellene i begge ender

Etter enhver endring, koble til igjen og les tabellen til klienten for det dyttede prefikset og for tunnelenheten. Test deretter i begge retninger: fra klienten til en vert på det dyttede subnettet, og fra den verten tilbake til klienten. En rute som finnes, men ikke bærer trafikk, betyr en av tre ting: den andre siden videresender ikke, en brannmur slipper strømmen, eller svaret har ingen vei tilbake.

Hold tre identifikatorer sammen: konfigurasjonsstien, navnet på unit eller instans, og klientidentiteten du testet med.

Disse tre gjør neste hendelse til en femminutters sjekk i stedet for en ny undersøkelse, og de er det en kollega trenger når tunnelen blir noen andres problem.

Et ruteproblem som overlever en omstart er ofte ikke et ruteproblem i det hele tatt; feilen sitter over tabellen du fortsetter å lese.