Mihin reitti kuuluu OpenVPN:ssä: asiakkaaseen vai palvelimeen?
Paljaan reitin lisääminen palvelimen asetukseen muuttaa palvelinta, ei asiakasta. Valitse asiakastiedosto, yleinen push tai yhden asiakkaan push, ja tarkista, mitä perille tuli.
Lisäät route 10.60.0.0 255.255.255.0 palvelimen asetukseen, käynnistät uudelleen, yhdistät kannettavan uudelleen, ja aliverkko on edelleen tavoittamattomissa kyseisestä kannettavasta. Rivi hyväksyttiin, palvelu käynnistyi puhtaasti, eikä lokissa näytä olevan mitään vialla. Kävi niin, että reitti asennettiin koneeseen, jota muokkasit: yhdyskäytävä uskoo nyt voivansa tavoittaa kyseisen etuliitteen, kun taas asiakkaalle ei kerrottu mitään. Sijoittelu on koko kysymys, ja on neljä paikkaa, joissa sama rivi voi elää.
Neljä paikkaa ja kuka kunkin vastaanottaa
Reitti voidaan lisätä asiakkaan omalla asetuksella, tarjota jokaiselle asiakkaalle yleisellä pushilla, tarjota yhdelle asiakkaalle asiakaskohtaisella tiedostolla tai kirjoittaa palvelimen omaan reitityskontekstiin.
Nämä neljä tapausta käyttävät lähes samanlaista syntaksia ja tuottavat täysin erilaisia tuloksia. Kolme ensimmäistä vaikuttavat siihen, mitä asiakas lähettää tunneliin; neljäs vaikuttaa siihen, miten palvelin tavoittaa verkon, mikä on hyödyllistä silloin, kun palvelin itse tarvitsee polun, ja haitallista silloin, kun se sekoitetaan jakeluun.
Päätä, minkä neljästä haluat, ennen kuin kirjoitat rivin, ja vahvista sitten vastaanottaja.
| Placement | Effect | Receiver |
|---|---|---|
| Client profile route | Installed by the client at connect | That client only |
Global push "route ..." | Sent to every client that accepts pushed options | All pulling clients |
| Client-specific push | Sent to the matching client context | One identity |
| Server config route, no push | Added to the server's own table | The gateway itself |
Miksi paljas palvelinreitti yllättää ihmiset
Palvelimen asetukset ovat ensimmäinen paikka, johon ylläpitäjät katsovat, ja reittidirektiivi siellä luetaan VPN-verkkoa koskevana väitteenä. Se ei ole. OpenVPN käsittelee sitä paikallisena reittiasennuksena koneessa, jossa daemon pyörii, eli täsmälleen samana muutoksena, jonka tekisit komennolla ip route ja sitten unohtaisit.
Jakelu edellyttää, että reitti työnnetään pushilla, ja push edellyttää, että asiakas vetää sen. Asiakas, joka käynnistettiin vedetyt valinnat poistettuna käytöstä, jättää tarjouksen kokonaan huomiotta. Tarkista tämän kättelyn molemmat päät ennen palvelintiedoston uudelleenkirjoittamista, koska palvelimen loki ei valita: sen puolelta tarjous lähetettiin. Hyväksytty reitti astuu voimaan myös vasta seuraavassa yhteydessä, ei koskaan siinä istunnossa, jossa jo olet.
Kun näet kaksi toimintoa erillisinä, vika lakkaa olemasta arvoituksellinen: palvelin tavoittaa etuliitteen, asiakas ei, ja molemmat väitteet ovat tosia samaan aikaan.
Asiakaskohtaiset tiedostot ja identiteetti, johon ne sopivat
Asiakaskohtainen tiedosto nimetään sen identiteetin mukaan, jonka palvelin vahvisti, ja se on oletuksena varmenteen yleinen nimi. Työpöytäasiakkaan ystävällinen yhteyden nimi ei ole tuo arvo, ja epäjohdonmukaisuus tuottaa tiedoston, jota ei koskaan lueta.
Tarkista hakemisto, jota palvelin todella käyttää, ja vahvista sitten, että tiedostonimi vastaa vahvistettua identiteettiä täsmälleen, myös isoilla ja pienillä kirjaimilla.
grep -n 'client-config-dir' /etc/openvpn/server/server.conf
ls -l /etc/openvpn/ccd/Tuon tiedoston sisällä reitti on yhä työnnettävä pushilla, koska asiakaskohtainen konteksti on joukko valintoja, jotka kohdistetaan kyseisen asiakkaan istuntoon, ei paikallinen reititystaulu. Paljas reitti siellä kärsii samasta ongelmasta kuin paljas reitti yleisessä tiedostossa.
Asiakkaan oma tiedosto ja työkalu, joka sitä hallitsee
Asiakkaan asetukseen sijoitettu reitti asennetaan, kun kyseinen asiakas yhdistää, ja poistetaan, kun se katkaisee yhteyden, mikä on oikea elinkaari staattiselle kohteelle.
Jos verkko-hallintaohjelma omistaa profiilin, se voi tuoda nämä valinnat kerran ja pitää sitten oman kopionsa. Ladatun tiedoston muokkaaminen myöhemmin ei muuta mitään, mikä on yleinen syy ilmaukselle "reitti on siellä mutta ei päde".
Tarkista aktiivinen profiili ladatun tiedoston sijaan ja tarkista hallintaohjelman näyttämät tuodut asetukset. Yhdistä sitten ja kysy järjestelmältä, mitä polkua tietty osoite käyttää, sen sijaan että olettaisit tunnelin voittaneen, koska reitti oli tekstitiedostossa.
Tarkista asiakkaalta ja tarkista sitten paluupolku
Kysy kohteesta asiakkaan omalta reititystaululta, ei palvelimen. Yhden isännän haku etuliitteen sisällä riittää näyttämään käytettävän rajapinnan ja seuraavan hypyn.
ip route get 10.60.0.10Jos haku osoittaa tunneliin, jakelu toimi ja jäljellä oleva ongelma on muualla. Jos se osoittaa oletusyhdyskäytävään, reittiä ei asennettu, asiakaspuolen valinta suodatti sen tai se kuuluu profiiliin, jota asiakas ei käytä.
Oleta, että jakelu toimi, eikä mikään silti vastaa: tarkista silloin edelleenlähetys yhdyskäytävällä, vastapuolen paluureitti ja mahdollinen palomuuri niiden välissä. Reitti valitsee polun, se ei anna pääsyä.