ficando o openconnect vpn para trabalhar através do gerenciador de rede

Este é o mesmo problema que aqui: Conseguir que o openconnect vpn funcione com a GUI , mas minhas adições foram excluídas e fui solicitado a criar uma nova pergunta.

de fato, há várias pessoas fazendo perguntas semelhantes aqui, todas com 0 respostas.

versões de software: ubuntu 14.04, openconnect 5.02

problema principal: estou tentando adicionar uma conexão VPN ao gerenciador de rede, usando o openconnect. Quando eu forneço meu nome de usuário e senha VPN, ele se conecta com êxito, mas não consigo resolver o DNS.

se eu executar o openconnect no terminal via sudo, o dns funcionará.

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

mais detalhes:

1a. ao conectar via openconnect e gerenciador de rede, mesmo que eu tenha adicionado explicitamente dns e um domínio de pesquisa na guia ipv4, apenas o domínio de pesquisa termina em /etc/resolv.conf. mesmo que eu não forneça DNS e domínios de pesquisa, posso ver nos logs que está obtendo essas informações do concentrador de VPN. novamente, o domínio de pesquisa é atualizado corretamente. [log abaixo]

1b. ao conectar via sudo em um terminal, o resolv.conf é preenchido corretamente com domínios DNS e de pesquisa, mesmo que eu não tenha adicionado essas informações na linha de comando ou fornecido um caminho para um script vpnc. deve estar recebendo do concentrador VPN. [log também abaixo]

2a ao conectar via openconnect e gerenciador de rede, uma nova interface 'vpn0' é criada.

2b. ao conectar via sudo e linha de comando, uma nova interface 'tun0' é criada.

log ao conectar via gerenciador de rede:

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)

é aqui que ele pede minha senha

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'

apesar de todo o ruído no log sobre a atualização do resolv.conf, ele remove os servidores de nomes, mas não os substitui pelos endereços IP no log. atualiza o domínio de pesquisa corretamente, portanto, provavelmente não é um problema de permissão.

log ao conectar usando o sudo openconnect no 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'

nada sobre a atualização do resolv.conf e, no entanto, ele atualiza corretamente os servidores de nomes e o domínio de pesquisa.

atualizar se eu ignorar todos os avisos no resolv.conf e adicionar os servidores de nomes do concentrador vpn a ele, sou capaz de navegar instantaneamente. é claro que, assim que eu desconecto, essas alterações são substituídas.

houve um erro nisso , em 2012, mas expirou. o problema parece ser o script vpnc.

Eu tentei atualizar manualmente meus scripts vpnc para as versões mais recentes, mas sem sucesso.

algumas pesquisas adicionais revelam que, a partir do 12.04, o resolv.conf não é mais onde os servidores de nomes buscam a resolução de DNS ao usar o gerenciador de rede. é por isso que funciona quando eu uso a linha de comando, mas não quando uso o gerenciador de rede. em vez disso, o servidor de nomes 127.0.1.1 [dnsmasq] é adicionado e esse servidor de nomes recebe os endereços IP dos servidores de nomes reais.

A grande vantagem é que, se você se conectar a uma VPN, em vez de todo o tráfego DNS ser roteado através da VPN, como no passado, enviará apenas consultas DNS relacionadas à sub-rede e aos domínios anunciados por essa VPN.

A atualização que desativa o dnsmasq, conforme explicado no link acima, resolve o problema porque /etc/resolv.conf é preenchido.

essa não é uma solução real, embora seja um substituto.

— zee
fonte

Por que o NetworkManager lista 127.0.0.1 além dos outros dois endereços IP editados? Qual servidor de nomes está executando localmente e escutando em 127.0.0.1 e capaz de resolver nomes de VPN?

— Jdthood #

Eu acho que é apenas para cache de DNS. não é um servidor de nomes "real".

— zee

O endereço 127.0.0.1 é listado como um endereço de servidor de nomes obtido pelo NetworkManager. O NetworkManager passa esse endereço ao dnsmasq para usá-lo como um endereço de encaminhamento. O Dnsmasq tentará encaminhar consultas para este endereço, que é um endereço de loopback. Existe realmente um servidor de nomes em execução na máquina local que escuta as consultas nesse endereço? E mesmo assim, por que o NetworkManager está relatando o endereço durante a inicialização da VPN? Parece-me que seu servidor VPN está configurado incorretamente para fornecer 127.0.0.1 como um endereço de servidor de nomes na VPN.

— Jdthood #

Curiosamente, quando tentei minha conexão esta manhã, essa linha agora se foi, então são apenas os 2 servidores DNS do concentrador.

— zee

