SoftEther VPN демонстрирует странное поведение
Есть немного сложной проблемы.
Я пытаюсь настроить инфраструктуру песочницы в виртуальных виртуальных машинах для целей разработки. На данный момент есть только 3 сервера - сервер VPN-шлюза, веб-сервер Sentora (который также служит DNS-сервером для VPN) и сервер разработки API.
Все три сервера подключены друг к другу с помощью внутренней сети VirtualBox с именем "protonet". VPN-сервер имеет еще одно соединение в качестве мостового адаптера, так что внешние компьютеры могут получить к нему доступ. Это мостовое соединение является основным на VPN-сервере.
VPN-концентратор - это SecureNAT-концентратор с локальным мостом, который идет во внутреннюю сеть VBox protonet. Случайный режим включен для всех виртуальных машин и всех сетевых интерфейсов.
Подсеть для внутренней сети - 10.1.0.1-255, а подсеть для DHCP-сервера SecureNAT - 10.1.1.2-255. Сервер VPN находится на 10.1.0.2, сервер разработки API на 10.1.0.3, а сервер DNS на 10.1.0.4. Шлюз для всех серверов, кроме VPN-сервера, настроен на 10.1.0.1. Сервер VPN использует шлюз для мостового адаптера... 192.168.1.1. Сейчас я тестирую это с двумя клиентами... один сидит на 10.1.1.2, а другой на 10.1.1.3 - хост-сервер SecureNAT сидит на 10.1.1.1. Клиенты настроены на использование 10.1.1.1 в качестве шлюза, 10.1.0.4 в качестве основного DNS-сервера, а затем 8.8.4.4 в качестве вторичного DNS-сервера.
По сути, это то, что происходит. Когда VPN Virtual Hub впервые запускается / переходит в "онлайн", это не проблема. Я могу успешно пропинговать серверы с клиентского компьютера и получить доступ к различным ресурсам.
Примерно через 15-30 секунд все это останавливается, и я могу получить различные ошибки от простого тайм-аута, вплоть до ошибки отказа в прямом соединении (брандмауэры открываются по мере необходимости на серверах, а брандмауэр отключается в VPN Server). Единственное сообщение об ошибке в журналах, когда это происходит:
2017-04-28 22: 02: 26.564 [HUB "myFirstHUB"] SecureNAT: было обнаружено, что NAT режима ядра для SecureNAT можно запустить на интерфейсе "ipv4_rawsocket_virtual_router". NAT в режиме ядра запускается. В дальнейшем обработка TCP, UDP и ICMP NAT будет выполняться с высокой производительностью через Kernel-Mode. Параметры режима ядра NAT: IP-адрес = "10.171.7.254", маска подсети = "255.255.255.252", шлюз по умолчанию = "10.171.7.253", широковещательный адрес = "10.171.7.255", виртуальный MAC-адрес: "DA-3C-D5-82-9D-0E", адрес сервера DHCP: "10.171.7.253", адрес сервера DNS: "192.168.1.1"
Еще более странным является то, что, хотя все это работает, клиентские IP-адреса нельзя пропинговать ни с VPN-шлюза, ни с какого-либо сервера за ним... даже когда они могут пинговаться и успешно использоваться самими клиентами, После разрыва соединения клиент все еще может пропинговать хост-компьютер - но только потому, что он, скорее всего, также использует с ним сеть 192.168.1.1.
На этом этапе я почти все перепробовал: - удаление конфигурации сервера и начало с нуля - проверка того, что клиенты по-прежнему подключены к самому концентратору (они есть) - проверка событий Windows для журналов (показаны только журналы для жаловаться, что ПК не является главным браузером, но они несовместимы с тем, когда все функции на самом деле прекращаются. - Попытался открыть сервер в режиме принудительного пользователя (т.е. вместо запуска службы vpnserver, используя cd /usr/local/vpnserver;./ запуск vpnserver) - перезагрузка виртуальных машин в инфраструктуре, а также самой физической машины (фактически, это делалось несколько раз) - полностью попытался создать новый виртуальный концентратор - попытался изменить всю подсеть SecureNAT - попытался удалить локальный мост
Может ли кто-нибудь потенциально иметь дальнейшее понимание того, что вызывает эту странную проблему? Я сильно подозреваю, что это как-то связано с автоматическим переходом в режим ядра и получением этих странных 10-точечных IP-адресов, но я не знаю, происходит ли это из-за чего-то другого, что также вызывает проблемы с соединением, или же из-за этого, Я не нахожу в Google ничего относительно того, что мне следует делать, чтобы это не происходило / не принимал надлежащие IP-адреса SecureNET в качестве настроек в SecureNAT.
Благодарю.