Ich versuche, einige Ubuntu 20.04-Clients bei der Arbeit dazu zu bringen, eine Verbindung zu einem neuen OpenVPN-Server herzustellen, der von unserem neuen Serveranbieter bereitgestellt wird.
Das Ziel besteht darin, nur bestimmten Datenverkehr in den Tunnel zu leiten (die entsprechenden Routen werden vom OpenVPN-Server gepusht) und die Clients dazu zu bringen, auch den vom OpenVPN-Server gepushten DNS-Server zu verwenden.
Dies funktioniert mit Windows 10-Clients und OpenVPN GUI 2.5 sofort. Es funktioniert auch mit openvpn(2.4.7) vom Terminal aus wie folgt: sudo openvpn --config config.ovpnund der folgenden Client-Konfigurationsdatei config.ovpn:
dev tun
tun-ipv6
persist-tun
persist-key
cipher AES-128-GCM
ncp-ciphers AES-128-GCM
auth SHA256
tls-client
client
resolv-retry infinite
remote <ipadressOfProvider> <port> udp4
verify-x509-name "<name>" name
auth-user-pass
remote-cert-tls server
compress
# The following is added only in the config for Ubuntu 20.04
dhcp-option DOMAIN <domainToResolveWithRemoteSiteDNS>
script-security 2
up /etc/openvpn/update-systemd-resolved
up-restart
down /etc/openvpn/update-systemd-resolved
down-pre
Die Probleme beginnen bei Verwendung von network-manager-openvpn(1.8.12) und der obigen Konfigurationsdatei. Die Verbindung wird hergestellt und der gepushte DNS-Server wird in systemd-resolved (auch ohne die zusätzlichen upund downSkripte in der OpenVPN-Konfiguration) korrekt aktualisiert.
Jedoch,alleDer Verkehr wird in die tun0Schnittstelle geleitet, sogar der öffentliche Verkehr. Das Ergebnis ist, dass ichdürfenZugriff auf Ressourcen am Remote-Standort auch über interne Domänennamen, aberhabe keinen ZugriffInternet, da das OpenVPN-Subnetz keinen direkten Internetzugang hat.
Ändern der OptionVerwenden Sie diese Verbindung nur für Ressourcen in ihrem Netzwerkin der Netzwerkmanager-OpenVPN-Konfiguration (entspricht der ipv4.neverdefaultüber angezeigten Option nmcli c show config) löst das Routing-Problem: Jetzt wird nur noch Verkehr, der die gepushten Routen betrifft, in den Tunnel geleitet. Allerdings wird dadurch auch verhindert, dass der gepushte DNS-Server auf angewendet wird /run/systemd/resolve/resolv.conf.
Bisher habe ich keine Option gefunden, den gepushten DNS zu akzeptierenUndLeiten Sie nur den Verkehr weiter, der die gepushten Routen betrifft, und zwar gleichzeitig mit dem Netzwerkmanager.
Einige möglicherweise interessante Beobachtungen bisher:
1. Routen
Network Manager ipv4.neverdefault=noerstellt zusätzlich zu den gepushten Routen ein zweites Standard-Gateway mit niedrigerer Metrik:
$ ip route
default via 10.*.*.* dev tun0 proto static metric 50
default via 192.168.***.** dev wlp3s0 proto dhcp metric 600
10.*.*.*/24 dev tun0 proto kernel scope link src 10.*.*.* metric 50
158.***.**.** via 192.168.***.** dev wlp3s0 proto static metric 600
169.254.0.0/16 dev wlp3s0 scope link metric 1000
172.**.***.*/24 via 10.*.*.* dev tun0 proto static metric 50
192.168.*.*/24 via 10.*.*.* dev tun0 proto static metric 50
192.168.*.*/24 via 10.*.*.* dev tun0 proto static metric 50
192.168.***.*/24 dev wlp3s0 proto kernel scope link src 192.168.***.*** metric 600
192.168.***.** dev wlp3s0 proto static scope link metric 600
Der Network Manager ipv4.neverdefault=yeserstellt zusätzlich zu den gepushten Routen kein zweites Standard-Gateway (wie oben, ohne erste Zeile).
openvpnim Terminal wird zusätzlich zu den gepushten Routen kein sekundäres Standard-Gateway erstellt:
default via 192.168.***.** dev wlp3s0 proto dhcp metric 600
10.*.*.*/24 dev tun0 proto kernel scope link src 10.*.*.*
169.254.0.0/16 dev wlp3s0 scope link metric 1000
172.**.***.*/24 via 10.*.*.* dev tun0
192.168.*.*/24 via 10.*.*.* dev tun0
192.168.*.*/24 via 10.*.*.* dev tun0
192.168.***.*/24 dev wlp3s0 proto kernel scope link src 192.168.***.*** metric 600
2. DNS-Server
Netzwerkmanager ipv4.neverdefault=noüberschreibt /run/systemd/resolve/resolv.conf:
nameserver 172.**.***.**
Network Manager bietet folgende ipv4.neverdefault=yesFunktionen nicht:
nameserver 192.168.***.**
nameserver ****:***:****:****::**
openvpnim Terminalfügt hinzuder DNS-Server zu den vorhandenen und fügt den Domänennamen hinzu, der vom Remote-DNS-Server bereitgestellt wird, wie in folgendem definiert config.ovpn:
nameserver 192.168.***.**
nameserver ****:***:****:****::**
nameserver 172.**.***.***
search <domainToResolveWithRemoteSiteDNS>
Wenn Sie eine Idee haben, welche Optionen im Netzwerkmanager geändert werden könnten, um die Verarbeitung config.ovpnwie beim OpenVPN-Terminalclient durchzuführen, würde ich mich über Ihre Meinung freuen.
Danke, Valentin
Antwort1
Nach einigen zusätzlichen "Recherchen" (hauptsächlich Versuch und Irrtum) konnte ich erfolgreich eine Verbindung zur Remote-Site über den Netzwerkmanager herstellen und dabei nur den Verkehr der gepushten Routen weiterleitenUndmithilfe des Push-DNS-Servers.
Einstellen der VPN-Verbindung im Netzwerkmanager auf
neverdefault(wie bereits im OP besprochen):nmcli c modify <connectionname> ipv4.never-default yesEinrichten der Verbindung
dns-searchzu den internen Domänen der Gegenstelle:nmcli c modify <connectionname> ipv4.dns-search <domainname>
Diese Option veranlasst den Netzwerkmanager, den DNS-Server erneut hinzuzufügen run/systemd/resolve/resolv.conf(fügt hinzu, nicht überschreibt), obwohl es ipv4.never-defaultaktiv ist.
Alternativ <domainname>kann durch ersetzt werden , ~.was zu einem Überschreiben von führt run/systemd/resolve/resolv.confund somit den gepushten DNS-Server zum einzigen macht, der alle DNS-Anfragen beantwortet.
Antwort2
Danke @Valentin!
Ihre Lösung ist genau richtig!
In meinem Fall, in dem ich einen Ubuntu 20.04-Client verwendet habe, der sich mit dem 20.04-Server verbindet und auch die OpenVPN-Optionen des Gnome-Netzwerkmanagers verwendet, war es nicht notwendig, DNS-Search einzustellen – nur die Option „Never-Default“.
Um Ordner-/Netzwerkkonnektivität (Samba) zu ermöglichen, musste ich auch die Option „Interfaces“ unter der Direktive „Networking“ der Datei smb.conf auf meinem Server wie folgt bearbeiten
interfaces = 127.0.0.0/8 eth0
interfaces = 127.0.0.0/8 enp2s0
interfaces = X.X.X.X/XX enp2s0
Wobei die letzte Zeile hinzugefügt wurde, wobei XXXX/XX die CIDR-Notation des IP-Adressbereichs ist, der vom selben OpenVPN-Server zugewiesen wird.