faire fonctionner openconnect vpn via network-manager

c'est le même problème qu'ici: faire fonctionner openconnect vpn via gui , mais mes ajouts ont été supprimés et on m'a demandé de créer une nouvelle question.

en fait, un certain nombre de personnes posent des questions similaires ici, toutes avec 0 réponses.

versions du logiciel: ubuntu 14.04, openconnect 5.02

problème principal: j'essaie d'ajouter une connexion vpn dans le gestionnaire de réseau, en utilisant openconnect. quand je fournis mon nom d'utilisateur et mon mot de passe vpn, il se connecte avec succès, mais je ne peux pas résoudre le DNS.

si je lance openconnect dans le terminal via sudo, le DNS fonctionne.

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

plus de détails:

1a. lors de la connexion via openconnect et network-manager, même si j'ai explicitement ajouté DNS et un domaine de recherche sous l'onglet ipv4, seul le domaine de recherche se retrouve dans /etc/resolv.conf. même si je ne fournis pas de DNS et de domaines de recherche, je peux voir dans les journaux qu'il obtient ces informations du concentrateur VPN. encore une fois, le domaine de recherche est correctement mis à jour. [log ci-dessous]

1b. lors de la connexion via sudo sur un terminal, resolv.conf est correctement rempli avec les domaines DNS et de recherche, même si je n'ai pas ajouté ces informations dans la ligne de commande ou fourni un chemin vers un script vpnc. il doit l'obtenir du concentrateur vpn. [connectez-vous également ci-dessous]

2a. lors de la connexion via openconnect et network-manager, une nouvelle interface 'vpn0' est créée.

2b. lors de la connexion via sudo et la ligne de commande, une nouvelle interface 'tun0' est créée.

journal lors de la connexion via le gestionnaire de réseau:

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)

c'est là qu'il me demande mon mot de passe

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'

malgré tout le bruit dans le journal concernant la mise à jour de resolv.conf, il supprime les serveurs de noms mais ne les remplace pas par les adresses IP dans le journal. il met à jour le domaine de recherche correctement, donc ce n'est probablement pas un problème d'autorisations.

journal lors de la connexion à l'aide de sudo openconnect dans le 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'

rien sur la mise à jour de resolv.conf, et pourtant il met correctement à jour les serveurs de noms et le domaine de recherche.

mettre à jour si j'ignore tous les avertissements dans resolv.conf et y ajouter les serveurs de noms de concentrateur vpn, je suis instantanément en mesure de naviguer. bien sûr, dès que je me déconnecte, ces modifications sont écrasées.

il y avait un bug à ce sujet , en 2012, mais il a expiré. le problème semble être le script vpnc.

j'ai essayé de mettre à jour manuellement mes scripts vpnc vers les dernières versions, mais en vain.

d' autres recherches révèlent qu'à partir du 12.04 resolv.conf n'est plus où les serveurs de noms recherchent la résolution DNS lors de l'utilisation de network-manager. c'est pourquoi cela fonctionne lorsque j'utilise la ligne de commande, mais pas lors de l'utilisation du gestionnaire de réseau. le serveur de noms 127.0.1.1 [dnsmasq] est plutôt ajouté et ce serveur de noms reçoit les adresses IP des serveurs de noms réels.

Le gros avantage est que si vous vous connectez à un VPN, au lieu que tout votre trafic DNS soit acheminé via le VPN comme par le passé, vous n'enverrez à la place que des requêtes DNS liées au sous-réseau et aux domaines annoncés par ce VPN.

la mise à jour désactivant dnsmasq comme expliqué dans le lien ci-dessus résout le problème car /etc/resolv.conf est rempli.

ce n'est pas une vraie solution mais c'est un repli.

— zee
source

Pourquoi NetworkManager répertorie 127.0.0.1 en plus des deux autres adresses IP expurgées? Quel serveur de noms s'exécute localement et écoute à 127.0.0.1 et est capable de résoudre les noms VPN?

— jdthood

je pense que c'est juste pour la mise en cache DNS. ce n'est pas un "vrai" serveur de noms.

— zee

L'adresse 127.0.0.1 est répertoriée en tant qu'adresse de serveur de noms obtenue par NetworkManager. NetworkManager transmet cette adresse à dnsmasq pour l'utiliser comme adresse de transfert. Dnsmasq essaiera de transmettre les requêtes à cette adresse qui est une adresse de bouclage. Existe-t-il réellement un serveur de noms en cours d'exécution sur la machine locale qui écoute les requêtes à cette adresse? Et même si c'est le cas, pourquoi NetworkManager signale-t-il l'adresse lors de l'initiation VPN? Il me semble que votre serveur VPN est mal configuré pour fournir 127.0.0.1 comme adresse de serveur de noms sur le VPN.

— jdthood

Fait intéressant, lorsque j'ai essayé ma connexion ce matin, cette ligne a maintenant disparu, il ne s'agit donc que des 2 serveurs DNS du concentrateur.

— zee

