Unde îi este locul rutei în OpenVPN: la client sau la server?
O rută goală în configurația serverului schimbă serverul, nu clientul. Alegeți fișierul clientului, un push global sau un push pentru un singur client și verificați ce a ajuns.
Adăugați route 10.60.0.0 255.255.255.0 în configurația serverului, reporniți, reconectați un laptop și subrețeaua este încă inaccesibilă de pe acel laptop. Linia a fost acceptată, serviciul a pornit curat și nimic din jurnal nu pare greșit. Ce s-a întâmplat este că ruta a fost instalată pe mașina pe care ați editat-o: gateway-ul crede acum că poate ajunge la acel prefix, în timp ce clientului nu i s-a spus nimic. Plasarea este toată întrebarea și există patru locuri în care aceeași linie poate trăi.
Cele patru locuri și cine primește fiecare
O rută poate fi adăugată de configurația clientului însuși, oferită fiecărui client printr-un push global, oferită unui singur client printr-un fișier specific clientului sau scrisă în contextul de rutare al serverului însuși.
Aceste patru cazuri folosesc o sintaxă aproape identică și produc rezultate complet diferite. Primele trei afectează ce trimite un client în tunel; al patrulea afectează modul în care serverul ajunge la o rețea, ceea ce este util când serverul însuși are nevoie de o cale și dăunător când este confundat cu distribuția.
Decideți pe care dintre cele patru îl doriți înainte de a scrie linia, apoi confirmați destinatarul.
| 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 |
De ce ruta goală de pe server surprinde lumea
Configurația serverului este primul loc în care se uită administratorii, iar o directivă de rută de acolo se citește ca o afirmație despre rețeaua VPN. Nu este. OpenVPN o tratează ca o instalare locală de rută pe mașina care rulează demonul, exact același tip de modificare pe care ați face-o cu ip route și apoi ați uita-o.
Distribuția cere ca ruta să fie trimisă prin push, iar push-ul cere ca clientul să o tragă. Un client pornit cu opțiunile trase dezactivate ignoră complet oferta. Verificați ambele capete ale acelei strângeri de mână înainte de a rescrie fișierul serverului, pentru că jurnalul serverului nu se va plânge: din partea lui, oferta a fost trimisă. O rută acceptată intră în vigoare doar la următoarea conectare, niciodată în sesiunea în care vă aflați deja.
Odată ce vedeți cele două ca operațiuni separate, defecțiunea nu mai este misterioasă: serverul ajunge la prefix, clientul nu, iar ambele afirmații sunt adevărate în același timp.
Fișiere per client și identitatea cu care se potrivesc
Un fișier specific clientului este denumit după identitatea pe care serverul a autentificat-o, care implicit este numele comun al certificatului. Un nume de conexiune prietenos într-un client desktop nu este acea valoare, iar o nepotrivire produce un fișier care nu este niciodată citit.
Verificați directorul pe care serverul îl folosește efectiv, apoi confirmați că numele fișierului corespunde exact identității autentificate, inclusiv majusculele și minusculele.
grep -n 'client-config-dir' /etc/openvpn/server/server.conf
ls -l /etc/openvpn/ccd/În acel fișier ruta tot trebuie trimisă prin push, pentru că contextul per client este un set de opțiuni aplicate sesiunii acelui client, nu un tabel de rutare local. O rută goală acolo are aceeași problemă ca o rută goală în fișierul global.
Fișierul propriu al clientului și instrumentul care îl deține
O rută plasată în configurația clientului este instalată când acel client se conectează și eliminată când se deconectează, ceea ce este ciclul de viață corect pentru o destinație statică.
Dacă un manager de rețea deține profilul, poate importa acele opțiuni o dată și apoi să păstreze propria copie. Editarea ulterioară a fișierului descărcat nu schimbă nimic, ceea ce este o cauză frecventă a "ruta este acolo, dar nu se aplică".
Verificați profilul activ, nu fișierul descărcat, și verificați setările importate pe care le afișează managerul. Apoi conectați-vă și întrebați sistemul ce cale folosește o anumită adresă, în loc să presupuneți că tunelul a câștigat pentru că ruta exista într-un fișier text.
Verificați pe client, apoi verificați calea de întoarcere
Întrebați tabelul de rutare propriu al clientului despre destinație, nu pe cel al serverului. O căutare pentru un singur host din interiorul prefixului este suficientă pentru a arăta interfața și următorul salt care vor fi folosite.
ip route get 10.60.0.10Dacă căutarea indică tunelul, distribuția a funcționat și problema rămasă este în altă parte. Dacă indică gateway-ul implicit, ruta nu a fost instalată, a fost filtrată de o opțiune din partea clientului sau aparține unui profil pe care clientul nu îl folosește.
Presupuneți că distribuția a funcționat și totuși nimic nu răspunde: atunci verificați redirecționarea pe gateway, ruta de întoarcere a celeilalte părți și orice firewall dintre ele. O rută alege o cale, ea nu acordă acces.