openconnect vpn über den Netzwerkmanager zum Laufen bringen

Dies ist das gleiche Problem wie hier: Openconnect VPN über GUI zum Laufen bringen , aber meine Ergänzungen wurden gelöscht und ich wurde gebeten, eine neue Frage zu erstellen.

Tatsächlich gibt es hier eine Reihe von Leuten, die ähnliche Fragen stellen, alle mit 0 Antworten.

Softwareversionen: Ubuntu 14.04, openconnect 5.02

Hauptproblem: Ich versuche, eine VPN-Verbindung mit openconnect zum Netzwerk-Manager hinzuzufügen. Wenn ich meinen VPN-Benutzernamen und mein Passwort eingebe, wird die Verbindung erfolgreich hergestellt, aber ich kann DNS nicht auflösen.

Wenn ich Openconnect im Terminal über Sudo laufen lasse, funktioniert DNS.

sudo openconnect -u <username> https://<vpn concentrator name>

mehr Details:

1a. Wenn ich über openconnect und network-manager eine Verbindung herstelle, obwohl ich explizit DNS und eine Suchdomäne unter der Registerkarte ipv4 hinzugefügt habe, landet nur die Suchdomäne in /etc/resolv.conf. Selbst wenn ich keine DNS und Suchdomänen zur Verfügung stelle, kann ich in den Protokollen sehen, dass diese Informationen vom VPN-Konzentrator abgerufen werden. Auch hier wird die Suchdomäne ordnungsgemäß aktualisiert. [Log unten]

1b. Wenn eine Verbindung über sudo on in einem Terminal hergestellt wird, wird resolv.conf ordnungsgemäß mit DNS und Suchdomänen gefüllt, obwohl ich diese Informationen nicht in der Befehlszeile hinzugefügt oder einen Pfad zu einem vpnc-Skript angegeben habe. es muss es vom VPN-Konzentrator bekommen. [log auch unten]

2a. Bei der Verbindung über openconnect und network-manager wird eine neue Schnittstelle 'vpn0' erstellt.

2b. Bei der Verbindung über Sudo und Befehlszeile wird eine neue Schnittstelle 'tun0' erstellt.

Protokoll bei Verbindung über Netzwerk-Manager:

NetworkManager[784]: <info> Starting VPN service 'openconnect'...
NetworkManager[784]: <info> VPN service 'openconnect' started (org.freedesktop.NetworkManager.openconnect), PID 4513
NetworkManager[784]: <info> VPN service 'openconnect' appeared; activating connections
NetworkManager[784]: <info> VPN plugin state changed: init (1)

Hier wird nach meinem Passwort gefragt