E agora você pode resolver nomes da Internet? Nomes de VPN? Nomes locais? Publique o conteúdo real do resolv.conf que você diz não estar sendo atualizado corretamente. Você sabia que o NetworkManager, por padrão, executa um servidor de nomes de encaminhamento - uma instância do dnsmasq - que escuta em 127.0.1.1 e encaminha consultas aos servidores de nomes nos endereços que o NetworkManager fornece através do DBus? Quando esse servidor de nomes de encaminhamento é usado, apenas o endereço de escuta é listado em uma nameserverlinha no /etc/resolv.conf, independentemente de quantos servidores de nomes forwardee estão em uso.

— Jdthood #

Verifique se há uma incompatibilidade entre o host que você está tentando resolver através da VPN e o "domínio DNS" que o servidor VPN da Cisco está enviando.

Para verificar isso, abra um terminal e execute:

tail -f /var/log/syslog

Em seguida, inicie o openconnect via gerenciador de rede. Você verá um monte de resultados, incluindo algumas linhas como esta:

5 de dezembro 12:54:31 canoa NetworkManager [1266]: DNS interno: 10.0.20.21

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

5 de dezembro 12:54:31 NetworkManager de canoa [1266]: Domínio DNS: 'internal.example.com'

E mais abaixo você verá

5 de dezembro 12:54:31 canoe dnsmasq [1871]: usando o servidor de nomes 10.0.20.21 # 53 para o domínio internal.example.com

Isso significa que o servidor VPN está instruindo o cliente que os servidores DNS devem ser usados para resolver hosts dentro internal.example.com, como server.internal.example.com.

No meu caso, preciso resolver server.example.com(e não estava obtendo nenhum resultado).

A solução para mim foi acessar as configurações da VPN e adicionar example.comcomo um domínio de pesquisa adicional:

Não se esqueça de desconectar a VPN e reconectar para que a configuração entre em vigor.

— jdhildeb
fonte

Então, eu resolvi isso por mim mesmo de maneira satisfatória. Estou no Mint 18 / Ubuntu 16.04

Meu problema foi que, depois que eu me conectei à VPN do Openconnect através do NetworkManager, não consegui mais resolver o DNS de domínios fora dos meus domínios de trabalho. Ou seja, eu perdi a internet!

Minha correção foi essa:

No NetworkManager, editei a conexão VPN em "Conexões de rede".
Na guia IPv4, alterou o método para "Somente endereços automáticos (VPN)"
Adicionado meu servidor DNS de trabalho (por exemplo, 10.10.10.100) e "Domínio de pesquisa" de "mywork.tld"
Clique em "Rotas".
Adicione uma rota que cubra minha rede de trabalho, por exemplo, 10.10.0.0 / 255.255.0.0 e gateway de 10.10.10.253 <- Gateway VPN que recebi de um "traceroute".
Marquei as duas opções: i. "Ignorar rotas automaticamente obtidas" ii. "Use esta conexão apenas para recursos em sua rede"

Funciona no meu computador.

Minha compreensão do que aconteceu é que:

Meu /etc/resolv.conf está configurado com o dnsmasq e está apontando para 127.0.1.1
O dnsmasq está usando os servidores DNS do meu ISP para resolução geral de DNS da Internet. Por exemplo, DNS do ISP é, digamos, 8.8.8.8.
Eu me conecto à VPN, o servidor DNS de 10.10.10.100 é adicionado como um servidor adicional ao dnsmasq para ser usado na resolução DNS "mywork.tld".
Quando estou na VPN, meu firewall de trabalho não me permite mais usar a porta 53 a 8.8.8.8, portanto minha resolução geral da Internet desaparece. O DNS deve atingir o tempo limite e ir para o servidor DNS secundário, mas não por algum motivo?
Fico apenas com acesso à resolução DNS para "server01.mywork.tld" porque esta consulta vai para 10.10.10.100 à qual tenho acesso pela VPN.
Se eu consultar www.google.com, ele falhará, mesmo que meu DNS interno possa encaminhar. Só posso supor que meu DNS interno nunca seja solicitado.

Minha correção parece continuar funcionando desde que não altere o endereço IP da rede ou do servidor DNS.

Estou um pouco confuso com isso, mas acho que funciona para mim porque, uma vez feito isso, minha NIC sem fio se torna minha conexão de rede padrão. Portanto, as consultas DNS vão para 8.8.8.8 por wifi. Qualquer consulta para "xyz.mywork.tld" é informada pelo dnsmasq para ir para 10.10.10.100. Eu configurei uma rota para isso, de modo que passe pela NIC "vpn0", que retorna o endereço IP 10.10.10.x correto para "xyz.mywork.tld". Resolução de DNS do bingo bango para redes internas e externas e todos estão felizes.

— Seanchán
fonte