far funzionare openconnect vpn tramite network-manager

questo è lo stesso problema qui: far funzionare openconnect vpn tramite gui , ma le mie aggiunte sono state cancellate e mi è stato chiesto di creare una nuova domanda.

in effetti, ci sono un certo numero di persone che fanno domande simili qui, tutte con 0 risposte.

versioni software: ubuntu 14.04, openconnect 5.02

problema principale: sto provando ad aggiungere una connessione VPN in Network-Manager, usando openconnect. quando fornisco il mio nome utente e password vpn, si collega correttamente, ma non riesco a risolvere dns.

se eseguo openconnect nel terminale tramite sudo, dns funziona.

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

più dettagli:

1 bis. durante la connessione tramite openconnect e gestore di rete anche se ho aggiunto esplicitamente dns e un dominio di ricerca nella scheda ipv4, solo il dominio di ricerca finisce in /etc/resolv.conf. anche se non fornisco dns e domini di ricerca, posso vedere nei registri che sta ottenendo tali informazioni dal concentratore VPN. di nuovo, il dominio di ricerca viene aggiornato correttamente. [registro sotto]

1b. quando ci si connette tramite sudo on in un terminale, resolv.conf viene popolato correttamente con dns e domini di ricerca anche se non ho aggiunto tali informazioni nella riga di comando o fornito un percorso a uno script vpnc. deve ottenerlo dal concentratore VPN. [accedi anche sotto]

2a. durante la connessione tramite openconnect e gestore di rete, viene creata una nuova interfaccia 'vpn0'.

2b. quando ci si collega tramite sudo e la riga di comando, viene creata una nuova interfaccia 'tun0'.

registro durante la connessione tramite gestore di rete:

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)

questo è dove chiede la mia password

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'

nonostante tutto il rumore nel registro relativo all'aggiornamento di resolv.conf rimuove i nameserver ma non li sostituisce con gli indirizzi IP nel registro. aggiorna correttamente il dominio di ricerca, quindi probabilmente non è un problema di autorizzazioni.

registro durante la connessione tramite sudo openconnect nel terminale:

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'

nulla sull'aggiornamento resolv.conf, eppure aggiorna correttamente i server dei nomi e il dominio di ricerca.

aggiorno se ignoro tutti gli avvertimenti in resolv.conf e vi aggiungo i nameserver del concentratore VPN, sono immediatamente in grado di navigare. ovviamente non appena mi disconnetto, tali modifiche vengono sovrascritte.

c'era un bug su questo , nel 2012, ma è scaduto. il problema sembra essere lo script vpnc.

ho provato ad aggiornare manualmente i miei script vpnc alle ultime versioni, ma senza risultati.

alcune ulteriori ricerche rivelano che a partire da 12.04 resolv.conf non è più il luogo in cui i nameserver vanno per la risoluzione del DNS quando si utilizza Network Manager. ecco perché funziona quando uso la riga di comando, ma non quando utilizzo Network Manager. piuttosto viene aggiunto il nameserver 127.0.1.1 [dnsmasq] e a quel nameserver vengono indicati gli indirizzi IP dei nameserver reali.

Il grande vantaggio è che se ti connetti a una VPN, invece di far passare tutto il tuo traffico DNS attraverso la VPN come in passato, invierai invece solo query DNS relative alla sottorete e ai domini annunciati da quella VPN

l'aggiornamento disabilitando dnsmasq come spiegato nel link sopra risolve il problema perché /etc/resolv.conf è popolato.

questa non è una vera soluzione sebbene sia un fallback.

— zeta
fonte

Perché NetworkManager elenca 127.0.0.1 oltre agli altri due indirizzi IP redatti? Quale nameserver è in esecuzione in locale e in ascolto su 127.0.0.1 e in grado di risolvere i nomi VPN?

— jdthood,

penso che sia solo per la memorizzazione nella cache DNS. non è un nameserver "reale".

— Zee,

L'indirizzo 127.0.0.1 è elencato come indirizzo nameserver ottenuto da NetworkManager. NetworkManager passa questo indirizzo a dnsmasq per usarlo come indirizzo di inoltro. Dnsmasq proverà a inoltrare le query a questo indirizzo, che è un indirizzo di loopback. Esiste effettivamente un nameserver in esecuzione sul computer locale che ascolta le query a quell'indirizzo? E anche in questo caso, perché NetworkManager segnala l'indirizzo durante l'avvio della VPN? Mi sembra che il tuo server VPN non sia configurato correttamente per fornire 127.0.0.1 come indirizzo nameserver sulla VPN.

— jdthood,

interessante quando ho provato la mia connessione stamattina quella linea non c'è più, quindi sono solo i 2 server DNS del concentratore.

— Zee,

