OpenVPN bliver ved med at skubbe gamle ruter? Se, hvad den har indlæst

Du tilføjer en rute, genstarter tjenesten, genopretter forbindelsen, og klientens tabel ser præcis ud som før. To forskellige ting kan være sande: serveren har aldrig indlæst din ændring, eller klienten har aldrig installeret det, den modtog. De har intet til fælles undtagen symptomet, så det første skridt er at finde ud af, hvilken af de to du har.

Sammenligningen nedenfor går fra processen og udad, fordi processen er den eneste autoritet på, hvilken fil der gælder.

Filen, du redigerede, og filen, processen læser

Begynd med unit og den kommandolinje, den har frembragt. På en systemd-vært udskriver systemctl cat openvpn@server linjen ExecStart, og en instans-unit udleder normalt sin konfigurationssti af instansnavnet, så en daemon startet som openvpn@office læser en anden fil end en startet som openvpn@server. Sammenlign det med argv for den kørende proces. Et konfigurationsstyringsværktøj tilføjer endnu en måde at miste ændringen på: det kan skrive en korrekt fil et sted, som unit aldrig nævner, og så ser et grønt deploy ud som ingenting.

Tidsstempler afgør det hurtigt: er filen nyere end processens starttid, kan processen ikke have læst den. Router-firmware tilføjer et tredje tilfælde, fordi mange modeller gemmer deres indstillinger i flash og genopbygger konfigurationen under opstart, hvilket gør en filredigering på disken til det helt forkerte lag.

Hvad serveren skubber, og hvad klienten installerer

En skubbet rute skal overleve to filtre. På serveren skal den stå i den indlæste konfiguration og ikke i en kommenteret blok eller i en klientfil, hvis navn ikke passer. På klienten skal pull være slået til, og ingen pull-filter må kassere valgmuligheden. Forbind med verbosity 4 og læs de skubbede valgmuligheder, som klienten rapporterer: hvis ruten står på den liste, har serveren gjort sit arbejde, og klienten vælger ikke at installere den.

Klientfiler er en hyppig kilde til forvirring. En fil, der er opkaldt efter certificatets common name, skubber valgmuligheder til den klient alene, og en forskel på ét tegn stopper skubningen lydløst, uden fejl på nogen af siderne. Serveren logger det common name, den så ved forbindelsen, så sammenlign den værdi med filnavnet i stedet for med det, du tror, klienten hedder.

Det skubbede præfiks og returruten er forskellige problemer

En klient, der bevidst ignorerer redirect-gateway for at beholde sin lokale internetvej, skaber et andet, urelateret hul. Serverens probes når tunneladressen, og svarene kommer aldrig frem, fordi et svar, der er adresseret til serverens tunnel-IP, rutes via klientens almindelige standardgateway. Den skubbede subnetrute har ikke skylden her; det, der mangler, er en rute, der sender trafik for serverens tunnelnetsværk tilbage gennem tunnelenheden.

At tilføje den rute på klienten retter svar på probes, som serveren starter. Den erstatter ikke den skubbede subnetrute, og det omvendte gælder også, fordi de to beskriver modsatte rejseretninger.

Sammenlign tabellerne i begge ender

Efter enhver ændring skal du genoprette forbindelsen og læse klientens tabel for det skubbede præfiks og for tunnelenheden. Test derefter i begge retninger: fra klienten til en vært på det skubbede subnet og fra den vært tilbage til klienten. En rute, der findes, men ikke bærer trafik, betyder en af tre ting: den anden side videresender ikke, en firewall kasserer strømmen, eller svaret har ingen vej tilbage.

Hold tre identifikatorer sammen: konfigurationsstien, unit- eller instansnavnet og den klientidentitet, du testede med.

De tre gør næste forekomst til et femminutters tjek i stedet for en ny undersøgelse, og de er det, en kollega har brug for, når tunnelen bliver en andens problem.

Et ruteproblem, der overlever en genstart, er ofte slet ikke et routingproblem; fejlen sidder oven over den tabel, du bliver ved med at læse.