☰

Fortinet/VM-Konnektivitätsproblem

tag-icon • tag-icon networking windows-10 ubuntu virtualbox virtual-machine
Fortinet/VM-Konnektivitätsproblem

Ich habe einen Windows 10 NUC. Ich verwende Fortinet darauf, damit ich remote im LAN meines Unternehmens arbeiten kann. Auf dieser Windows 10-Maschine verwende ich VirtualBox und verwende eine Ubuntu 16.04 VM. Ich verwende die NAT-Einstellung in der VM. Ich habe auf mehreren Websites gelesen, dass ich, wenn Fortinet auf dem Host läuft, innerhalb der VM im LAN arbeiten kann, ohne dass eine weitere Konfiguration erforderlich ist.

Es funktioniert, mehr oder weniger, was noch frustrierender ist, als wenn es überhaupt nicht funktioniert. Manchmal gibt es keine Probleme. Dann sieht der Browser plötzlich die LAN-Sites nicht, aber ich kann mich trotzdem per SSH mit meinem Remote-Rechner im LAN verbinden. Oder SSH schlägt fehl, aber das Surfen funktioniert trotzdem. Natürlich gibt es noch meinen persönlichen Favoriten, bei dem beide fehlschlagen.

Manchmal kann ich Fortinet und die VM neu starten und alles funktioniert, aber normalerweise dauert es ein paar Mal, bis dieses Schema funktioniert. Ich habe im Internet nach anderen mit ähnlichen Problemen gesucht, aber ohne Erfolg.

Jede Hilfe wäre willkommen.

BEARBEITEN: Aus dem Befehl „/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 ######

Antwort1

Nicht wirklich eine Antwort, eher eine Anleitung zur Fehlerbehebung, aber nach vielem Hin und Her in den Kommentaren …

  1. Wir haben festgestellt, dass das Problem mit DNS zusammenhing, da nslookupes für Unternehmensdomänennamen nicht funktionierte.
  2. Wir haben festgestellt, dass resolveconf/dnsmasq für DNS verwendet wurde, weil nslookup versucht hat, eine 127.0.*.*IP-Adresse als DNS-Server zu verwenden.
  3. Wir haben festgestellt, dass resolveconf Network Manager als DNS-Autorität verwendet hat, da /usr/share/resolvconf/dump-debug-infoes keine zusätzlichen DNS-Einträge enthielt.
  4. Wir haben die für Network Manager konfigurierten DNS-Server durch Ausführen von gelöscht nmcli dev show | grep DNS. Wir haben festgestellt, dass einige DNS-Server hinzugefügt werden, wenn die VPN-Verbindung wiederhergestellt wird.
  5. Wir haben nslookup {dns-server-ip} {dns-server-ip}jeden DNS-Server aufgefordert, sich über den Hostnamen zu identifizieren. Wir haben bestätigt, dass der neue DNS-Server für das Unternehmensnetzwerk bestimmt war.
  6. Wir kamen zu dem Schluss, dass die DNS-Server zwischen der VM und dem Host nicht mehr synchronisiert waren. Der Gast verlor die DNS-Server des Unternehmens, obwohl auf Hostebene noch eine VPN-Verbindung bestand. Anschließend schien der Zugriff des Gastes auf das Unternehmensnetzwerk „unterbrochen“ zu sein, obwohl Ping/SSH bei Verwendung von IPs oder zwischengespeicherten DNS-Einträgen noch immer ordnungsgemäß funktionierte.

Lösungen:

  • Fügen Sie die DNS-Server manuell zum Netzwerkmanager hinzu, damit sie bei fälschlicherweise erkannten Netzwerkänderungen nicht entfernt werden. Weitere Informationen finden Sie hier: https://askubuntu.com/questions/721080/

verwandte Informationen