Var hör rutten hemma i OpenVPN: hos klienten eller servern?
En bar rutt i serverkonfigurationen ändrar servern, inte klienten. Välj klientfilen, en global push eller en push för en enda klient, och kontrollera vad som kom fram.
Du lägger till route 10.60.0.0 255.255.255.0 i serverkonfigurationen, startar om, ansluter en laptop igen, och subnätet är fortfarande oåtkomligt från den laptopen. Raden accepterades, tjänsten startade rent och inget i loggen ser fel ut. Det som hände är att rutten installerades på maskinen du redigerade: gatewayen tror nu att den kan nå det prefixet, medan klienten aldrig fick veta något. Placeringen är hela frågan, och det finns fyra ställen där samma rad kan bo.
De fyra ställena och vem som tar emot varje
En rutt kan läggas till av klientens egen konfiguration, erbjudas alla klienter via en global push, erbjudas en klient via en klientspecifik fil, eller skrivas in i serverns eget routingkontext.
Dessa fyra fall använder nästan identisk syntax och ger helt olika resultat. De tre första påverkar vad en klient skickar in i tunneln; det fjärde påverkar hur servern når ett nätverk, vilket är användbart när servern själv behöver en väg och skadligt när det förväxlas med distribution.
Bestäm vilken av de fyra du vill ha innan du skriver raden och bekräfta sedan mottagaren.
| 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 |
Varför den bara serverrutten förvånar folk
Serverkonfigurationen är det första stället administratörer tittar på, och ett rutt direktiv där läses som ett påstående om VPN-nätverket. Det är det inte. OpenVPN behandlar det som en lokal ruttinstallation på maskinen som kör daemonen, vilket är precis samma typ av ändring som du skulle göra med ip route och sedan glömma.
Distribution kräver att rutten pushas, och push kräver att klienten drar den. En klient som startas med dragna alternativ inaktiverade ignorerar erbjudandet helt. Kontrollera båda ändarna av det handslaget innan du skriver om serverfilen, eftersom serverloggen inte kommer att klaga: från dess sida skickades erbjudandet. En accepterad rutt träder också i kraft först vid nästa anslutning, aldrig i sessionen du redan är i.
När du ser de två som separata operationer slutar felet vara mystiskt: servern når prefixet, klienten inte, och båda påståendena är sanna samtidigt.
Klientspecifika filer och identiteten de matchar
En klientspecifik fil namnges efter den identitet servern autentiserade, vilket som standard är certifikatets vanliga namn. Ett vänligt anslutningsnamn i en skrivbordsklient är inte det värdet, och en missmatchning ger en fil som aldrig läses.
Kontrollera katalogen servern faktiskt använder och bekräfta sedan att filnamnet matchar den autentiserade identiteten exakt, inklusive stora och små bokstäver.
grep -n 'client-config-dir' /etc/openvpn/server/server.conf
ls -l /etc/openvpn/ccd/Inuti den filen måste rutten fortfarande pushas, eftersom den klientspecifika kontexten är en uppsättning alternativ som tillämpas på den klientens session, inte en lokal routingtabell. En bar rutt där har samma problem som en bar rutt i den globala filen.
Klientens egen fil och verktyget som äger den
En rutt som placeras i klientens konfiguration installeras när den klienten ansluter och tas bort när den kopplar från, vilket är rätt livscykel för en statisk destination.
Om en nätverkshanterare äger profilen kan den importera dessa alternativ en gång och sedan behålla sin egen kopia. Att redigera den nedladdade filen efteråt ändrar ingenting, vilket är en vanlig orsak till "rutten finns men gäller inte".
Kontrollera den aktiva profilen i stället för filen du laddade ner, och kontrollera de importerade inställningarna som hanteraren visar. Anslut sedan och fråga systemet vilken väg en specifik adress använder, i stället för att anta att tunneln vann eftersom rutten fanns i en textfil.
Verifiera på klienten och kontrollera sedan returvägen
Fråga klientens egen routingtabell om destinationen, inte serverns. En sökning efter en enda värd inne i prefixet räcker för att visa gränssnittet och nästa hopp som kommer att användas.
ip route get 10.60.0.10Om sökningen pekar på tunneln fungerade distributionen och det återstående problemet finns någon annanstans. Om den pekar på standardgatewayen installerades inte rutten, filtrerades den av ett klientalternativ, eller tillhör den en profil som klienten inte använder.
Anta att distributionen fungerade och att ingenting svarar ändå: kontrollera då vidarebefordran på gatewayen, andra sidans returrutt och eventuell brandvägg mellan dem. En rutt väljer en väg, den ger inte åtkomst.