☰

Проблема с подключением Fortinet/VM

tag-icon • tag-icon networking windows-10 ubuntu virtualbox virtual-machine
Проблема с подключением Fortinet/VM

У меня есть Windows 10 NUC. Я запускаю Fortinet на нем, чтобы иметь возможность удаленно работать в локальной сети моей компании. На этой машине с Windows 10 я запускаю VirtualBox и использую виртуальную машину Ubuntu 16.04. Я использую настройку NAT в виртуальной машине. Я видел несколько сайтов, где говорится, что если Fortinet запущен на хосте, я могу работать в локальной сети из виртуальной машины без необходимости какой-либо другой настройки.

Он работает, в общем-то, что еще больше раздражает, чем когда он вообще не работает. Иногда проблем не возникает. Затем, внезапно, браузер не видит сайты локальной сети, но я все еще могу подключиться по ssh к своей удаленной машине в локальной сети. Или ssh не работает, но просмотр все равно работает. Конечно, есть мой личный фаворит, когда оба не работают.

Иногда мне удается перезапустить Fortinet и VM, и все работает, но обычно требуется несколько раз, чтобы эта схема заработала. Я искал в Интернете других с похожими проблемами, но безуспешно.

Любая помощь будет оценена по достоинству.

EDIT: Из команды "/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 ######

решение1

На самом деле это не столько ответ, сколько руководство по отладке, но после многочисленных обсуждений в комментариях...

  1. Мы определили, что проблема связана с DNS, поскольку nslookupона не работала для корпоративных доменных имен.
  2. Мы определили, что resolveconf/dnsmasq использовался для DNS, поскольку nslookup пытался использовать 127.0.*.*IP-адрес в качестве своего DNS-сервера.
  3. Мы определили, что resolveconf использует Network Manager в качестве центра DNS, поскольку /usr/share/resolvconf/dump-debug-infoне содержит дополнительных записей DNS.
  4. Мы сбросили DNS-серверы, настроенные для Network Manager, запустив nmcli dev show | grep DNS. Мы заметили, что некоторые DNS-серверы добавляются при повторном подключении VPN.
  5. Мы nslookup {dns-server-ip} {dns-server-ip}просили каждый DNS-сервер идентифицировать себя по имени хоста. Мы подтвердили, что новый DNS-сервер был для корпоративной сети.
  6. Мы пришли к выводу, что DNS-серверы становились десинхронизированными между VM и Host. Гость терял корпоративные DNS-серверы, даже если VPN все еще был подключен на уровне Host. Впоследствии казалось, что доступ гостя к корпоративной сети был «сломан», даже если ping/ssh все еще работали правильно при использовании IP-адресов или кэшированных DNS-записей.

Решения:

  • Вручную добавьте DNS-серверы в сетевой менеджер, чтобы они не удалялись при неправильно обнаруженных сетевых изменениях. Более подробная информация здесь: https://askubuntu.com/questions/721080/

Связанный контент