Kam spada pot v OpenVPN: k odjemalcu ali k strežniku?
Gola pot v konfiguraciji strežnika spremeni strežnik, ne odjemalca. Izberite odjemalsko datoteko, globalni push ali push za enega odjemalca, in preverite, kaj je prispelo.
Dodate route 10.60.0.0 255.255.255.0 v konfiguracijo strežnika, znova zaženete, znova povežete prenosnik in podomrežje s tega prenosnika še vedno ni dosegljivo. Vrstica je bila sprejeta, storitev se je začela čisto in v dnevniku nič ne izgleda narobe. Zgodilo se je, da je bila pot nameščena na stroju, ki ste ga urejali: prehod zdaj verjame, da lahko doseže to predpono, medtem ko odjemalcu ni bilo povedano nič. Postavitev je vse vprašanje in obstajajo štiri mesta, kjer lahko ista vrstica živi.
Štiri mesta in kdo prejme vsako
Pot je mogoče dodati z lastno konfiguracijo odjemalca, ponuditi vsakemu odjemalcu prek globalnega pusha, ponuditi enemu odjemalcu prek datoteke, specifične za odjemalca, ali zapisati v lastni kontekst usmerjanja strežnika.
Ti štirje primeri uporabljajo skoraj enako sintakso in dajejo povsem različne rezultate. Prvi trije vplivajo na to, kaj odjemalec pošlje v tunel; četrti vpliva na to, kako strežnik doseže omrežje, kar je koristno, ko strežnik sam potrebuje pot, in škodljivo, ko se zamenja za distribucijo.
Odločite se, katerega od štirih želite, preden napišete vrstico, nato potrdite prejemnika.
| 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 |
Zakaj gola strežniška pot preseneti ljudi
Konfiguracija strežnika je prvo mesto, kam pogledajo skrbniki, in direktiva poti tam se bere kot trditev o omrežju VPN. Ni. OpenVPN jo obravnava kot lokalno namestitev poti na stroju, kjer teče demon, kar je natanko ista vrsta spremembe, kot bi jo naredili z ip route in nato pozabili.
Distribucija zahteva, da se pot potisne s pushom, push pa zahteva, da jo odjemalec potegne. Odjemalec, zagnan z onemogočenimi potegnjenimi možnostmi, ponudbo popolnoma prezre. Preverite oba konca tega rokovanja, preden prepišete strežniško datoteko, ker se dnevnik strežnika ne bo pritoževal: z njegove strani je bila ponudba poslana. Sprejeta pot prav tako začne veljati šele ob naslednji povezavi, nikoli v seji, v kateri ste že.
Ko obe operaciji vidite kot ločeni, napaka preneha biti skrivnostna: strežnik doseže predpono, odjemalec ne, in obe trditvi sta resnični hkrati.
Datoteke za posamezne odjemalce in identiteta, s katero se ujemajo
Datoteka, specifična za odjemalca, se imenuje po identiteti, ki jo je strežnik avtenticiral, kar je privzeto splošno ime potrdila. Prijazno ime povezave v namiznem odjemalcu ni ta vrednost, in neujemanje ustvari datoteko, ki se nikoli ne prebere.
Preverite imenik, ki ga strežnik dejansko uporablja, nato potrdite, da ime datoteke natančno ustreza avtenticirani identiteti, vključno z velikimi in malimi črkami.
grep -n 'client-config-dir' /etc/openvpn/server/server.conf
ls -l /etc/openvpn/ccd/Znotraj te datoteke je treba pot še vedno potisniti s pushom, ker je kontekst za posameznega odjemalca niz možnosti, ki se uporabijo za sejo tega odjemalca, ne lokalna usmerjevalna tabela. Gola pot tam ima enako težavo kot gola pot v globalni datoteki.
Lastna datoteka odjemalca in orodje, ki jo ima v lasti
Pot, nameščena v konfiguracijo odjemalca, se namesti, ko se ta odjemalec poveže, in odstrani, ko se odklopi, kar je pravi življenjski cikel za statični cilj.
Če ima profil v lasti upravitelj omrežja, lahko te možnosti enkrat uvozi in nato obdrži svojo kopijo. Poznejše urejanje prenesene datoteke ne spremeni ničesar, kar je pogost vzrok za "pot je tam, a ne velja".
Preverite aktivni profil, ne datoteke, ki ste jo prenesli, in preverite uvožene nastavitve, ki jih prikazuje upravitelj. Nato se povežite in vprašajte sistem, katero pot uporablja določen naslov, namesto da bi domnevali, da je tunel zmagal, ker je pot obstajala v besedilni datoteki.
Preverite na odjemalcu, nato preverite povratno pot
Vprašajte lastno usmerjevalno tabelo odjemalca za cilj, ne strežnikovo. Iskanje enega gostitelja znotraj predpone zadostuje, da pokaže vmesnik in naslednji skok, ki bosta uporabljena.
ip route get 10.60.0.10Če iskanje kaže na tunel, je distribucija delovala in preostala težava je drugje. Če kaže na privzeti prehod, pot ni bila nameščena, filtrirala jo je možnost na strani odjemalca ali pripada profilu, ki ga odjemalec ne uporablja.
Predpostavite, da je distribucija delovala, in vseeno nič ne odgovori: takrat preverite posredovanje na prehodu, povratno pot na drugi strani in morebitno požarno prepoved med njima. Pot izbere pot, ne daje dostopa.