У меня есть система (SYSTEMX), которая подключена к нашей сети через VPN. Периодически VPN отключается, и SYSTEMX теряет соединение с сетью. Когда это происходит, я обычно легко узнаю об этом из журнала, созданного во время ночной задачи, которая дает сбой из-за того, что система находится в автономном режиме.
Я пингую систему "ping SYSTEMX" и получаю таймауты, как и ожидалось. Переподключаю VPN и все готово.
Однако дважды в журнале регистрировались разные результаты, поскольку появлялась новая система (SYSTEMSTEALTH) и разрешалась по тому же IP-адресу, который был предоставлен SYSTEMX.
Я пингую «ping SYSTEMX» и, о чудо, приходят ответы.
Когда я выполняю «nslookup SYSTEMX» и «nslookup SYSTEMSTEALTH», оба имени преобразуются в один и тот же IP-адрес.
Я не эксперт по топологии сети, однако мне кажется, что при распределении новой аренды DHCP необходимо связаться с сервером имен для удаления устаревших записей для этого адреса, чтобы предотвратить подобный сценарий.
Есть ли у кого-нибудь предложения или кто-нибудь может прояснить способ предотвращения этого? Я работаю со своим ИТ-отделом, чтобы решить эту проблему, их текущая позиция заключается в том, что все в порядке, поскольку SYSTEMX не находится в сети, SYSTEMSTEALTH подключается позже, и все хорошо. Однако возможность "ping SYSTEMX", подключение к нему, предоставление общего доступа к файлам с использованием административных ресурсов; это не кажется мне правильным, поскольку SYSTEMX на самом деле SYSTEMSTEALTH.
Спасибо за помощь.
решение1
Происходит следующее: решение VPN регистрирует новую запись PTR каждый раз, когда предоставляется новое соединение. Это также может произойти в любой среде, где разрешены динамические обновления DNS, кстати. Поэтому, когда вы делаете запрос на основе IP, есть несколько записей PTR, потому что, как было указано, старые не были очищены. Поэтому, когда вы делаете nslookup на основе IP, вы получаете одну из записей PTR, которая может не соответствовать правильному имени компьютера.
Как уже упоминалось, если DNS-сервер настроен на очистку, в конечном итоге старые записи PTR будут очищены, хотя это и требует времени. Например, это может занять несколько недель в конфигурации DNS по умолчанию Windows Server 2003 (после включения очистки).
И как уже упоминалось, мы обнаружили, что резервирование DHCP было способом в тех случаях, когда это действительно имело для нас значение. В случаях, когда это не имело значения, мы пинговали IP, проверяли его, а затем делали nbtstat -aайпи адресчтобы увидеть, что на самом деле отвечает система Windows на этом IP-адресе.
решение2
Записи DNS будут очищены, но для репликации этих изменений может потребоваться время в зависимости от сложности вашей топологии. В этом сценарии имеет смысл настроить резервирование, чтобы гарантировать, что ваш IP-адрес для SYSTEMX зарезервирован только для этой машины.
решение3
Это распространенная проблема с решениями для удаленного доступа. Предполагается, что сквозной DHCP должен решать эту проблему, но он часто не используется из-за меньшей надежности, чем использование встроенного DHCP продукта VPN. Многие из этих встроенных продуктов не сообщают соответствующим записям DNS об удалении при отключении клиента.
Чтобы помочь с этим, некоторые люди добавляют ipconfig /registerdns в конец своих скриптов входа, которые выполняются при успешном подключении VPN, однако это все равно не удаляет старую плохую запись. Я не знаю третьей стороны, которая решает эту проблему в настоящее время, и в результате я обычно заставляю клиента подтверждать свой IP-адрес.
решение4
Конечно, это очень распространенная проблема. На сайте Synergix www.synergix.com есть официальный документ по этой теме. По сути, идея заключается в том, чтобы клиентская машина сама управляла процессом удаления любых ранее зарегистрированных записей. Таким образом, вам не придется перенастраивать интервал очистки DNS на тот, который вы могли установить. Программное обеспечение Active Directory Client Extensions от Synergix элегантно выполнит эту работу.
ДД