Hvor hører ruten hjemme i OpenVPN: hos klienten eller serveren?
En bar rute i serverkonfigurationen ændrer serveren, ikke klienten. Vælg klientfilen, et globalt push eller et push til én klient, og kontroller, hvad der ankom.
Du tilføjer route 10.60.0.0 255.255.255.0 til serverkonfigurationen, genstarter, genopretter forbindelsen fra en laptop, og undernettet er stadig utilgængeligt fra den laptop. Linjen blev accepteret, tjenesten startede rent, og intet i loggen ser forkert ud. Det, der skete, er, at ruten blev installeret på den maskine, du redigerede: gatewayen tror nu, at den kan nå det præfiks, mens klienten aldrig fik noget at vide. Placeringen er hele spørgsmålet, og der er fire steder, hvor den samme linje kan bo.
De fire steder og hvem der modtager hvert af dem
En rute kan tilføjes af klientens egen konfiguration, tilbydes alle klienter gennem et globalt push, tilbydes én klient gennem en klientspecifik fil eller skrives ind i serverens egen routingkontekst.
De fire tilfælde bruger næsten identisk syntaks og giver helt forskellige resultater. De første tre påvirker, hvad en klient sender ind i tunnelen; det fjerde påvirker, hvordan serveren når et netværk, hvilket er nyttigt, når serveren selv har brug for en vej, og skadeligt, når det forveksles med distribution.
Beslut, hvilken af de fire du vil have, før du skriver linjen, og bekræft derefter modtageren.
| 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 serverrute overrasker folk
Serverkonfigurationen er det første sted, administratorer kigger, og en routedirektiv der læses som en udtalelse om VPN-netværket. Det er det ikke. OpenVPN behandler det som en lokal ruteinstallation på den maskine, der kører daemonen, hvilket er præcis den samme slags ændring, du ville lave med ip route og derefter glemme.
Distribution kræver, at ruten pushes, og push kræver, at klienten trækker. En klient startet med trukne indstillinger deaktiveret ignorerer tilbuddet helt. Kontroller begge ender af det håndtryk, før du omskriver serverfilen, fordi serverloggen vil ikke klage: fra dens side blev tilbuddet sendt. En accepteret rute træder også først i kraft ved næste forbindelse, aldrig i den session, du allerede er i.
Når du ser de to som separate handlinger, holder fejlen op med at være mystisk: serveren kan nå præfikset, klienten kan ikke, og begge udsagn er sande på samme tid.
Klientspecifikke filer og den identitet, de matcher
En klientspecifik fil navngives efter den identitet, serveren autentificerede, som som standard er certificatets common name. Et venligt forbindelsesnavn i en desktopklient er ikke den værdi, og en uoverensstemmelse giver en fil, der aldrig læses.
Kontroller den mappe, serveren faktisk bruger, og bekræft derefter, at filnavnet matcher den autentificerede identitet præcist, inklusive store og små bogstaver.
grep -n 'client-config-dir' /etc/openvpn/server/server.conf
ls -l /etc/openvpn/ccd/Inde i den fil skal ruten stadig pushes, fordi den klientspecifikke kontekst er et sæt indstillinger, der anvendes på den klients session, ikke en lokal routingtabel. En bar rute der har samme problem som en bar rute i den globale fil.
Klientens egen fil og værktøjet, der ejer den
En rute, der er placeret i klientens konfiguration, installeres, når den klient opretter forbindelse, og fjernes, når den afbryder, hvilket er den rigtige livscyklus for en statisk destination.
Hvis en netværksadministrator ejer profilen, kan den importere disse indstillinger én gang og derefter beholde sin egen kopi. At redigere den downloadede fil bagefter ændrer intet, hvilket er en almindelig årsag til "ruten er der, men gælder ikke".
Kontroller den aktive profil i stedet for den fil, du downloadede, og kontroller de importerede indstillinger, som administratoren viser. Opret derefter forbindelse, og spørg systemet, hvilken vej en bestemt adresse bruger, i stedet for at antage, at tunnelen vandt, fordi ruten fandtes i en tekstfil.
Bekræft på klienten, og kontroller derefter returvejen
Spørg klientens egen routingtabel om destinationen, ikke serverens. Et opslag på en enkelt vært inde i præfikset er nok til at vise det interface og det næste hop, der vil blive brugt.
ip route get 10.60.0.10Hvis opslaget peger på tunnelen, virkede distributionen, og det resterende problem er et andet sted. Hvis det peger på standardgatewayen, blev ruten ikke installeret, blev filtreret af en klientindstilling eller tilhører en profil, som klienten ikke bruger.
Antag, at distributionen virkede, og der stadig ikke svares: kontroller derefter forwarding på gatewayen, den anden sides returrute og enhver firewall imellem. En rute vælger en vej, den giver ikke adgang.