Työntääkö OpenVPN yhä vanhoja reittejä? Tarkista, mitä se latasi

Lisäät reitin, käynnistät palvelun uudelleen, yhdistät uudelleen, ja asiakkaan taulukko näyttää täsmälleen samalta kuin ennen. Kaksi eri asiaa voi olla totta: palvelin ei koskaan ladannut muutostasi tai asiakas ei koskaan asentanut saamaansa. Yhteistä niillä on vain oire, joten ensimmäinen askel on selvittää, kumpi tapaus sinulla on.

Alla oleva vertailu etenee prosessista ulospäin, koska prosessi on ainoa auktoriteetti siinä, mikä tiedosto on voimassa.

Tiedosto, jota muokkasit, ja tiedosto, jota prosessi lukee

Aloita unitista ja sen tuottamasta komentorivistä. systemd-isännässä systemctl cat openvpn@server tulostaa rivin ExecStart, ja instanssiunit johtaa konfiguraatiopolkunsa yleensä instanssin nimestä, joten nimellä openvpn@office käynnistetty daemon lukee eri tiedostoa kuin nimellä openvpn@server käynnistetty. Vertaa tätä käynnissä olevan prosessin argviin. Konfiguraationhallintatyökalu lisää vielä yhden tavan hukata muutos: se voi kirjoittaa oikean tiedoston paikkaan, jota unit ei koskaan mainitse, ja silloin vihreä julkaisu näyttää tyhjältä.

Aikaleimat ratkaisevat asian nopeasti: jos tiedosto on uudempi kuin prosessin aloitusaika, prosessi ei ole voinut lukea sitä. Reitittimen laiteohjelmisto lisää kolmannen tapauksen, koska monet mallit pitävät asetuksensa flash-muistissa ja rakentavat konfiguraation uudelleen käynnistyksen aikana, mikä tekee levyllä olevan tiedoston muokkaamisesta täysin väärän kerroksen.

Mitä palvelin työntää ja mitä asiakas asentaa

Työnnetyn reitin on läpäistävä kaksi suodatinta. Palvelimella sen on oltava ladatussa konfiguraatiossa, ei kommentoidussa lohkossa eikä asiakaskohtaisessa tiedostossa, jonka nimi ei täsmää. Asiakkaalla pull on oltava käytössä eikä minkään pull-filter-asetuksen saa hylätä vaihtoehtoa. Yhdistä verbosity 4:llä ja lue työnnetyt asetukset, jotka asiakas raportoi: jos reitti on siinä luettelossa, palvelin teki osuutensa ja asiakas valitsee olla asentamatta sitä.

Asiakaskohtaiset tiedostot ovat tavallinen hämmennyslähde. Varmenteen common namen mukaan nimetty tiedosto työntää asetuksia vain kyseiselle asiakkaalle, ja yhden merkin ero pysäyttää työnnön äänettömästi ilman virhettä kummallakaan puolella. Palvelin kirjaa common namen, jonka näki yhteyden aikana, joten vertaa sitä arvoa tiedostonimeen äläkä siihen, mitä luulet asiakkaan nimeksi.

Työnnetty etuliite ja paluureitti ovat eri ongelmia

Asiakas, joka jättää tarkoituksella huomiotta redirect-gateway-asetuksen säilyttääkseen paikallisen internet-reittinsä, luo toisen, siihen liittymättömän aukon. Palvelimen kokeet saavuttavat tunnelin osoitteen, mutta vastaukset eivät koskaan saavu, koska palvelimen tunnelin IP:hen osoitettu vastaus reititetään asiakkaan tavallisen oletusyhdyskäytävän kautta. Työnnetty aliverkkoreitti ei ole tässä syyllinen; puuttuu reitti, joka lähettää palvelimen tunneliverkon liikenteen takaisin tunnelilaitteeseen.

Kyseisen reitin lisääminen asiakkaalle korjaa vastaukset palvelimen käynnistämiin kokeisiin. Se ei korvaa työnnettyä aliverkkoreittiä, ja päinvastoin pätee sama, koska kaksi kuvaa vastakkaisia kulkusuuntia.

Vertaa taulukoita molemmissa päissä

Yhdistä uudelleen jokaisen muutoksen jälkeen ja lue asiakkaan taulukosta työnnetty etuliite ja tunnelilaite. Testaa sitten molempiin suuntiin: asiakkaasta työnnetyn aliverkon isäntään ja siitä isännästä takaisin asiakkaaseen. Reitti, joka on olemassa mutta ei kuljeta liikennettä, tarkoittaa yhtä kolmesta: vastapuoli ei välitä, palomuuri pudottaa virtauksen tai vastauksella ei ole paluutietä.

Pidä kolme tunnistetta yhdessä: konfiguraatiopolku, unitin tai instanssin nimi ja asiakkaan identiteetti, jolla testasit.

Nämä kolme tekevät seuraavasta tapauksesta viiden minuutin tarkistuksen uuden tutkimuksen sijaan, ja juuri niitä kollega tarvitsee, kun tunnelista tulee jonkun toisen ongelma.

Uudelleenkäynnistyksen kestävä reittiongelma ei usein ole lainkaan reititysongelma; vika on ylempänä kuin taulukossa, jota jatkuvasti luet.