obtendo o openconnect vpn para trabalhar através do network-manager

Question

este é o mesmo problema que aqui: Obtendo o vconn openconnect para funcionar através do gui , mas minhas adições foram excluídas e me pediram para criar uma nova pergunta.

de fato, há um número de pessoas fazendo perguntas semelhantes aqui, todas com 0 respostas.

versões do software: ubuntu 14.04, openconnect 5.02

principal problema: 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 sucesso, mas não consigo resolver dns.

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

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

mais detalhes:

1a. ao se conectar via openconnect e network-manager, mesmo que eu tenha explicitamente adicionado dns e um domínio de busca sob a aba ipv4, somente o domínio de busca termina em /etc/resolv.conf. Mesmo que eu não forneça DNS e procure domínios, eu posso ver nos logs que está obtendo essa informação do concentrador de VPN. novamente, o domínio de pesquisa é atualizado corretamente. [log abaixo]

1b. ao se conectar via sudo on 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 recebendo do concentrador de vpn. [log 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-se através do 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, portanto, é provável que não seja emitido 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, ainda assim, atualiza corretamente os servidores de nomes e o domínio de pesquisa.

atualização se eu ignorar todos os avisos no resolv.conf e adicionar os servidores de nomes do concentrador vpn a ele, sou instantaneamente capaz de navegar. É claro que, assim que eu me desconectar, essas alterações serão sobrescritas.

houve um bug neste , 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 até que a partir de 12.04 resolv.conf não é mais 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 network-manager. em vez disso, o servidor de nomes 127.0.1.1 [dnsmasq] é adicionado e esse servidor de nomes é informado dos endereços IP dos verdadeiros servidores de nomes.

  

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

atualização desabilitar o dnsmasq como explicado no link acima resolve o problema porque o /etc/resolv.conf está preenchido.

esta não é uma solução real, embora seja uma alternativa.

    

Answer 1

Verifique se existe uma incompatibilidade entre o host que você está tentando resolver via 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 pelo gerenciador de rede. Você verá um monte de resultados, incluindo algumas linhas como esta:

  

Dec 5 12:54:31 canoa NetworkManager [1266]: DNS Interno: 10.0.20.21

     

Dec 5 12:54:31 canoa NetworkManager [1266]: DNS Interno: 10.10.3.32

     

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

E mais abaixo você verá

  

Dec 5 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 em internal.example.com , como server.internal.example.com .

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

A solução para mim foi entrar nas configurações de VPN e adicionar example.com como um domínio de pesquisa adicional:

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

    

Answer 2

Então, resolvi isso satisfatoriamente para mim. Eu estou no Mint 18 / Ubuntu 16.04

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

Minha correção foi esta:

1. No NetworkManager, editei a conexão VPN em "Conexões de rede".
2. Na guia IPv4, o método mudou para "Somente endereços automáticos (VPN)"
3. Adicionado o meu servidor DNS de trabalho (por exemplo, 10.10.10.100) e "Domínio de pesquisa" de "mywork.tld"
4. Clique em "Rotas".
5. Adicione um trajeto que cubra minha rede de trabalho, por exemplo 10.10.0.0 / 255.255.0.0 e gateway de 10.10.10.253 & lt; - gateway VPN que obtive de um "traceroute".
6. Então marquei as duas opções: Eu. "Ignorar rotas optadas automaticamente" ii. "Use esta conexão somente para recursos em sua rede"

Funciona no meu computador.

Meu entendimento do que aconteceu é que:

1. Meu /etc/resolv.conf está configurado com o dnsmasq e está apontando para 127.0.1.1
2. O dnsmasq está usando os servidores DNS do meu ISP para a resolução geral de DNS da Internet. Por exemplo, o DNS do ISP é digamos 8.8.8.8.
3. 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 de DNS "mywork.tld".
4. Quando estou na VPN, meu firewall de trabalho não permite mais que eu use a porta 53 a 8.8.8.8, então minha resolução geral de internet desaparece. O DNS deve expirar e ir para o servidor DNS secundário, mas isso não acontece por algum motivo?
5. Só tenho acesso à resolução de DNS para "server01.mywork.tld" porque esta consulta vai para 10.10.10.100 à qual tenho acesso através da VPN.
6. Se eu pesquisar por www.google.com, ele falhará, embora meu DNS interno possa encaminhar. Eu só posso supor que o 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 Wireless se torna minha conexão de rede padrão. Então, as consultas do DNS vão para 8.8.8.8 através do wifi. Qualquer consulta para "xyz.mywork.tld" é informada pelo dnsmasq para ir para 10.10.10.100. Eu configurei uma rota para isso, então isso vai até a "vpn0" NIC que retorna o endereço IP 10.10.10.x correto para "xyz.mywork.tld". Bingo bango resolução de DNS para redes internas e externas e todo mundo está feliz.