Я понял. Вот иллюстрация, сопровождаемая текстовым объяснением того, что продолжалось.
Прежде всего, любой подключенный диск должен быть подключен, чтобы удалить его. Кажется, это общая проблема с подключенными дисками в Windows.
Во-вторых, причина, по которой Клиент смог подключиться к Серверу B, несмотря на то, что единственный активный VPN-клиент от Клиента был к Серверу A, заключается в том, что Сервер B также установил VPN-соединение с Сервером A, используя ту же учетную запись Windows, что и Клиент.
Проблема заключалась в странном конфликте VPN-адресов, который возник не только из-за использования одной и той же учетной записи для двух разных клиентов ("Клиент" и "Сервер B"), но и в порядке, в котором они подключались, и из-за выбора окон резервных адресов. конфликтует с адресом адаптера обратной петли сервера.
Обычно каждый клиент и сервер B имеют свою собственную учетную запись пользователя для подключения к VPN на сервере A, и каждый из них имеет разные статические IP-адреса, назначенные на вкладке Dial-In учетных записей пользователей, поэтому обычно каждый клиент и сервер B получают их собственный статический IP без каких-либо конфликтов.
По какой-то причине, вместо того, чтобы использовать собственную учетную запись Сервера B, я использовал учетную запись клиента для подключения, которая в основном является моей основной учетной записью пользователя ... простая ошибка. Я заметил это в RRAS, когда увидел, что два клиента были подключены под одним и тем же именем пользователя. Я знаю, что одна была моей клиентской машиной, но другая была активна более 900 часов. Тогда я понял, что это должен быть сервер B, подключающийся к серверу A, но он не смог использовать свою собственную учетную запись пользователя.
Так вот где стало интересно. Некоторое время назад, 900+ часов, клиент должен был сначала подключиться и получить правильный статический IP: 192.168.1.101. Затем сервер B должен был впоследствии подключиться, пока VPN-клиент был еще активен, и, поскольку клиент уже вошел в систему под той же учетной записью, ему не удалось назначить выбранный статический IP-адрес, поэтому Windows просто решила вернуться к следующему IP-адресу. доступны в диапазоне статических маршрутов, который оказался 192.168.1.2. Таким образом, сервер B теперь имеет IP-адрес VPN 192.168.1.2. Что было бы хорошо, кроме ...
Это проблема, потому что это IP (192.168.1.2), который я назначил для петлевого адаптера Сервера А. Предполагается, что это IP-адрес, который я использую для доступа к серверу A в VPN, когда клиент подключен, за исключением того, что теперь сервер B считает, что это также 192.168.1.2.
Так что произошел необнаружимый конфликт IP-адресов, который объясняет странное поведение. А именно, что когда я впервые подключился к VPN для Сервера A, адрес 192.168.1.2 был маршрутизирован к Серверу B, и если я просто отключил и снова подключил диск к тому же IP, он обнаружил бы Сервер A. Я не уверен, как Windows принимает решение, к какому компьютеру подключаться, когда клиент RRAS и адаптер Microsoft Loopback в конечном итоге назначают один и тот же IP-адрес.
Честно говоря, это глупая ошибка в Windows Server, поскольку сервер RRAS должен был знать, что он не назначает IP-адрес в заданном диапазоне, который уже был занят другим адаптером (адаптером обратной связи). Возможно, он только отслеживает IP-адреса и проверяет наличие конфликтов с IP-адресами, которые он назначает сам, и не имеет никакого способа узнать, используют ли уже существующие адаптеры IP-адрес в допустимом диапазоне.
Все это было странное сочетание событий ... Сервер B подключился после того, как сервер A использовал ту же учетную запись, а не свою собственную, поскольку статический IP-адрес для этой учетной записи уже был занят, RRAS затем тупо назначил ему IP-адрес из допустимого диапазона, без предварительной проверки на конфликты, и это закончилось предоставление серверу B того же IP-адреса, что и у петлевого адаптера сервера A. Затем, когда клиент попытался получить доступ к этому IP-адресу, Windows сначала увидела, что это был сервер B, но отключение / повторное подключение сопоставленного диска к тому же IP-адресу затем разрешило бы сервер A. Невероятно странно.
В любом случае все, что мне нужно сделать, это увеличить допустимый диапазон от 192.168.1.1 до 192.168.1.3, поэтому он никогда не назначает свой статический IP-адрес каким-либо клиентам, чего не должно было случиться, учитывая, что все они были назначены своим собственные статические IP-адреса, за исключением того, что когда они подключены к одной и той же учетной записи, у него не было другого выбора, кроме как вернуться к чему-то в допустимом диапазоне.
