Problema de conectividade Fortinet/VM

Problema de conectividade Fortinet/VM

Eu tenho um NUC do Windows 10. Eu executo o Fortinet nele para poder trabalhar remotamente na LAN da minha empresa. Nesta máquina Windows 10 eu executo o VirtualBox e uso uma VM Ubuntu 16.04. Estou usando a configuração NAT na VM. Já vi vários sites dizerem que se o Fortinet estiver rodando no host, posso trabalhar na LAN de dentro da VM sem nenhuma outra configuração necessária.

Funciona, mais ou menos, o que é ainda mais frustrante do que quando não funciona. Às vezes, não há problemas. Então, de repente, o navegador não vê os sites da LAN, mas ainda posso fazer ssh na minha máquina remota na LAN. Ou o ssh falha, mas a navegação ainda funciona. Claro, há o meu favorito, onde ambos falham.

Às vezes, posso reiniciar o Fortinet e a VM e tudo funciona, mas geralmente leva algumas vezes para que esse esquema funcione. Pesquisei na web por outras pessoas com problemas semelhantes, sem sucesso.

Qualquer ajuda seria apreciada.

EDIT: No comando "/usr/share/resolvconf/dump-debug-info":

###### Start of debugging information for resolvconf ######
### ls -l /etc/resolvconf
total 16
-rw-r--r-- 1 root root  511 Jun  3  2015 interface-order
drwxr-xr-x 2 root root 4096 Feb 26 19:06 resolv.conf.d
drwxr-xr-x 2 root root 4096 Feb 26 18:58 update.d
drwxr-xr-x 2 root root 4096 Feb 26 19:02 update-libc.d
### cat /etc/resolvconf/interface-order
# interface-order(5)
lo.inet6
lo.inet
lo.@(dnsmasq|pdnsd)
lo.!(pdns|pdns-recursor)
lo
tun*
tap*
hso*
em+([0-9])?(_+([0-9]))*
p+([0-9])p+([0-9])?(_+([0-9]))*
@(br|eth)*([^.]).inet6
@(br|eth)*([^.]).ip6.@(dhclient|dhcpcd|pump|udhcpc)
@(br|eth)*([^.]).inet
@(br|eth)*([^.]).@(dhclient|dhcpcd|pump|udhcpc)
@(br|eth)*
@(ath|wifi|wlan)*([^.]).inet6
@(ath|wifi|wlan)*([^.]).ip6.@(dhclient|dhcpcd|pump|udhcpc)
@(ath|wifi|wlan)*([^.]).inet
@(ath|wifi|wlan)*([^.]).@(dhclient|dhcpcd|pump|udhcpc)
@(ath|wifi|wlan)*
ppp*
*
### ls -l /etc/resolvconf/resolv.conf.d
total 4
-rw-r--r-- 1 root root   0 Jun  3  2015 base
-rw-r--r-- 1 root root 151 Jun  3  2015 head
### cat /etc/resolvconf/resolv.conf.d/base
### cat /etc/resolvconf/resolv.conf.d/head
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
### ls -l /run/resolvconf
### ls -l /run/resolvconf
total 4
-rw-r--r-- 1 root root   0 Aug 20 17:50 enable-updates
drwxr-xr-x 2 root root  60 Aug 20 17:51 interface
-rw-r--r-- 1 root root 187 Aug 20 17:51 resolv.conf
### cat /run/resolvconf/enable-updates
### cat /run/resolvconf/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 127.0.1.1
search PK5001Z
### ls -l /run/resolvconf/interface
total 4
-rw-r--r-- 1 root root 36 Aug 20 17:51 NetworkManager
### cat /run/resolvconf/interface/NetworkManager
search PK5001Z
nameserver 127.0.1.1
### ls -l /etc/resolv.conf
lrwxrwxrwx 1 root root 29 Mar  2 00:23 /etc/resolv.conf -> ../run/resolvconf/resolv.conf
### lsattr /etc/resolv.conf
lsattr: Operation not supported While reading flags on /etc/resolv.conf
### cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 127.0.1.1
search PK5001Z
### cat /etc/NetworkManager/NetworkManager.conf
[main]
plugins=ifupdown,keyfile,ofono
dns=dnsmasq

[ifupdown]
managed=false
###### End of debugging information for resolvconf ######

Responder1

Não é realmente uma resposta, mas sim um guia de depuração, mas, depois de muitas idas e vindas nos comentários ...

  1. Identificamos que o problema estava relacionado ao DNS porque nslookupnão funcionava para nomes de domínio corporativos.
  2. Identificamos que resolveconf/dnsmasq estava sendo usado para DNS porque o nslookup estava tentando usar um 127.0.*.*endereço IP como servidor DNS.
  3. Identificamos que o resolveconf estava usando o Network Manager como autoridade DNS porque /usr/share/resolvconf/dump-debug-infonão continha nenhuma entrada DNS adicional.
  4. Descartamos os servidores DNS configurados para o Network Manager executando nmcli dev show | grep DNS. Percebemos que alguns servidores DNS são adicionados quando a VPN é reconectada.
  5. Costumávamos nslookup {dns-server-ip} {dns-server-ip}pedir a cada servidor DNS que se identificasse pelo nome do host. Confirmamos que os novos servidores DNS eram para a rede corporativa.
  6. Concluímos que os servidores DNS estavam ficando dessincronizados entre a VM e o Host. O convidado perderia os servidores DNS corporativos mesmo que a VPN ainda estivesse conectada no nível do Host. Posteriormente, pareceria que o acesso do convidado à rede corporativa foi 'interrompido', embora o ping/ssh ainda funcionasse corretamente ao usar IPs ou DNS inteiros em cache.

Soluções:

  • Adicione manualmente os servidores DNS ao gerenciador de rede para que eles não sejam removidos em caso de alterações de rede detectadas incorretamente. Mais informações estão aqui: https://askubuntu.com/questions/721080/

informação relacionada