Подключенный сетевой диск не может быть удален, но отображается в Проводнике; подключается к неверному серверу

Question

Это самая странная проблема, с которой я когда-либо сталкивался.

Сводка: сопоставленный сетевой диск сохраняется в проводнике Windows и не может быть удален / отключен (утверждает, что он не существует; сетевое использование ничего не показывает; сетевое использование диска: / delete не работает на нем). Как ни странно, подключенный диск подключается через некоторое время, несмотря на то, что требуемое VPN-подключение не подключено. Даже странно, что он подключается к не тому серверу, что должно быть невозможно, учитывая, что подключенный диск не может даже идентифицировать его без активного подключения VPN.

Подробности...

У меня было два подключенных сетевых диска.

Каждый из них установил соединение через VPN с совершенно разными серверами. Один был сопоставлен с (Z:) 192.168.1.2, а другой - с (W:) 192.168.2.1, так как каждый VPN-сервер установил свой диапазон для своих клиентов VPN (192.168.1. * Против 192.168.2.*). Обратите внимание, что это не локальные компьютеры, а удаленные серверы, которые отображаются, когда локальная сеть активна, с использованием функции маршрутизации и удаленного доступа Windows Server 2012. Сервер "IT" зарекомендовал себя как 192.168.1.2, а сервер "WW" как 192.168.2.1, и это совершенно разные серверы с разными / разными адресами WAN, хотя они находятся в одном и том же центре виртуального хостинга.

Оба подключенных диска работали, как ожидалось, когда обе VPN были активны

Когда я перезапустил свой клиентский компьютер (Windows 7), очевидно, что обе VPN неактивны, но один из дисков (Z:) 192.168.1.2 через некоторое время устанавливает соединение, несмотря на отсутствие активной VPN.

Как ни странно, он подключается к неправильному серверу "WW" вместо "IT", и я подтвердил это, создав файл на подключенном диске (WTF.txt) в проводнике и подтвердив, что он был успешно создан на сервере. сервер, войдя в систему через удаленный рабочий стол и перейдя к физической папке.

Это абсолютно не имеет смысла для меня. VPN не активен, поэтому при сопоставлении диска с адресом локальной сети, таким как 192.168.1.2, который не должен существовать, когда VPN неактивен, как это происходит, когда подключенный диск не только может найти удаленный сервер в другой части состояние, но также установить связь с ним? Почему он сохраняется в проводнике Windows, несмотря на то, что он был удален / отключен.

Интересно, что если я активирую VPN и снова сопоставлю диск с той же буквой и тем же адресом локальной сети (192.168.1.2), он устанавливает соединение с правильным сервером и снова отображается как активный в проводнике Windows. Он по-прежнему сохраняется, даже если я отключаю / удаляю его после выполнения этого ... это похоже на то, что в проводнике Windows была встроена какая-то стабильная червоточина, связывающая подключенный диск с неверным сервером, и он продолжает восстанавливаться после перезагрузки компьютера.

Answer 1

Я понял.

Прежде всего, диск должен быть подключен, чтобы удалить его. Кажется, это общая проблема с подключенными дисками в Windows.

Во-вторых, причина, по которой Клиент смог подключиться к Серверу B, несмотря на то, что единственная активная VPN от Клиента была к Серверу A, заключается в том, что Сервер B также установил VPN-соединение с Сервером A, используя ту же учетную запись, что и Клиент.

Проблема заключалась в странном конфликте VPN-адресов, который возник не только из-за использования одной и той же учетной записи для двух разных клиентов, но и в порядке, в котором они подключались, и из-за того, что выбранные резервные адреса окон конфликтовали с адресом адаптера обратной петли сервера.

Обычно каждый клиент и сервер 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-адреса, за исключением того, что когда они подключены к одной и той же учетной записи, у него не было другого выбора, кроме как вернуться к чему-то в допустимом диапазоне.