E ora puoi risolvere i nomi di Internet? Nomi VPN? Nomi locali? Si prega di pubblicare il contenuto effettivo di resolv.conf che si dice non sia stato aggiornato correttamente. Sapevate che NetworkManager per impostazione predefinita esegue un server dei nomi di inoltro - un'istanza di dnsmasq - che ascolta 127.0.1.1 e inoltra query ai server dei nomi agli indirizzi forniti da NetworkManager tramite DBus? Quando viene utilizzato questo server dei nomi di inoltro, solo il suo indirizzo di ascolto viene elencato su una nameserverriga in /etc/resolv.conf, indipendentemente dal numero di server dei nomi del destinatario.

— jdthood,

Controllare se esiste una discrepanza tra l'host che si sta tentando di risolvere tramite la VPN e il "Dominio DNS" che il server VPN Cisco sta inviando.

Per verificare ciò, apri un terminale ed esegui:

tail -f /var/log/syslog

Quindi avviare openconnect tramite gestore di rete. Vedrai un sacco di output, comprese alcune righe come questa:

5 dic 12:54:31 canoe NetworkManager [1266]: DNS interno: 10.0.20.21

5 dic 12:54:31 canoe NetworkManager [1266]: DNS interno: 10.10.3.32

5 dic 12:54:31 canoe NetworkManager [1266]: Dominio DNS: 'internal.example.com'

E più in basso vedrai

5 dic 12:54:31 canoe dnsmasq [1871]: utilizzo di nameserver 10.0.20.21 # 53 per il dominio internal.example.com

Ciò significa che il server VPN indica al client che i server DNS devono essere utilizzati per risolvere gli host all'interno internal.example.com, ad esempio server.internal.example.com.

Nel mio caso, devo risolvere server.example.com(e non ho ottenuto alcun risultato).

La soluzione per me era andare nelle impostazioni VPN e aggiungere example.comcome dominio di ricerca aggiuntivo:

Non dimenticare di disconnettere la VPN e riconnetterti per rendere effettive le impostazioni.

— jdhildeb
fonte

Quindi ho risolto questo per me stesso in modo abbastanza soddisfacente. Sono su Mint 18 / Ubuntu 16.04

Il mio problema era che una volta connesso alla VPN Openconnect tramite NetworkManager non potevo più risolvere il DNS per domini al di fuori dei miei domini di lavoro. Cioè ho perso internet!

La mia correzione era questa:

In NetworkManager, ho modificato la connessione VPN in "Connessioni di rete".
Nella scheda IPv4, il metodo è cambiato in "Solo indirizzi automatici (VPN)"
Aggiunti il mio server DNS di lavoro (ad es. 10.10.10.100) e "Cerca dominio" di "mywork.tld"
Fai clic su "Percorsi".
Aggiungi un percorso che copra la mia rete di lavoro, ad esempio 10.10.0.0 / 255.255.0.0 e gateway di 10.10.10.253 <- Gateway VPN che ho ottenuto da un "traceroute".
Quindi ho spuntato entrambe le opzioni: i. "Ignora percorsi ottenuti automaticamente" ii. "Usa questa connessione solo per le risorse sulla sua rete"

Funziona sul mio computer.

La mia comprensione di ciò che è accaduto è che:

Il mio /etc/resolv.conf è configurato con dnsmasq e punta a 127.0.1.1
dnsmasq utilizza i server DNS del mio ISP per la risoluzione DNS Internet generale. Ad esempio, ISP DNS è diciamo 8.8.8.8.
Mi collego alla VPN, il server DNS del 10.10.10.100 viene aggiunto come server aggiuntivo a dnsmasq da utilizzare per la risoluzione DNS "mywork.tld".
Una volta che sono sulla VPN, il mio firewall di lavoro non mi consente più di utilizzare le porte da 53 a 8.8.8.8, quindi la mia risoluzione Internet generale scompare. Il DNS dovrebbe andare in timeout e passare al server DNS secondario, ma non per qualche motivo?
Mi resta solo l'accesso alla risoluzione DNS per "server01.mywork.tld" perché questa query va al 10.10.10.100 a cui ho accesso tramite la VPN.
Se eseguo una query per www.google.com non riesce, anche se il mio DNS interno può inoltrare. Posso solo supporre che il mio DNS interno non sia mai stato richiesto.

La mia correzione sembra funzionare fino a quando il mio lavoro non cambia la loro rete o l'indirizzo IP del server DNS.

Sono un po 'confuso, ma penso che funzioni per me perché una volta fatto questo il mio Wireless NIC diventa la mia connessione di rete predefinita. Quindi le query DNS vanno a 8.8.8.8 tramite wifi. Qualsiasi query per "xyz.mywork.tld" viene detta da dnsmasq per andare al 10.10.10.100. Ho impostato un percorso per questo, in modo che superi la scheda di rete "vpn0" che restituisce l'indirizzo IP 10.10.10.x corretto per "xyz.mywork.tld". Risoluzione DNS di bingo bango per reti interne ed esterne e tutti sono felici.

— Seanchan
fonte