Kvar høyrer ruta heime i OpenVPN: hjå klienten eller tenaren?
Ei naken rute i tenarkonfigurasjonen endrar tenaren, ikkje klienten. Vel klientfila, ein global push eller ein push for éin klient, og kontroller kva som kom fram.
Du legg til route 10.60.0.0 255.255.255.0 i tenarkonfigurasjonen, startar på nytt, koplar til ein berbar PC igjen, og subnettet er framleis utilgjengeleg frå den berbare PC-en. Linja vart godteken, tenesta starta reint, og ingenting i loggen ser gale ut. Det som skjedde, er at ruta vart installert på maskinen du redigerte: gatewayen trur no at han kan nå det prefikset, medan klienten aldri fekk vite noko. Plasseringa er heile spørsmålet, og det er fire stader den same linja kan bu.
Dei fire stadene og kven som mottek kvart av dei
Ei rute kan leggjast til av konfigurasjonen til klienten sjølv, tilbydast alle klientar gjennom ein global push, tilbydast éin klient gjennom ei klientspesifikk fil, eller skrivast inn i tenaren sitt eige rutekontekst.
Desse fire tilfella brukar nesten identisk syntaks og gir heilt ulike resultat. Dei tre første påverkar kva ein klient sender inn i tunnelen; det fjerde påverkar korleis tenaren når eit nettverk, noko som er nyttig når tenaren sjølv treng ein veg og skadeleg når det vert forveksla med distribusjon.
Avgjer kva av dei fire du vil ha før du skriv linja, og stadfest deretter mottakaren.
| 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 |
Kvifor den nakne tenarruta overraskar folk
Tenarkonfigurasjonen er den første staden administratorar ser, og eit rutedirektiv der vert lese som ei utsegn om VPN-nettverket. Det er det ikkje. OpenVPN handsamar det som ein lokal ruteinstallasjon på maskinen som køyrer daemonen, som er nøyaktig same type endring du ville gjort med ip route og deretter gløymt.
Distribusjon krev at ruta vert pusha, og push krev at klienten trekkjer ho. Ein klient som startar med trekte alternativ deaktiverte, ignorerer tilbodet heilt. Kontroller begge endar av den handtrykkinga før du skriv om tenarfila, fordi tenarloggen vil ikkje klage: frå hans side vart tilbodet sendt. Ei godteken rute trer også i kraft først ved neste tilkopling, aldri i økta du allereie er i.
Når du ser dei to som separate operasjonar, sluttar feilen å vere mystisk: tenaren når prefikset, klienten ikkje, og båe utsegnene er sanne samstundes.
Klientspesifikke filer og identiteten dei samsvarar med
Ei klientspesifikk fil vert namngjeven etter identiteten tenaren autentiserte, som som standard er det vanlege namnet på sertifikatet. Eit venleg tilkoplingsnamn i ein skrivebordsklient er ikkje den verdien, og eit avvik gir ei fil som aldri vert lesen.
Kontroller katalogen tenaren faktisk brukar, og stadfest deretter at filnamnet samsvarar nøyaktig med den autentiserte identiteten, inkludert store og små bokstavar.
grep -n 'client-config-dir' /etc/openvpn/server/server.conf
ls -l /etc/openvpn/ccd/Inne i den fila må ruta framleis pushast, fordi den klientspesifikke konteksten er eit sett alternativ som vert brukt på økta til den klienten, ikkje ein lokal rutetabell. Ei naken rute der har same problem som ei naken rute i den globale fila.
Klienten si eiga fil og verktøyet som eig ho
Ei rute som vert lagd i konfigurasjonen til klienten, vert installert når den klienten koplar til, og fjerna når han koplar frå, som er rett livssyklus for ein statisk destinasjon.
Viss ein nettverkshandsamar eig profilen, kan han importere desse alternativa éin gong og deretter halde si eiga kopi. Å redigere den nedlasta fila etterpå endrar ingenting, som er ein vanleg årsak til "ruta er der, men gjeld ikkje".
Kontroller den aktive profilen i staden for fila du lasta ned, og kontroller dei importerte innstillingane handsamaren viser. Kopla deretter til og spør systemet kva veg ein bestemd adresse brukar, i staden for å anta at tunnelen vann fordi ruta fanst i ei tekstfil.
Stadfest på klienten, og kontroller deretter returvegen
Spør rutetabellen til klienten sjølv om destinasjonen, ikkje tenaren sin. Eit oppslag på éin vert inne i prefikset er nok til å vise grensesnittet og neste hopp som vil verte brukt.
ip route get 10.60.0.10Viss oppslaget peikar på tunnelen, verka distribusjonen, og det gjenverande problemet er ein annan stad. Viss det peikar på standardgatewayen, vart ruta ikkje installert, vart filtrert av eit klientalternativ, eller høyrer til ein profil klienten ikkje brukar.
Anta at distribusjonen verka, og at ingenting svarar likevel: kontroller då videresending på gatewayen, returruta til den andre sida og ein eventuell brannmur mellom dei. Ei rute vel ein veg, ho gir ikkje tilgang.