Dies ist das gleiche Problem wie hier:OpenConnect VPN über die GUI zum Laufen bringen, aber meine Ergänzungen wurden gelöscht und ich wurde aufgefordert, eine neue Frage zu erstellen.
Tatsächlich stellen hier mehrere Leute ähnliche Fragen, alle mit 0 Antworten.
Softwareversionen:Ubuntu 14.04, Openconnect 5.02
Hauptproblem:Ich versuche, mit OpenConnect eine VPN-Verbindung 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 ausführe, funktioniert DNS.
sudo openconnect -u <username> https://<vpn concentrator name>
Mehr Details:
1a. Wenn ich mich über OpenConnect und Network-Manager verbinde, landet nur die Suchdomäne in /etc/resolv.conf, obwohl ich unter der Registerkarte IPv4 ausdrücklich DNS und eine Suchdomäne hinzugefügt habe. Auch wenn ich DNS und Suchdomänen nicht angebe, kann ich in den Protokollen sehen, dass diese Informationen vom VPN-Konzentrator abgerufen werden. Auch hier wird die Suchdomäne ordnungsgemäß aktualisiert. [Protokoll unten]
1b. Wenn ich mich über sudo in einem Terminal verbinde, wird resolv.conf korrekt mit DNS und Suchdomänen gefüllt, obwohl ich diese Informationen nicht in der Befehlszeile hinzugefügt oder einen Pfad zu einem VPN-Skript angegeben habe. Es muss es vom VPN-Konzentrator beziehen. [Protokoll auch unten]
2a. Bei der Verbindung über OpenConnect und Network-Manager wird eine neue Schnittstelle „VPN0“ erstellt.
2b. Beim Verbinden über sudo und Kommandozeile wird eine neue Schnittstelle „tun0“ erstellt.
Protokollieren Sie bei der Verbindung über den Netzwerkmanager:
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 Aufregung 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, daher ist es wahrscheinlichnichtein Berechtigungsproblem.
Protokollieren Sie die Verbindung mit „sudo openconnect“ in einem 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 die Aktualisierung von resolv.conf, und dennoch werden die Nameserver und die Suchdomäne ordnungsgemäß aktualisiert.
Aktualisieren 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 einen Fehler dabei, im Jahr 2012, aber es ist abgelaufen. Das Problem scheint das VPNC-Skript zu sein.
Ich habe versucht, meine VPN-Skripte manuell auf die neuesten Versionen zu aktualisieren, aber ohne Erfolg.
Mancheweitere Forschungstellt sich heraus, dass resolv.conf ab 12.04 nicht mehr die Adresse ist, an die Nameserver zur DNS-Auflösung gehen, wenn der Netzwerkmanager verwendet wird. Deshalb funktioniert es, wenn ich die Befehlszeile verwende, aber nicht, wenn ich den Netzwerkmanager verwende. 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 bei einer Verbindung mit einem VPN nicht mehr wie bisher Ihren gesamten DNS-Verkehr über das VPN leiten lassen, sondern stattdessen nur noch DNS-Anfragen senden, die sich auf das von diesem VPN bekannt gegebene Subnetz und die Domänen beziehen.
Aktualisieren Das Deaktivieren von dnsmasq, wie im obigen Link erläutert, löst das Problem, da /etc/resolv.conf ausgefüllt ist.
Dies ist allerdings keine wirkliche Lösung, sondern nur ein Fallback.
Antwort1
Überprüfen Sie, ob eine Nichtübereinstimmung zwischen dem Host, den Sie über das VPN auflösen möchten, und der „DNS-Domäne“, die der Cisco VPN-Server sendet, 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, darunter einige Zeilen wie diese:
Dez 5 12:54:31 Kanu NetworkManager[1266]: Interner DNS: 10.0.20.21
5. Dez 12:54:31 Kanu NetworkManager[1266]: Interner DNS: 10.10.3.32
5. Dez 12:54:31 Kanu NetworkManager[1266]: DNS-Domäne: 'internal.example.com'
Und weiter unten sehen Sie
5. Dez 12:54:31 canoe dnsmasq[1871]: verwende Nameserver 10.0.20.21#53 für Domäne internal.example.com
Dies bedeutet, dass der VPN-Server dem Client mitteilt, dass die DNS-Server zum Auflösen von Hosts innerhalb von verwendet werden sollen internal.example.com, z. B. server.internal.example.com.
In meinem Fall muss ich das Problem lösen server.example.com(und habe kein Ergebnis erhalten).
Die Lösung bestand für mich darin, in die VPN-Einstellungen zu gehen und example.comals zusätzliche Suchdomäne hinzuzufügen:
Vergessen Sie nicht, die VPN-Verbindung zu trennen und anschließend erneut herzustellen, damit die Einstellung wirksam wird.
Antwort2
Ich habe das für mich also zufriedenstellend gelöst. Ich verwende Mint 18 / Ubuntu 16.04
Mein Problem war, dass ich, nachdem 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. Das heißt, ich hatte keinen Internetzugriff mehr!
Meine Lösung war folgende:
- Im NetworkManager habe ich die VPN-Verbindung unter „Netzwerkverbindungen“ bearbeitet.
- Im Reiter IPv4 wurde die Methode auf „Nur automatische (VPN-)Adressen“ geändert.
- Meinen Arbeits-DNS-Server (z. B. 10.10.10.100) und die „Suchdomäne“ „mywork.tld“ 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 einem „Traceroute“ erhalten habe.
- Dann habe ich beide Optionen angekreuzt: i. „Automatisch ausgewählte Routen ignorieren“ ii. „Diese Verbindung nur für Ressourcen in ihrem Netzwerk verwenden“
Funktioniert auf meinem Computer.
Nach meinem Verständnis ist der Vorfall folgendermaßen verlaufen:
- Meine /etc/resolv.conf ist mit dnsmasq eingerichtet und zeigt auf 127.0.1.1
- dnsmasq verwendet die DNS-Server meines ISPs für die allgemeine DNS-Auflösung im Internet. Der DNS des ISPs lautet beispielsweise 8.8.8.8.
- Ich verbinde mich mit VPN, der DNS-Server 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, erlaubt mir meine Arbeitsfirewall nicht mehr, Port 53 bis 8.8.8.8 zu verwenden, sodass meine allgemeine Internetauflösung verloren geht. DNS sollte eine Zeitüberschreitung aufweisen und zum sekundären DNS-Server wechseln, aber aus irgendeinem Grund geschieht dies nicht?
- Mir bleibt nur noch der Zugriff auf die DNS-Auflösung für „server01.mywork.tld“, da diese Abfrage an 10.10.10.100 geht, worauf ich über das VPN Zugriff habe.
- Wenn ich www.google.com abfrage, schlägt dies fehl, obwohl mein interner DNS weiterleiten kann. Ich kann nur annehmen, dass mein interner DNS nie abgefragt wird.
Meine Lösung scheint zu funktionieren, solange ich durch meine Arbeit die Netzwerk- oder DNS-Server-IP-Adresse nicht ändere.
Ich bin mir nicht ganz sicher, aber ich glaube, es funktioniert für mich, denn sobald dies erledigt ist, wird meine drahtlose Netzwerkkarte zu meiner Standardnetzwerkverbindung. DNS-Abfragen gehen also über WLAN an 8.8.8.8. Jede Abfrage für „xyz.mywork.tld“ wird von dnsmasq angewiesen, an 10.10.10.100 zu gehen. Ich habe dafür eine Route eingerichtet, die über die Netzwerkkarte „vpn0“ geht, die die richtige 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 zufrieden.