Kie la vojo apartenas en OpenVPN: ĉe la kliento aŭ ĉe la servilo?
Nuda vojo en la servila agordo ŝanĝas la servilon, ne la klienton. Elektu la klientan dosieron, ĝeneralan push aŭ push por unu kliento, kaj kontrolu, kio alvenis.
Vi aldonas route 10.60.0.0 255.255.255.0 al la servila agordo, restartigas, rekonektas tekkomputilon, kaj la subreto ankoraŭ neatingeblas de tiu tekkomputilo. La linio estis akceptita, la servo ekfunkciis pure, kaj nenio en la protokolo ŝajnas malĝusta. Kio okazis estas, ke la vojo estis instalita sur la maŝino, kiun vi redaktis: la pordego nun kredas, ke ĝi povas atingi tiun prefikson, dum la kliento neniam sciis ion. La loko estas la tuta demando, kaj ekzistas kvar lokoj, kie la sama linio povas loĝi.
La kvar lokoj kaj kiu ricevas ĉiun
Vojon eblas aldoni per la propra agordo de la kliento, proponi al ĉiu kliento per ĝenerala push, proponi al unu kliento per klientospecifa dosiero, aŭ skribi en la propran enkursigan kuntekston de la servilo.
Tiuj kvar kazoj uzas preskaŭ identan sintakson kaj produktas tute malsamajn rezultojn. La unuaj tri influas tion, kion kliento sendas en la tunelon; la kvara influas kiel la servilo atingas reton, kio utilas kiam la servilo mem bezonas vojon kaj malutilas kiam oni konfuzas ĝin kun disdonado.
Decidu, kiun el la kvar vi volas, antaŭ ol skribi la linion, poste konfirmu la ricevanton.
| 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 |
Kial la nuda servila vojo surprizas homojn
La servila agordo estas la unua loko, kiun administrantoj rigardas, kaj voja direktivo tie legeblas kiel aserto pri la VPN-reto. Ĝi ne estas tio. OpenVPN traktas ĝin kiel lokan vojinstalon sur la maŝino, kie funkcias la demono, kio estas ĝuste la sama speco de ŝanĝo, kiun vi farus per ip route kaj poste forgesus.
Disdonado postulas, ke la vojo estu puŝita, kaj puŝado postulas, ke la kliento tiru. Kliento lanĉita kun malŝaltitaj tiritaj opcioj tute ignoras la proponon. Kontrolu ambaŭ finojn de tiu manpremo antaŭ ol reskribi la servilan dosieron, ĉar la servila protokolo ne plendos: de ĝia flanko la propono estis sendita. Akceptita vojo ankaŭ validas nur ĉe la sekva konekto, neniam en la sesio, en kiu vi jam troviĝas.
Fojo, kiam vi vidos la du kiel apartajn operaciojn, la malsukceso ĉesos esti mistera: la servilo atingas la prefikson, la kliento ne, kaj ambaŭ asertoj veras samtempe.
Klientospecifaj dosieroj kaj la identeco, kiun ili kongruas
Klientospecifa dosiero nomiĝas laŭ la identeco, kiun la servilo aŭtentikigis, kiu defaŭlte estas la komuna nomo de la atestilo. Amika konekta nomo en surtabla kliento ne estas tiu valoro, kaj malkongruo produktas dosieron, kiu neniam estas legata.
Kontrolu la dosierujon, kiun la servilo efektive uzas, poste konfirmu, ke la dosiernomo precize kongruas kun la aŭtentikigita identeco, inkluzive de uskleco.
grep -n 'client-config-dir' /etc/openvpn/server/server.conf
ls -l /etc/openvpn/ccd/Ene de tiu dosiero la vojo ankoraŭ devas esti puŝita, ĉar la klienta kunteksto estas aro de opcioj aplikataj al la sesio de tiu kliento, ne loka enkursiga tabelo. Nuda vojo tie havas la saman problemon kiel nuda vojo en la ĝenerala dosiero.
La propra dosiero de la kliento kaj la ilo, kiu posedas ĝin
Vojo metita en la klientan agordon estas instalata, kiam tiu kliento konektiĝas, kaj forigata, kiam ĝi malkonektiĝas, kio estas la ĝusta vivciklo por statika celo.
Se retadministranto posedas la profilon, ĝi povas importi tiujn opciojn unufoje kaj poste teni sian propran kopion. Redakti la elŝutitan dosieron poste ŝanĝas nenion, kio estas ofta kaŭzo de "la vojo estas tie sed ne validas".
Kontrolu la aktivan profilon anstataŭ la dosieron, kiun vi elŝutis, kaj kontrolu la importitajn agordojn, kiujn la administranto montras. Poste konektiĝu kaj demandu al la sistemo, kiun vojon specifa adreso uzas, anstataŭ supozi, ke la tunelo venkis ĉar la vojo ekzistis en teksta dosiero.
Kontrolu ĉe la kliento, poste kontrolu la revenan vojon
Demandu la propran enkursigan tabelon de la kliento pri la celo, ne tiun de la servilo. Serĉo por unu gastiganto ene de la prefikso sufiĉas por montri la interfacon kaj la sekvan salteton, kiuj estos uzataj.
ip route get 10.60.0.10Se la serĉo montras al la tunelo, disdonado funkciis kaj la cetera problemo estas aliloke. Se ĝi montras al la defaŭlta pordego, la vojo ne estis instalita, estis filtrita de klientflanka opcio, aŭ apartenas al profilo, kiun la kliento ne uzas.
Supozu, ke disdonado funkciis kaj tamen nenio respondas: tiam kontrolu plusendadon sur la pordego, la revenan vojon de la alia flanko, kaj ajnan fajroŝirmilon inter ili. Vojo elektas vojon, ĝi ne donas aliron.