NetworkManager[784]: <info> VPN plugin state changed: starting (3)
NetworkManager[784]:    SCPlugin-Ifupdown: devices added (path: /sys/devices/virtual/net/vpn0, iface: vpn0)
NetworkManager[784]:    SCPlugin-Ifupdown: device added (path: /sys/devices/virtual/net/vpn0, iface: vpn0): no ifupdown configuration found.
NetworkManager[784]: <warn> /sys/devices/virtual/net/vpn0: couldn't determine device driver; ignoring...
NetworkManager[784]: <info> VPN connection '<connection name>' (Connect) reply received.
openconnect[4544]: Attempting to connect to server <ip address>:443
openconnect[4544]: SSL negotiation with <correctly identified vpn server>
openconnect[4544]: Connected to HTTPS on <correctly identified vpn server>
openconnect[4544]: Got CONNECT response: HTTP/1.1 200 OK
openconnect[4544]: CSTP connected. DPD 30, Keepalive 20
NetworkManager[784]: <info> VPN connection '<connection name>' (IP Config Get) reply received.
NetworkManager[784]: <info> VPN connection '<connection name>' (IP4 Config Get) reply received.
NetworkManager[784]: <info> VPN connection '<connection name>' (IP6 Config Get) reply received.
NetworkManager[784]: <info> VPN Gateway: <ip address>
NetworkManager[784]: <info> Tunnel Device: vpn0
NetworkManager[784]: <info> IPv4 configuration:
NetworkManager[784]: <info>   Internal Address: 10.xxx.xxx.xxx
NetworkManager[784]: <info>   Internal Prefix: 19
NetworkManager[784]: <info>   Internal Point-to-Point Address: 10.xxx.xxx.xxx
NetworkManager[784]: <info>   Maximum Segment Size (MSS): 0
NetworkManager[784]: <info>   Forbid Default Route: no
NetworkManager[784]: <info>   Internal DNS: <ip address>
NetworkManager[784]: <info>   Internal DNS: <ip address>
NetworkManager[784]: <info>   DNS Domain: '(none)'
NetworkManager[784]: <info> IPv6 configuration:
NetworkManager[784]: <info>   Internal Address: <ipv6 ip>
NetworkManager[784]: <info>   Internal Prefix: 64
NetworkManager[784]: <info>   Internal Point-to-Point Address: <ipv6 ip>
NetworkManager[784]: <info>   Maximum Segment Size (MSS): 0
NetworkManager[784]: <info>   Forbid Default Route: no
NetworkManager[784]: <info>   DNS Domain: '(none)'
openconnect[4544]: Connected vpn0 as <ip address> + <ipv6 ip>, using SSL
openconnect[4544]: Established DTLS connection (using OpenSSL)
NetworkManager[784]: <info> VPN connection '<connection name>' (IP Config Get) complete.
NetworkManager[784]: <info> Policy set '<connection name>' (vpn0) as default for IPv4 routing and DNS.
NetworkManager[784]: <info> Policy set '<connection name>' (vpn0) as default for IPv6 routing and DNS.
NetworkManager[784]: <info> Writing DNS information to /sbin/resolvconf
dnsmasq[1027]: setting upstream servers from DBus
dnsmasq[1027]: using nameserver 127.0.0.1#53 for domain 10.in-addr.arpa
dnsmasq[1027]: using nameserver 127.0.0.1#53 for domain <home search domain>
dnsmasq[1027]: using nameserver 127.0.0.1#53 for domain <vpn search domain>
dnsmasq[1027]: using nameserver <ip address>#53 for domain 10.in-addr.arpa
dnsmasq[1027]: using nameserver <ip address>#53 for domain <home search domain>
dnsmasq[1027]: using nameserver <ip address>#53 for domain <vpn search domain>
dnsmasq[1027]: using nameserver <ip address>#53 for domain 10.in-addr.arpa
dnsmasq[1027]: using nameserver <ip address>#53 for domain <home search domain>
dnsmasq[1027]: using nameserver <ip address>#53 for domain <vpn search domain>
dbus[471]: [system] Activating service name='org.freedesktop.nm_dispatcher' (using servicehelper)
NetworkManager[784]: <info> VPN plugin state changed: started (4)
NetworkManager[784]:    keyfile: updating /etc/NetworkManager/system-connections/<connection name>-6a503043-13b0-4ce7-9749-29cd3054cae3
dbus[471]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'

Trotz aller Geräusche im Protokoll über die Aktualisierung von resolv.conf werden die Nameserver entfernt, aber nicht durch die IP-Adressen im Protokoll ersetzt. Die Suchdomäne wird korrekt aktualisiert, sodass es sich wahrscheinlich nicht um ein Berechtigungsproblem handelt.

Protokoll beim Verbinden mit sudo openconnect im Terminal:

NetworkManager[784]:    SCPlugin-Ifupdown: devices added (path: /sys/devices/virtual/net/tun0, iface: tun0)
NetworkManager[784]:    SCPlugin-Ifupdown: device added (path: /sys/devices/virtual/net/tun0, iface: tun0): no ifupdown configuration found.
NetworkManager[784]: <warn> /sys/devices/virtual/net/tun0: couldn't determine device driver; ignoring...
dbus[471]: [system] Activating service name='org.freedesktop.hostname1' (using servicehelper)
kernel: [ 3258.725774] systemd-hostnamed[4927]: Warning: nss-myhostname is not installed. Changing the local hostname might make it unresolveable. Please install nss-myhostname!
dbus[471]: [system] Successfully activated service 'org.freedesktop.hostname1'

nichts über das Aktualisieren von resolv.conf, und dennoch werden die Nameserver und die Suchdomäne ordnungsgemäß aktualisiert.

Update, wenn ich alle Warnungen in resolv.conf ignoriere und die VPN-Konzentrator-Nameserver hinzufüge, kann ich sofort surfen. Sobald ich die Verbindung trenne, werden diese Änderungen natürlich überschrieben.

Es gab 2012 einen Fehler , der jedoch abgelaufen ist. Das Problem scheint das VPN-Skript zu sein.

