Когда я \\192.168.1.2\ в проводнике Windows на своем рабочем столе, он подключается к другому серверу на полпути через штат Пенсильвания, и я понятия не имею, как.

Я понятия не имею, как он переводит адрес 192.168.1.2 на удаленный сервер.

Я запустил команду "route print" в командной строке Windows, и там ничего не указывает на удаленный сервер.

Кто-нибудь знает, как это возможно или где Windows может хранить информацию, необходимую для установления этого соединения?

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

Может ли быть проблема с кэшированием моего коммутатора D-LINK?

ОБНОВЛЕНИЕ: я выполнил команду netstat -an для просмотра списка всех активных соединений и заметил, что единственное нераспознанное соединение - через порт 445, но оно указано в качестве адреса IPV6. Я предполагаю, что речь идет об удаленном сервере, но как и почему Windows сохранила этот адрес?

1 ответ1

0

Я понял. Вот иллюстрация, сопровождаемая текстовым объяснением того, что продолжалось.

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

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .