Waar hoort die roete in OpenVPN tuis: by die kliënt of by die bediener?
’n Kaal roete in die bediener se konfigurasie verander die bediener, nie die kliënt nie. Kies die kliëntlêer, ’n globale push of ’n push per kliënt, en kontroleer wat aangekom het.
Jy voeg route 10.60.0.0 255.255.255.0 by die bediener se konfigurasie, herbegin, verbind ’n skootrekenaar weer, en die subnet is steeds onbereikbaar vanaf daardie skootrekenaar. Die reël is aanvaar, die diens het skoon begin, en niks in die log lyk verkeerd nie. Wat gebeur het, is dat die roete op die masjien wat jy gewysig het, geïnstalleer is: die gateway glo nou dat dit daardie voorvoegsel kan bereik, terwyl die kliënt niks vertel is nie. Plasing is die hele vraag, en daar is vier plekke waar dieselfde reël kan woon.
Die vier plekke en wie elkeen ontvang
’n Roete kan deur die kliënt se eie konfigurasie bygevoeg word, aan elke kliënt gebied word deur ’n globale push, aan een kliënt gebied word deur ’n kliëntspesifieke lêer, of in die bediener se eie routeringskonteks geskryf word.
Daardie vier gevalle gebruik byna identiese sintaksis en lewer heeltemal verskillende resultate. Die eerste drie beïnvloed wat ’n kliënt in die tonnel stuur; die vierde beïnvloed hoe die bediener ’n netwerk bereik, wat nuttig is wanneer die bediener self ’n pad nodig het en skadelik is wanneer dit vir verspreiding aangesien word.
Bepaal watter een van die vier jy wil hê voordat jy die reël skryf, en bevestig dan die ontvanger.
| 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 |
Waarom die kaal bedienerroete mense verras
Die bediener se konfigurasie is waar administrateurs eerste kyk, en ’n roete-opdrag daar lees soos ’n stelling oor die VPN-netwerk. Dit is nie. OpenVPN behandel dit as ’n plaaslike roete-installasie op die masjien wat die daemon laat loop, presies dieselfde soort verandering wat jy met ip route sou maak en dan vergeet.
Verspreiding vereis dat die roete gestoot word, en stoot vereis dat die kliënt trek. ’n Kliënt wat begin is met getrekte opsies gedeaktiveer, ignoreer die aanbod heeltemal. Kontroleer beide kante van daardie handdruk voordat jy die bedienerlêer herskryf, want die bediener se log sal nie kla nie: van sy kant is die aanbod gestuur. ’n Aanvaarde roete land ook eers by die volgende verbinding, nooit in die sessie waarin jy reeds is nie.
Sodra jy die twee as aparte bewerkings sien, hou die fout op om raaiselagtig te wees: die bediener kan die voorvoegsel bereik, die kliënt nie, en albei stellings is terselfdertyd waar.
Lêers per kliënt en die identiteit wat hulle pas
’n Kliëntspesifieke lêer word vernoem na die identiteit wat die bediener geauthentiseer het, wat by verstek die sertifikaat se algemene naam is. ’n Vriendelike verbindingsnaam in ’n lessenaarkliënt is nie daardie waarde nie, en ’n wanpassing lewer ’n lêer wat nooit gelees word nie.
Kontroleer die gids wat die bediener werklik gebruik, en bevestig dan dat die lêernaam presies met die geauthentiseerde identiteit ooreenstem, insluitend hoofletters.
grep -n 'client-config-dir' /etc/openvpn/server/server.conf
ls -l /etc/openvpn/ccd/Binne daardie lêer moet die roete steeds gestoot word, want die konteks per kliënt is ’n stel opsies wat op daardie kliënt se sessie toegepas word, nie ’n plaaslike routeringstabel nie. ’n Kaal roete daar het dieselfde probleem as ’n kaal roete in die globale lêer.
Die kliënt se eie lêer en die instrument wat dit besit
’n Roete wat in die kliënt se konfigurasie geplaas is, word geïnstalleer wanneer daardie kliënt verbind en verwyder wanneer dit ontkoppel, wat die regte lewensiklus vir ’n statiese bestemming is.
As ’n netwerkbestuurder die profiel besit, kan dit daardie opsies een keer invoer en dan sy eie kopie hou. Om die afgelaaide lêer daarna te wysig, verander niks, wat ’n algemene oorsaak is van "die roete is daar maar geld nie".
Kontroleer die aktiewe profiel eerder as die lêer wat jy afgelaai het, en kontroleer die ingevoerde instellings wat die bestuurder wys. Verbind dan en vra die stelsel watter pad ’n spesifieke adres gebruik, eerder as om te aanvaar dat die tonnel gewen het omdat die roete in ’n tekslêer bestaan het.
Verifieer op die kliënt en kontroleer dan die terugpad
Vra die kliënt se eie routeringstabel vir die bestemming, nie die bediener s’n nie. ’n Opsoek na ’n enkele gasheer binne die voorvoegsel is genoeg om die koppelvlak en volgende hop te wys wat gebruik sal word.
ip route get 10.60.0.10As die opsoek na die tonnel wys, het verspreiding gewerk en is die oorblywende probleem elders. As dit na die verstekgateway wys, is die roete nie geïnstalleer nie, is dit deur ’n kliëntkant-opsie gefiltreer, of behoort dit aan ’n profiel wat die kliënt nie gebruik nie.
Aanvaar dat verspreiding gewerk het en reageer steeds niks: kontroleer dan aanstuur op die gateway, die ander kant se terugroete, en enige vuurmuur tussen hulle. ’n Roete kies ’n pad, dit verleen nie toegang nie.