Ich habe versucht, meine VPN-Skripte manuell auf die neuesten Versionen zu aktualisieren, aber ohne Erfolg.

Einige weitere Untersuchungen haben ergeben , dass ab 12.04 in resolv.conf Nameserver nicht mehr für die DNS-Auflösung verwendet werden, wenn der Netzwerkmanager verwendet wird. Deshalb funktioniert es, wenn ich die Befehlszeile benutze, aber nicht, wenn ich den Netzwerk-Manager benutze. Stattdessen wird der Nameserver 127.0.1.1 [dnsmasq] hinzugefügt und diesem Nameserver werden die IP-Adressen der tatsächlichen Nameserver mitgeteilt.

Der große Vorteil besteht darin, dass Sie, wenn Sie eine Verbindung zu einem VPN herstellen, anstatt wie in der Vergangenheit den gesamten DNS-Verkehr über das VPN zu leiten, nur DNS-Anfragen zu dem von diesem VPN angekündigten Subnetz und den Domänen senden

Das Update, das dnsmasq deaktiviert, wie im obigen Link erläutert, behebt das Problem, da /etc/resolv.conf ausgefüllt ist.

Dies ist keine echte Lösung, obwohl es ein Fallback ist.

— zee
quelle

Warum listet NetworkManager zusätzlich zu den beiden anderen redigierten IP-Adressen 127.0.0.1 auf? Welcher Nameserver wird lokal ausgeführt und überwacht 127.0.0.1 und kann VPN-Namen auflösen?

— jdthood

Ich denke, das ist nur für DNS-Caching. Es ist kein "echter" Nameserver.

— Zee

Die Adresse 127.0.0.1 wird als Nameserver-Adresse aufgeführt, die von NetworkManager abgerufen wird. NetworkManager übergibt diese Adresse an dnsmasq, um sie als Weiterleitungsadresse zu verwenden. Dnsmasq versucht, Abfragen an diese Adresse weiterzuleiten, bei der es sich um eine Loopback-Adresse handelt. Gibt es tatsächlich einen Nameserver auf dem lokalen Computer, der an dieser Adresse auf Abfragen wartet? Und selbst wenn ja, warum meldet NetworkManager die Adresse während der VPN-Initiierung? Für mich sieht es so aus, als ob Ihr VPN-Server falsch konfiguriert ist, um 127.0.0.1 als Nameserver-Adresse im VPN anzugeben.

— jdthood

Interessanterweise ist diese Leitung jetzt weg, als ich heute Morgen meine Verbindung ausprobiert habe. Es sind also nur die 2 DNS-Server vom Konzentrator.

— Zee

Und können Sie jetzt Internetnamen auflösen? VPN-Namen? Lokale Namen? Bitte posten Sie den tatsächlichen Inhalt von resolv.conf, von dem Sie sagen, dass er nicht richtig aktualisiert wird. Wussten Sie, dass NetworkManager standardmäßig einen Weiterleitungs-Nameserver - eine Instanz von dnsmasq - ausführt, der 127.0.1.1 abhört und Abfragen an Nameserver an Adressen weiterleitet, die NetworkManager ihm über DBus zugewiesen hat? Wenn dieser Weiterleitungs-Nameserver verwendet wird, wird nur seine nameserverAbhöradresse in einer Zeile in /etc/resolv.conf aufgeführt, unabhängig davon, wie viele Weiterleitungs-Nameserver verwendet werden.

— jdthood

Überprüfen Sie, ob zwischen dem Host, den Sie über das VPN beheben möchten, und der vom Cisco VPN-Server gesendeten "DNS-Domäne" eine Nichtübereinstimmung besteht.

Um dies zu überprüfen, öffnen Sie ein Terminal und führen Sie Folgendes aus:

tail -f /var/log/syslog

Starten Sie dann openconnect über den Netzwerkmanager. Sie werden eine ganze Reihe von Ausgaben sehen, einschließlich einiger Zeilen wie dieser:

5. Dezember 12:54:31 Kanu NetworkManager [1266]: Internes DNS: 10.0.20.21

5. Dezember 12:54:31 Kanu NetworkManager [1266]: Internes DNS: 10.10.3.32

5. Dezember 12:54:31 Kanu NetworkManager [1266]: DNS-Domäne: 'internal.example.com'

Und weiter unten wirst du sehen

