☰

Problema de conectividad Fortinet/VM

tag-icon • tag-icon networking windows-10 ubuntu virtualbox virtual-machine
Problema de conectividad Fortinet/VM

Tengo un NUC con Windows 10. Ejecuto Fortinet para poder trabajar en la LAN de mi empresa de forma remota. En esta máquina con Windows 10 ejecuto VirtualBox y uso una máquina virtual Ubuntu 16.04. Estoy usando la configuración NAT en la VM. He visto varios sitios que dicen que si Fortinet se está ejecutando en el host, puedo trabajar en la LAN desde la VM sin necesidad de otra configuración.

Funciona, más o menos, lo cual es incluso más frustrante que cuando no funciona en absoluto. A veces no hay problemas. Luego, de repente, el navegador no ve los sitios de la LAN, pero aún puedo acceder a mi máquina remota en la LAN. O bien, ssh falla pero la navegación aún funciona. Por supuesto, está mi favorito personal en el que ambos fallan.

A veces, puedo reiniciar Fortinet y la VM y todo funciona, pero normalmente este esquema tarda varias veces en funcionar. He buscado en la web otros con problemas similares sin éxito.

Cualquier ayuda sería apreciada.

EDITAR: Desde el 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 ######

Respuesta1

Realmente no es tanto una respuesta como una guía de depuración, pero, después de muchos comentarios de ida y vuelta...

  1. Identificamos que el problema estaba relacionado con el DNS porque nslookupno funcionaba para nombres de dominio corporativos.
  2. Identificamos que resolveconf/dnsmasq se estaba usando para DNS porque nslookup estaba intentando usar una 127.0.*.*dirección IP como su servidor DNS.
  3. Identificamos que resolveconf estaba usando Network Manager como autoridad DNS porque /usr/share/resolvconf/dump-debug-infono contenía ninguna entrada DNS adicional.
  4. Desechamos los servidores DNS configurados para Network Manager ejecutando nmcli dev show | grep DNS. Notamos que se agregan algunos servidores DNS cuando se vuelve a conectar la VPN.
  5. Solíamos nslookup {dns-server-ip} {dns-server-ip}pedirle a cada servidor DNS que se identificara por nombre de host. Confirmamos que el nuevo servidor DNS era para la red corporativa.
  6. Llegamos a la conclusión de que los servidores DNS se estaban desincronizando entre la VM y el Host. El invitado perdería los servidores DNS corporativos aunque la VPN todavía estuviera conectada en el nivel del Host. Posteriormente, parecería que el acceso del invitado a la red corporativa estaba "roto" a pesar de que ping/ssh todavía funcionaba correctamente cuando se usaban direcciones IP o DNS en caché.

Soluciones:

  • Agregue manualmente los servidores DNS al administrador de red para que no se eliminen si se detectan cambios de red incorrectamente. Más información está aquí: https://askubuntu.com/questions/721080/

información relacionada