SoftEther VPN zeigt ein bizarres Verhalten

Habe ein komplexes Problem.

Ich versuche, eine Sandbox-Infrastruktur für virtuelle Box-VMs für Entwicklungszwecke einzurichten. Im Moment gibt es nur drei Server - den VPN Gateway Server., Den Sentora Webserver (der auch als DNS-Server für das VPN dient) und den API Development Server.

Alle drei Server sind über ein internes VirtualBox-Netzwerk mit dem Namen "Protonet" miteinander verbunden. Der VPN-Server verfügt über eine weitere Verbindung als überbrückter Adapter, sodass externe Computer darauf zugreifen können. Diese überbrückte Verbindung ist die primäre Verbindung auf dem VPN-Server.

Der VPN-Hub ist ein SecureNAT-Hub mit einer lokalen Brücke, die zum internen Netzwerk der 'protonet' VBox führt. Der Promiscuous-Modus ist für alle VMs und alle Netzwerkschnittstellen aktiviert.

Das Subnetz für das interne Netzwerk ist 10.1.0.1-255 und das Subnetz für den SecureNAT-DHCP-Server ist 10.1.1.2-255. Der VPN-Server befindet sich um 10.1.0.2, der API-Entwicklungsserver unter 10.1.0.3 und der DNS-Server unter 10.1.0.4. Das Gateway für alle Server außer dem VPN-Server ist auf 10.1.0.1 eingestellt. Der VPN-Server verwendet das Gateway für den Bridged-Adapter ... 192.168.1.1. Im Moment teste ich dies mit zwei Clients ... einer sitzt bei 10.1.1.2 und der andere bei 10.1.1.3 - der SecureNAT-Host-Server steht bei 10.1.1.1. Clients sind so konfiguriert, dass 10.1.1.1 als Gateway, 10.1.0.4 als primärer DNS-Server und dann 8.8.4.4 als sekundärer DNS-Server verwendet werden.

Im Grunde ist das, was passiert. Wenn der VPN Virtual Hub zum ersten Mal gestartet wird und "Online" wird, gibt es kein Problem. Ich kann die Server erfolgreich vom Client-Computer aus pingen und auf die verschiedenen Ressourcen zugreifen.

Nach etwa 15 bis 30 Sekunden hört das alles auf, und ich kann verschiedene Fehler von einem einfachen Timeout bis hin zu einem Flat-Out-Verbindungsfehler zurückweisen (Firewalls werden nach Bedarf auf den Servern geöffnet, und die Firewall wird auf dem VPN deaktiviert Server). Die einzige Fehlermeldung in den Protokollen lautet:

2017-04-28 22: 02: 26.564 [HUB "myFirstHUB"] SecureNAT: Es wurde festgestellt, dass das Kernelmodus-NAT für SecureNAT auf der Schnittstelle "ipv4_rawsocket_virtual_router" ausgeführt werden kann. Der Kernelmodus-NAT wird gestartet. Die TCP-, UDP- und ICMP-NAT-Verarbeitung wird im Kernel-Modus mit hoher Leistung ausgeführt. Die Parameter des Kernel-Modus-NAT: IP-Adresse = "10.171.7.254", Subnet Mask = "255.255.255.252", Standard-Gateway = "10.171.7.253", Broadcast-Adresse = "10.171.7.255", Virtuelle MAC-Adresse: "DA" -3C-D5-82-9D-0E ", DHCP-Serveradresse:" 10.171.7.253 ", DNS-Serveradresse:" 192.168.1.1 "

Noch seltsamer ist, dass die Client-IPs auch dann nicht von dem VPN-Gateway oder von den dahinterliegenden Servern per Ping angesprochen werden können, selbst wenn sie alle funktionieren. Selbst wenn sie von den Clients selbst per Ping gesendet und erfolgreich verwendet werden können . Nachdem die Verbindung unterbrochen wurde, kann der Client immer noch ein Ping-Signal an den Host-Computer senden - allerdings nur, weil er auch das 192.168.1.1-Netzwerk verwendet, höchstwahrscheinlich.

Ich habe an diesem Punkt so ziemlich alles versucht: - Löschen der Serverkonfiguration und Starten von vorne - Überprüfen, ob die Clients noch mit dem Hub selbst verbunden sind (sie sind es) - Geprüfte Windows-Ereignisanzeige für Protokolle (Die einzigen angezeigten Protokolle gelten für sich darüber beschweren, dass der PC nicht der Master-Browser ist, diese jedoch inkonsistent sind, wenn die Funktionalität tatsächlich angehalten wird) - Versuchtes Öffnen des Servers im erzwungenen Benutzermodus (dh anstelle des Dienstes vpnserver start verwenden Sie cd /usr/local/vpnserver ;./ vpnserver start) - Neustart der VMs in der Infrastruktur sowie der physischen Maschine selbst (dies ist tatsächlich mehrmals geschehen) - Versucht, einen neuen virtuellen HUB vollständig zu erstellen - Versucht, das gesamte SecureNAT-Subnetz zu ändern - Versucht, die lokale Brücke zu entfernen

Könnte jemand möglicherweise weitere Einsichten darüber haben, was dieses seltsame Problem verursacht? Ich vermute stark, dass es etwas damit zu tun hat, dass es automatisch in den Kernel-Modus geht und diese seltsamen 10-Punkt-IPs erhält, aber ich weiß nicht, ob dies auf etwas anderes zurückzuführen ist, das auch Verbindungsprobleme verursacht oder ob es dazu führt. Bei Google finde ich nichts darüber, was ich tun sollte, um zu verhindern, dass dies geschieht, und die richtigen SecureNET-IP-Adressen als in SecureNAT einzurichten.

Vielen Dank.

Vernetzungsdiagramm.