Wêr heart de rûte yn OpenVPN: by de klant of by de tsjinner?
In keale rûte yn 'e tsjinnerkonfiguraasje feroaret de tsjinner, net de klant. Kies it klantbestân, in globale push of in push foar ien klant, en kontrolearje wat oankaam.
Jo foegje route 10.60.0.0 255.255.255.0 ta oan 'e tsjinnerkonfiguraasje, starte opnij, ferbine in laptop opnij, en it subnet is noch altyd net berikber fanôf dy laptop. De rigel waard akseptearre, de tsjinst starte skjin, en neat yn it log liket ferkeard. Wat barde is dat de rûte ynstallearre waard op 'e masine dy't jo bewurke hawwe: de gateway tinkt no dat it dat foarheaksel berikke kin, wylst de klant neat ferteld waard. Plakking is de hiele fraach, en der binne fjouwer plakken wêr't deselde rigel libje kin.
De fjouwer plakken en wa't elk ûntfangt
In rûte kin tafoege wurde troch de eigen konfiguraasje fan 'e klant, oanbean wurde oan elke klant fia in globale push, oanbean wurde oan ien klant fia in klantspekifyk bestân, of skreaun wurde yn 'e eigen routingkontekst fan 'e tsjinner.
Dy fjouwer gefallen brûke hast deselde syntaksis en jouwe folslein ferskillende resultaten. De earste trije beynfloedzje wat in klant de tunnel yn stjoert; de fjirde beynfloedet hoe't de tsjinner in netwurk berikt, wat nuttich is as de tsjinner sels in paad nedich hat en skealik as it foar distribúsje oansjoen wurdt.
Beslis hokker fan 'e fjouwer jo wolle foardat jo de rigel skriuwe, en befêstigje dan de ûntfanger.
| 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 |
Wêrom't de keale tsjinnerrûte minsken ferrast
De tsjinnerkonfiguraasje is wêr't behearders earst sjogge, en in rûte-opdracht dêr liedt as in útspraak oer it VPN-netwurk. Dat is it net. OpenVPN behannelet it as in lokale rûte-ynstallaasje op 'e masine dy't de daemon draait, krekt deselde soarte feroaring dy't jo mei ip route meitsje soene en dan ferjitte.
Distribúsje freget dat de rûte pusht wurdt, en push freget dat de klant lûkt. In klant dy't start is mei útskeakele lutsen opsjes negearret it oanbod folslein. Kontrolearje beide einen fan dy hânskudding foardat jo it tsjinnerbestân oerskriuwe, want it tsjinnerlog sil net kleie: fan syn kant waard it oanbod stjoerd. In akseptearre rûte jildt ek pas by de folgjende ferbining, nea yn 'e sesje wêryn't jo al binne.
Sa gau as jo de twa as aparte operaasjes sjogge, hâldt de flater op mysterieus te wêzen: de tsjinner berikt it foarheaksel, de klant net, en beide bewearings binne tagelyk wier.
Klantspekifike bestannen en de identiteit dêr't se by passe
In klantspekifyk bestân wurdt neamd nei de identiteit dy't de tsjinner autentisearre, wat standert de algemiene namme fan it sertifikaat is. In freonlike ferbiningsnamme yn in desktopklant is dy wearde net, en in mismatch produsearret in bestân dat nea lêzen wurdt.
Kontrolearje de map dy't de tsjinner eins brûkt, en befêstigje dan dat de bestânsnamme krekt oerienkomt mei de autentisearre identiteit, ynklusyf haadletters en lytse letters.
grep -n 'client-config-dir' /etc/openvpn/server/server.conf
ls -l /etc/openvpn/ccd/Yn dat bestân moat de rûte noch hieltyd pusht wurde, want de klantspekifike kontekst is in set opsjes dy't op 'e sesje fan dy klant tapast wurde, net in lokale routingtabel. In keale rûte dêr hat itselde probleem as in keale rûte yn it globale bestân.
It eigen bestân fan 'e klant en it ark dat it besit
In rûte dy't yn 'e konfiguraasje fan 'e klant pleatst is, wurdt ynstallearre as dy klant ferbindt en fuorthelle as er loskeppele, wat de juste libbenssyklus is foar in statyske bestimming.
As in netwurkbehearder it profyl besit, kin it dy opsjes ien kear ymportearje en dêrnei syn eigen kopy hâlde. It downloadde bestân letter bewurkje feroaret neat, wat in faak foarkommende oarsaak is fan "de rûte is der mar jildt net".
Kontrolearje it aktive profyl ynstee fan it bestân dat jo downloaded hawwe, en kontrolearje de ymportearre ynstellingen dy't de behearder sjen lit. Ferbine dan en freegje it systeem hokker paad in bepaald adres brûkt, ynstee fan oan te nimmen dat de tunnel wûn hat om't de rûte yn in tekstbestân stie.
Kontrolearje op 'e klant, en kontrolearje dan it werompaad
Freegje de eigen routingtabel fan 'e klant om de bestimming, net dy fan 'e tsjinner. In syktocht nei ien host yn it foarheaksel is genôch om de ynterface en de folgjende hop te toanen dy't brûkt wurde.
ip route get 10.60.0.10As de syktocht nei de tunnel wiist, hat distribúsje wurke en is it oerbleaune probleem earne oars. As it nei de standertgateway wiist, waard de rûte net ynstallearre, waard it filtere troch in opsje oan 'e klantkant, of heart it by in profyl dat de klant net brûkt.
Nim oan dat distribúsje wurke hat en dat noch neat antwurdet: kontrolearje dan trochstjoering op 'e gateway, it werompaad fan 'e oare kant en elke firewall dêrtusken. In rûte kiest in paad, it jout gjin tagong.