Este é o mesmo problema que aqui:Fazendo com que o openconnect vpn funcione através da interface gráfica, mas minhas adições foram excluídas e fui solicitado a criar uma nova pergunta.
Na verdade, 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 forneço meu nome de usuário e senha da VPN, ele se conecta com sucesso, 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 network-manager, embora eu tenha adicionado explicitamente o 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 ele está obtendo essas informações do concentrador VPN. Novamente, o domínio de pesquisa é atualizado corretamente. [registro abaixo]
1b. Ao conectar via sudo em um terminal, o resolv.conf é preenchido corretamente com DNS e domínios 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 sendo obtido do concentrador VPN. [registro também abaixo]
2a. Ao conectar via openconnect e network-manager, 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. Ele atualiza o domínio de pesquisa corretamente, então é provávelnãoum problema de permissões.
Faça login ao conectar usando sudo openconnect em um 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, mas ele atualiza adequadamente os servidores de nomes e o domínio de pesquisa.
Atualizar Se eu ignorar todos os avisos em resolv.conf e adicionar os servidores de nomes do concentrador VPN a ele, poderei navegar instantaneamente. É claro que assim que eu desconectar, essas alterações serão substituídas.
houve um bug nisso, em 2012, mas expirou. O problema parece ser o script vpnc.
Tentei atualizar manualmente meus scripts vpnc para as versões mais recentes, mas sem sucesso.
Algunsmais pesquisaAcontece que a partir de 12.04 o resolv.conf não é mais o local onde os servidores de nomes vão para a resolução de DNS ao usar o gerenciador de rede. É por isso que funciona quando 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 ter todo o seu tráfego DNS roteado através da VPN como no passado, você enviará apenas consultas DNS relacionadas à sub-rede e aos domínios anunciados por essa VPN.
Atualizar Desativar o dnsmasq conforme explicado no link acima resolve o problema porque /etc/resolv.conf está preenchido.
Esta não é uma solução real, é uma alternativa.
Responder1
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 Cisco VPN está enviando.
Para verificar isso, abra um terminal e execute:
tail -f /var/log/syslog
Em seguida, inicie o openconnect através do gerenciador de rede. Você verá um monte de resultados, incluindo algumas linhas como esta:
5 de dezembro 12:54:31 canoe 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 canoa NetworkManager [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 de internal.example.com
, como server.internal.example.com
.
No meu caso, preciso resolver server.example.com
(e não estava obtendo resultado algum).
A solução para mim foi acessar as configurações da VPN e adicionar example.com
um domínio de pesquisa adicional:
Não se esqueça de desconectar a VPN e reconectar para que a configuração tenha efeito.
Responder2
Portanto, resolvi isso sozinho de forma bastante satisfatória. Estou no Mint 18/Ubuntu 16.04
Meu problema foi que, depois de me conectar à VPN Openconnect por meio do NetworkManager, não consegui mais resolver DNS para domínios fora dos meus domínios de trabalho. Ou seja, perdi internet!
Minha correção foi esta:
- No NetworkManager, editei a conexão VPN em "Conexões de rede".
- Na aba IPv4, alterei 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 obtive de um "traceroute".
- Então marquei as duas opções: i. “Ignorar rotas escolhidas automaticamente” ii. "Use esta conexão apenas para recursos da sua rede"
Funciona no meu computador.
Minha compreensão do que aconteceu é que:
- Meu /etc/resolv.conf está configurado com 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, o DNS do ISP é, digamos, 8.8.8.8.
- Eu me conecto à VPN, o servidor DNS 10.10.10.100 é adicionado como um servidor adicional ao dnsmasq para ser usado para 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, então minha resolução geral da Internet desaparece. O DNS deve atingir o tempo limite e ir para o servidor DNS secundário, mas isso não acontece por algum motivo?
- Só me resta acesso à resolução DNS para "server01.mywork.tld" porque essa 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 presumir que meu DNS interno nunca é solicitado.
Minha correção parece continuar funcionando desde que meu trabalho não altere a rede ou o endereço IP do servidor DNS.
Estou um pouco confuso sobre 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 defini 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". Bingo bango Resolução DNS para redes internas e externas e todos ficam felizes.