Et pouvez-vous maintenant résoudre les noms Internet? Noms VPN? Noms locaux? Veuillez publier le contenu réel de resolv.conf qui, selon vous, n'est pas mis à jour correctement. Saviez-vous que NetworkManager exécute par défaut un serveur de noms de transfert - une instance de dnsmasq - qui écoute au 127.0.1.1 et transmet les requêtes aux serveurs de noms aux adresses qui lui sont données par NetworkManager via DBus? Lorsque ce serveur de noms de transfert est utilisé, seule son adresse d'écoute est répertoriée sur une nameserverligne dans /etc/resolv.conf, quel que soit le nombre de serveurs de noms de destinataires utilisés.

— jdthood

Vérifiez s'il y a un décalage entre l'hôte que vous essayez de résoudre via le VPN et le «domaine DNS» que le serveur VPN Cisco envoie.

Pour vérifier cela, ouvrez un terminal et exécutez:

tail -f /var/log/syslog

Ensuite, démarrez openconnect via le gestionnaire de réseau. Vous verrez tout un tas de résultats, y compris certaines lignes comme celle-ci:

5 décembre 12:54:31 canoe NetworkManager [1266]: DNS interne: 10.0.20.21

5 décembre 12:54:31 canoe NetworkManager [1266]: DNS interne: 10.10.3.32

5 décembre 12:54:31 canoe NetworkManager [1266]: domaine DNS: 'internal.example.com'

Et plus bas, vous verrez

5 décembre 12:54:31 canoe dnsmasq [1871]: utilisation du serveur de noms 10.0.20.21 # 53 pour le domaine internal.example.com

Cela signifie que le serveur VPN indique au client que les serveurs DNS doivent être utilisés pour résoudre les hôtes à l'intérieur internal.example.com, tels que server.internal.example.com.

Dans mon cas, je dois résoudre server.example.com(et n'obtenais aucun résultat).

La solution pour moi était d'entrer dans les paramètres VPN et d'ajouter example.comun domaine de recherche supplémentaire:

N'oubliez pas de déconnecter le VPN, puis de vous reconnecter pour que le paramètre prenne effet.

— jdhildeb
source

J'ai donc résolu ce problème de manière assez satisfaisante. Je suis sur Mint 18 / Ubuntu 16.04

Mon problème était qu'une fois connecté au VPN Openconnect via NetworkManager, je ne pouvais plus résoudre le DNS pour les domaines en dehors de mes domaines de travail. C'est à dire que j'ai perdu Internet!

Ma solution était la suivante:

Dans NetworkManager, j'ai modifié la connexion VPN sous "Connexions réseau".
Dans l'onglet IPv4, modification de la méthode en "Adresses automatiques (VPN) uniquement"
Ajout de mon serveur DNS professionnel (par exemple 10.10.10.100) et "domaine de recherche" de "mywork.tld"
Cliquez sur "Itinéraires".
Ajoutez une route qui couvre mon réseau de travail, par exemple 10.10.0.0 / 255.255.0.0 et passerelle de 10.10.10.253 <- Passerelle VPN que j'ai obtenue d'une "traceroute".
Ensuite, j'ai coché les deux options: i. "Ignorer les itinéraires automatiquement choisis" ii. "Utiliser cette connexion uniquement pour les ressources de son réseau"

Fonctionne sur mon ordinateur.

Ma compréhension de ce qui s'est passé est que:

Mon /etc/resolv.conf est configuré avec dnsmasq et pointe vers 127.0.1.1
dnsmasq utilise les serveurs DNS de mon FAI pour la résolution DNS Internet générale. Par exemple, ISP DNS est disons 8.8.8.8.
Je me connecte au VPN, le serveur DNS de 10.10.10.100 est ajouté en tant que serveur supplémentaire à dnsmasq pour être utilisé pour la résolution DNS "mywork.tld".
Une fois que je suis sur le VPN, mon pare-feu de travail ne me permet plus d'utiliser le port 53 à 8.8.8.8, donc ma résolution Internet générale disparaît. Le DNS devrait expirer et aller au serveur DNS secondaire, mais ce n'est pas le cas pour une raison quelconque?
Je ne dispose que d'un accès à la résolution DNS pour "server01.mywork.tld" car cette requête passe au 10.10.10.100 auquel j'ai accès via le VPN.
Si je recherche www.google.com, il échoue, même si mon DNS interne peut être transféré. Je peux seulement supposer que mon DNS interne n'est jamais demandé.

Mon correctif semble fonctionner tant que mon travail ne modifie pas l'adresse IP de son réseau ou de son serveur DNS.

Je suis un peu flou à ce sujet, mais je pense que cela fonctionne pour moi car une fois cela fait, ma carte réseau sans fil devient ma connexion réseau par défaut. Les requêtes DNS passent donc en 8.8.8.8 via wifi. Toute requête pour "xyz.mywork.tld" est indiquée par dnsmasq pour aller à 10.10.10.100. J'ai défini un itinéraire pour cela, de sorte que cela passe sur la carte réseau "vpn0" qui renvoie la bonne adresse IP 10.10.10.x pour "xyz.mywork.tld". Résolution DNS Bingo bango pour les réseaux internes et externes et tout le monde est content.

— Seanchán
source