OpenVPN:n työntämät reitit eivät asennu: ajoitus, oikeudet vai käytäntö

Palvelin sanoo työntäneensä reitin, asiakas sanoo olevansa yhteydessä, ja kohde on silti tavoittamattomissa. Juuri tuon kuvan tuottaa kolme syytä. Reitin lisääminen ajettiin ennen kuin laite oli olemassa, asiakkaalta puuttuivat oikeudet taulun muuttamiseen tai käytäntö käski asiakasta jättää työnnetyt asetukset huomiotta.

Ulkopuolelta ne näyttävät samoilta ja vaativat eri korjauksia. Lue asiakkaan loki kohdasta, jossa reittipäätös tehdään.

Todista, että reitti puuttuu, ei vain että se on rikki

Aloita todistamalla, että reitti puuttuu eikä ole vain rikki. Linuxissa ip route show dev tun0 luettelee, mitä asiakas asensi tunnelilaitteelle. Windowsissa route print tai Get-NetRoute näyttää saman taulukkomuodossa.

Reitti, joka on olemassa mutta ei välitä liikennettä, on eri ongelma. Se siirtää tutkinnan välitys- ja palomuurisääntöihin, ei reitin asentamiseen.

Ajoitus: lisäys ajettiin ennen kuin laite oli olemassa

Asiakas jäsentää palvelimen PUSH_REPLY, kun ohjauskanava on ylhäällä ja kun se on määrittänyt rajapinnan. Vasta sitten se koskee reititystauluun käyttäen sitä mekanismia, jonka alusta tarjoaa. Linux kulkee netlinkin kautta; Windows käyttää API:a, joka vaatii korotetun tunnisteen. Komentosarja tai asiakas, joka lisää reittejä heti luettuaan kokoonpanon, voi ajaa ennen kuin TUN/TAP-laite on olemassa, ja ydin hylkää lisäyksen.

Sama kilpailu selittää, miksi käsin kirjoitettu reitti toimii mutta automaattinen ei: kun kirjoitat sen, rajapinta on jo ylhäällä.

route-delay on olemassa juuri tätä tapausta varten, ja route-up nimeää komentosarjan, joka ajetaan, kun rajapinta ja reitit on määritetty. Laita tunneliosoitteesta riippuvat reitit tuohon koukkuun, älä varhaiseen vaiheeseen.

Oikeudet: kuka saa muuttaa taulua

Windowsin reititystaulun muuttaminen vaatii korotetun tunnisteen. Tavallisen käyttäjän käynnistämä GUI voi asettaa sovittimen osoitteen palvelun kautta ja silti olla lisäämättä reittiä. Silloin loki näyttää käyttöoikeus evätty -tyylisen virheen eikä puuttuvaa työntöä.

GUIn käynnistäminen järjestelmänvalvojana tai palvelupohjaisen asiakkaan käyttäminen muuttaa tuloksen. Ajastettu tehtävä, joka käynnistää asiakkaan ilman vaadittua tunnistetta, ei muuta.

Tarkista millä tilillä asiakas todella toimii ennen kuin muutat mitään. Versio ja palvelutila ratkaisevat, mitkä syyt ovat ylipäätään mahdollisia, joten kirjaa molemmat reittitulosteen viereen.

Käytäntö: työnnetyt reitit voidaan hylätä tarkoituksella

route-nopull saa asiakkaan jättämään huomiotta reitit, joita palvelin työntää, mukaan lukien työnnetty oletusreitti, sillä välin kun tunneliosoite hyväksytään edelleen. Työnnetyt DNS- ja DHCP-asetukset pudotetaan samalla direktiivillä. Tällainen asiakas ei ole viallinen; se odottaa nimenomaisia reittirivejä omassa kokoonpanossaan.

route-noexec on toinen ohjaus: se estää asiakasta kokonaan suorittamasta reittimuutoksia. Topologia, jota asiakas ei pysty kartoittamaan, voi tuottaa samanlaisen tuloksen, jolloin reitti kirjataan hylättynä eikä lisättynä. Lue lokirivi, joka kertoo päätöksen, sen sijaan että arvaisit, mikä kolmesta pätee. Tarkista sitten tehokas profiili, koska tuontityökalu tai hallintatyökalu voi lisätä asetuksia, joita käyttäjä ei koskaan muokannut.

Profiili, joka näyttää siistiltä tekstieditorissa, voi silti kantaa lisätyn direktiivin suorituksen aikana.

Vertaa työntöluetteloa tauluun

Yhdistämisen jälkeen aseta palvelimen työntöluettelo asiakkaan taulun viereen. Linuxissa se on ip route show dev tun0; Windowsissa route print tai Get-NetRoute. Jos reitti puuttuu, korjaa ensin asennus. Jos se on olemassa ja liikenne epäonnistuu, siirry välitys- ja palomuurikäytäntöön.

Kirjaa asiakkaan versio, tili, jolla se toimii, ja se, onko se palvelupohjainen. Nämä kolme tosiasiaa kertovat seuraavalle henkilölle, mitkä syyt on suljettu pois.