OpenVPN held fram med å dytte gamle ruter? Sjekk kva det lasta

Du legg til ei rute, startar tenesta på nytt, koplar til igjen, og tabellen til klienten ser nøyaktig ut som før. To ulike ting kan vere sanne: tenaren lasta aldri endringa di, eller klienten installerte aldri det han fekk. Dei har ingenting til felles bortsett frå symptomet, så det første steget er å finne ut kva av dei to du har.

Samanlikninga nedanfor går frå prosessen og utover, fordi prosessen er den einaste autoriteten på kva fil som gjeld.

Fila du redigerte, og fila prosessen les

Start med unit og kommandolinja ho produserte. På ein systemd-vert skriv systemctl cat openvpn@server ut linja ExecStart, og ein instans-unit leier vanlegvis konfigurasjonsstien sin frå instansnamnet, så ein daemon som er starta som openvpn@office, les ei anna fil enn ein som er starta som openvpn@server. Samanlikn det med argv til prosessen som køyrer. Eit konfigurasjonsstyringsverktøy legg til ein annan måte å miste endringa på: det kan skrive ei korrekt fil på ein stad unit aldri nemner, og då ser ein grøn utrulling ut som ingenting.

Tidsstempel avgjer det raskt: er fila nyare enn starttida til prosessen, kan prosessen ikkje ha lese ho. Rutervare legg til eit tredje tilfelle, fordi mange modellar held innstillingane i flash og byggjer konfigurasjonen på nytt under oppstart, noko som gjer ei filendring på disken til heilt feil lag.

Kva tenaren dyttar, og kva klienten installerer

Ei dytta rute må overleve to filter. På tenaren må ho stå i den lasta konfigurasjonen, ikkje i ein kommentert blokk eller i ei klientspesifikk fil der namnet ikkje stemmer. På klienten må pull vere slått på, og ingen pull-filter kan kaste valet. Kopla til med verbosity 4 og les dei dytta vala klienten rapporterer: står ruta på den lista, har tenaren gjort jobben sin, og klienten vel å ikkje installere ho.

Klientspesifikke filer er ei vanleg kjelde til forvirring. Ei fil som er kalla opp etter common name til sertifikatet, dyttar val berre til den klienten, og ein skilnad på eitt teikn stoppar dyttinga stille, utan feil på nokon av sidene. Tenaren loggar common name han såg ved tilkopling, så samanlikn den verdien med filnamnet, ikkje med det du trur klienten heiter.

Det dytta prefikset og returvegen er ulike problem

Ein klient som med vilje ignorerer redirect-gateway for å halde den lokale internettvegen sin, lagar eit andre, urelatert gap. Probane til tenaren når tunneladressa, og svara kjem aldri fram, fordi eit svar adressert til tunnel-IP-en til tenaren blir ruta via den vanlege standardporten til klienten. Den dytta subnett-ruta har ikkje skulda her; det som manglar, er ei rute som sender trafikk for tunnelnettet til tenaren tilbake gjennom tunneleininga.

Å leggje til den ruta på klienten rettar svar på probar tenaren startar. Ho erstattar ikkje den dytta subnett-ruta, og det motsette gjeld òg, fordi dei to skildrar motsette reiseretningar.

Samanlikn tabellane i begge endar

Etter kvar endring koplar du til igjen og les tabellen til klienten for det dytta prefikset og for tunneleininga. Test deretter i begge retningar: frå klienten til ein vert på det dytta subnettet, og frå den verten tilbake til klienten. Ei rute som finst, men ikkje ber trafikk, tyder ein av tre ting: den andre sida videresender ikkje, ein brannmur slepp straumen, eller svaret har ingen veg tilbake.

Hald tre identifikatorar saman: konfigurasjonsstien, namnet på unit eller instans, og klientidentiteten du testa med.

Desse tre gjer neste hending til ein femminutts sjekk i staden for ei ny undersøking, og dei er det ein kollega treng når tunnelen blir nokon andre sitt problem.

Eit ruteproblem som overlever ein omstart er ofte ikkje eit ruteproblem i det heile; feilen sit over tabellen du held fram med å lese.