Waar hoort de route in OpenVPN: bij de client of bij de server?
Een kale route in de serverconfiguratie verandert de server, niet de client. Kies het clientbestand, een globale push of een push per client, en controleer wat er aankwam.
Je voegt route 10.60.0.0 255.255.255.0 toe aan de serverconfiguratie, herstart, verbindt een laptop opnieuw, en het subnet is vanaf die laptop nog steeds onbereikbaar. De regel werd geaccepteerd, de dienst startte schoon en niets in het log ziet er verkeerd uit. Wat er gebeurde, is dat de route werd geïnstalleerd op de machine die je hebt bewerkt: de gateway denkt nu dat hij dat prefix kan bereiken, terwijl de client niets is verteld. De plaatsing is de hele vraag, en er zijn vier plekken waar dezelfde regel kan leven.
De vier plekken en wie elk ervan ontvangt
Een route kan worden toegevoegd door de configuratie van de client zelf, aan elke client worden aangeboden via een globale push, aan één client worden aangeboden via een cliëntspecifiek bestand, of in de eigen routeringscontext van de server worden geschreven.
Die vier gevallen gebruiken bijna dezelfde syntaxis en leveren totaal verschillende resultaten op. De eerste drie beïnvloeden wat een client de tunnel in stuurt; de vierde beïnvloedt hoe de server een netwerk bereikt, wat nuttig is wanneer de server zelf een pad nodig heeft en schadelijk wanneer het voor distributie wordt aangezien.
Bepaal welke van de vier je wilt voordat je de regel schrijft, en bevestig daarna de 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 de kale serverroute mensen verrast
De serverconfiguratie is de eerste plek waar beheerders kijken, en een routedirectief daar leest als een uitspraak over het VPN-netwerk. Dat is het niet. OpenVPN behandelt het als een lokale route-installatie op de machine waarop de daemon draait, precies hetzelfde soort wijziging die je met ip route zou maken en daarna zou vergeten.
Distributie vereist dat de route wordt gepusht, en pushen vereist dat de client hem trekt. Een client die is gestart met getrokken opties uitgeschakeld, negeert het aanbod volledig. Controleer beide kanten van die handdruk voordat je het serverbestand herschrijft, want het serverlog zal niet klagen: van zijn kant is het aanbod verzonden. Een geaccepteerde route gaat ook pas bij de volgende verbinding in, nooit in de sessie waarin je al zit.
Zodra je de twee als afzonderlijke bewerkingen ziet, is de fout niet langer raadselachtig: de server bereikt het prefix, de client niet, en beide uitspraken zijn tegelijk waar.
Cliëntspecifieke bestanden en de identiteit waarmee ze overeenkomen
Een cliëntspecifiek bestand wordt vernoemd naar de identiteit die de server heeft geauthenticeerd, standaard de common name van het certificaat. Een vriendelijke verbindingsnaam in een desktopclient is die waarde niet, en een mismatch levert een bestand op dat nooit wordt gelezen.
Controleer de map die de server werkelijk gebruikt, en bevestig daarna dat de bestandsnaam exact overeenkomt met de geauthenticeerde identiteit, inclusief hoofdletters en kleine letters.
grep -n 'client-config-dir' /etc/openvpn/server/server.conf
ls -l /etc/openvpn/ccd/Binnen dat bestand moet de route nog steeds worden gepusht, omdat de context per client een set opties is die op de sessie van die client wordt toegepast, niet een lokale routeringstabel. Een kale route daar heeft hetzelfde probleem als een kale route in het globale bestand.
Het eigen bestand van de client en het hulpprogramma dat het beheert
Een route in de configuratie van de client wordt geïnstalleerd wanneer die client verbindt en verwijderd wanneer hij loskoppelt, wat de juiste levenscyclus is voor een statische bestemming.
Als een netwerkbeheerder het profiel beheert, kan hij die opties één keer importeren en daarna zijn eigen kopie bewaren. Het gedownloade bestand later bewerken verandert niets, wat een veelvoorkomende oorzaak is van "de route staat er wel maar geldt niet".
Controleer het actieve profiel in plaats van het bestand dat je hebt gedownload, en controleer de geïmporteerde instellingen die de beheerder toont. Verbind daarna en vraag het systeem welk pad een bepaald adres gebruikt, in plaats van aan te nemen dat de tunnel heeft gewonnen omdat de route in een tekstbestand stond.
Controleer op de client en daarna het retourpad
Vraag de eigen routeringstabel van de client naar de bestemming, niet die van de server. Een opzoeking voor één host binnen het prefix is genoeg om de interface en de volgende hop te tonen die worden gebruikt.
ip route get 10.60.0.10Als de opzoeking naar de tunnel wijst, werkte de distributie en zit het resterende probleem elders. Als die naar de standaardgateway wijst, is de route niet geïnstalleerd, gefilterd door een optie aan de clientkant, of hoort hij bij een profiel dat de client niet gebruikt.
Stel dat de distributie werkte en er nog steeds niets reageert: controleer dan doorsturen op de gateway, de retourroute van de andere kant en elke firewall daartussen. Een route kiest een pad, hij verleent geen toegang.