5. Dezember 12:54:31 Kanu dnsmasq [1871]: Verwenden des Nameservers 10.0.20.21 # 53 für die Domain internal.example.com

Dies bedeutet, dass der VPN-Server den Client anweist, dass die DNS-Server zum Auflösen von Hosts verwendet werden sollen internal.example.com, z server.internal.example.com.

In meinem Fall muss ich eine Lösung finden server.example.com(und habe kein Ergebnis erhalten).

Die Lösung für mich bestand darin, in die VPN-Einstellungen zu gehen und example.comals zusätzliche Suchdomäne hinzuzufügen :

Vergessen Sie nicht, das VPN zu trennen und erneut eine Verbindung herzustellen, damit die Einstellung wirksam wird.

— jdhildeb
quelle

Also habe ich das für mich zufriedenstellend genug gelöst. Ich bin auf Mint 18 / Ubuntu 16.04

Mein Problem war, dass ich, sobald ich über NetworkManager eine Verbindung zum Openconnect-VPN hergestellt hatte, DNS für Domänen außerhalb meiner Arbeitsdomänen nicht mehr auflösen konnte. Dh ich habe das Internet verloren!

Mein Fix war:

In NetworkManager habe ich die VPN-Verbindung unter "Netzwerkverbindungen" bearbeitet.
Auf der Registerkarte IPv4 wurde die Methode in "Nur automatische (VPN) Adressen" geändert.
Mein Arbeits-DNS-Server (zB 10.10.10.100) und "Suchdomäne" von "mywork.tld" wurden hinzugefügt.
Klicken Sie auf "Routen".
Fügen Sie eine Route hinzu, die mein Arbeitsnetzwerk abdeckt, z. B. 10.10.0.0 / 255.255.0.0 und das Gateway 10.10.10.253 <- VPN-Gateway, das ich von einer "Traceroute" erhalten habe.
Dann habe ich beide Optionen angekreuzt: i. "Automatisch ausgewählte Routen ignorieren" ii. "Verwenden Sie diese Verbindung nur für Ressourcen in ihrem Netzwerk"

Funktioniert auf meinem Computer.

Mein Verständnis von dem, was passiert ist, ist das:

Meine /etc/resolv.conf ist mit dnsmasq eingerichtet und zeigt auf 127.0.1.1
dnsmasq verwendet die DNS-Server meines Internetdienstanbieters für die allgemeine Internet-DNS-Auflösung. Zum Beispiel ist ISP DNS sagen wir 8.8.8.8.
Ich verbinde mich mit VPN. Der DNS-Server vom 10.10.10.100 wird als zusätzlicher Server zu dnsmasq hinzugefügt, um für die DNS-Auflösung "mywork.tld" verwendet zu werden.
Sobald ich im VPN bin, kann ich mit meiner Arbeitsfirewall die Ports 53 bis 8.8.8.8 nicht mehr verwenden, sodass meine allgemeine Internetauflösung nicht mehr funktioniert. DNS sollte eine Zeitüberschreitung aufweisen und zum sekundären DNS-Server wechseln, aber aus irgendeinem Grund nicht?
Ich habe nur Zugriff auf die DNS-Auflösung für "server01.mywork.tld", da diese Abfrage an 10.10.10.100 geht, auf die ich über das VPN zugreifen kann.
Wenn ich nach www.google.com frage, schlägt dies fehl, obwohl mein internes DNS weiterleiten kann. Ich kann nur davon ausgehen, dass mein internes DNS nie gefragt wird.

Mein Fix scheint so lange zu funktionieren, wie meine Arbeit die IP-Adresse des Netzwerks oder des DNS-Servers nicht ändert.

Ich bin ein bisschen dunstig, aber ich denke, es funktioniert für mich, denn sobald dies erledigt ist, wird meine drahtlose Netzwerkkarte zu meiner Standardnetzwerkverbindung. DNS-Abfragen gehen also über WLAN zu 8.8.8.8. Jede Abfrage nach "xyz.mywork.tld" wird von dnsmasq angewiesen, zum 10.10.10.100 zu wechseln. Ich habe dafür eine Route festgelegt, die über die Netzwerkkarte "vpn0" geht, die die korrekte 10.10.10.x-IP-Adresse für "xyz.mywork.tld" zurückgibt. Bingo Bango DNS-Auflösung für interne und externe Netzwerke und alle sind glücklich.

— Seanchán
quelle