Hvor hører ruten hjemme i OpenVPN: hos klienten eller serveren?
En bar rute i serverkonfigurasjonen endrer serveren, ikke klienten. Velg klientfilen, en global push eller en push for én klient, og kontroller hva som kom frem.
Du legger til route 10.60.0.0 255.255.255.0 i serverkonfigurasjonen, starter på nytt, kobler til en laptop igjen, og subnettet er fortsatt utilgjengelig fra den laptopen. Linjen ble godtatt, tjenesten startet rent, og ingenting i loggen ser galt ut. Det som skjedde, er at ruten ble installert på maskinen du redigerte: gatewayen tror nå at den kan nå det prefikset, mens klienten aldri fikk vite noe. Plasseringen er hele spørsmålet, og det er fire steder den samme linjen kan bo.
De fire stedene og hvem som mottar hvert av dem
En rute kan legges til av klientens egen konfigurasjon, tilbys alle klienter gjennom en global push, tilbys én klient gjennom en klientspesifikk fil, eller skrives inn i serverens eget rutekontekst.
Disse fire tilfellene bruker nesten identisk syntaks og gir helt forskjellige resultater. De tre første påvirker hva en klient sender inn i tunnelen; det fjerde påvirker hvordan serveren når et nettverk, noe som er nyttig når serveren selv trenger en vei og skadelig når det forveksles med distribusjon.
Bestem hvilken av de fire du vil ha før du skriver linjen, og bekreft deretter mottakeren.
| 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 |
Hvorfor den bare serverruten overrasker folk
Serverkonfigurasjonen er det første stedet administratorer ser, og et rutedirektiv der leses som en uttalelse om VPN-nettverket. Det er det ikke. OpenVPN behandler det som en lokal ruteinstallasjon på maskinen som kjører daemonen, som er nøyaktig samme type endring du ville gjort med ip route og deretter glemt.
Distribusjon krever at ruten pushes, og push krever at klienten trekker den. En klient som startes med trukket alternativer deaktivert, ignorerer tilbudet helt. Kontroller begge ender av det håndtrykket før du skriver om serverfilen, fordi serverloggen ikke vil klage: fra dens side ble tilbudet sendt. En godtatt rute trer også i kraft først ved neste tilkobling, aldri i økten du allerede er i.
Når du ser de to som separate operasjoner, slutter feilen å være mystisk: serveren når prefikset, klienten ikke, og begge utsagnene er sanne samtidig.
Klientspesifikke filer og identiteten de samsvarer med
En klientspesifikk fil navngis etter identiteten serveren autentiserte, som som standard er sertifikatets vanlige navn. Et vennlig tilkoblingsnavn i en skrivebordsklient er ikke den verdien, og et avvik gir en fil som aldri leses.
Kontroller katalogen serveren faktisk bruker, og bekreft deretter at filnavnet samsvarer nøyaktig med den autentiserte identiteten, inkludert store og små bokstaver.
grep -n 'client-config-dir' /etc/openvpn/server/server.conf
ls -l /etc/openvpn/ccd/Inne i den filen må ruten fortsatt pushes, fordi den klientspesifikke konteksten er et sett alternativer som brukes på den klientens økt, ikke en lokal rutetabell. En bar rute der har samme problem som en bar rute i den globale filen.
Klientens egen fil og verktøyet som eier den
En rute som legges i klientens konfigurasjon, installeres når den klienten kobler til, og fjernes når den kobler fra, som er riktig livssyklus for en statisk destinasjon.
Hvis en nettverksbehandler eier profilen, kan den importere disse alternativene én gang og deretter beholde sin egen kopi. Å redigere den nedlastede filen etterpå endrer ingenting, som er en vanlig årsak til "ruten er der, men gjelder ikke".
Kontroller den aktive profilen i stedet for filen du lastet ned, og kontroller de importerte innstillingene behandleren viser. Koble deretter til og spør systemet hvilken vei en bestemt adresse bruker, i stedet for å anta at tunnelen vant fordi ruten fantes i en tekstfil.
Bekreft på klienten, og kontroller deretter returveien
Spør klientens egen rutetabell om destinasjonen, ikke serverens. Et oppslag på én vert inne i prefikset er nok til å vise grensesnittet og neste hopp som vil bli brukt.
ip route get 10.60.0.10Hvis oppslaget peker på tunnelen, virket distribusjonen, og det gjenværende problemet er et annet sted. Hvis det peker på standardgatewayen, ble ruten ikke installert, ble filtrert av et klientalternativ, eller tilhører en profil klienten ikke bruker.
Anta at distribusjonen virket, og at ingenting svarer likevel: kontroller da videresending på gatewayen, den andre sidens returrute og en eventuell brannmur mellom dem. En rute velger en vei, den gir ikke tilgang.