Защо име на сървър се преобразува в неговия VPN адрес след комутируем достъп

Офис файлов сървър отговаря на LAN адреса си цяла сутрин, после отдалечен потребител се включва по телефон и името започва да се преобразува в адрес на тунел вместо това. В DNS нищо не е редактирано на ръка и това е уликата: записът е публикуван от самата машина. Три условия решават дали да поправите регистратора, записа или представата на клиента, а грешният ред означава, че записът ще се върне след следващата връзка.

Два адреса, едно име, три условия

Windows сървър с няколко интерфейса може да има LAN адрес, един или повече адреси за комутируем достъп и понякога втори мрежов адаптер. Всеки интерфейс може да регистрира собствените си адреси в DNS, ако за него е разрешена динамична регистрация. Когато PPP адаптерът се регистрира, същото име на хост получава адрес, до който може да достигне само партньорът на тунела, а LAN клиентите го получават като валиден отговор.

Три условия решават поправката. Първо, достъпен ли е допълнителният адрес от клиентите, които го получават? Второ, зависи ли още някой консуматор от тази регистрация? Трето, записът динамичен ли е и следователно може да се върне, или е статичен и следователно умишлен запис?

Отговорете на тези въпроси, преди да пипате нещо. Ако адресът е недостъпен от мрежата, която прави заявката, никакво изчистване на клиентския кеш няма да го поправи за дълго. Ако нещо зависи от него, например път за управление, използван от самите партньори на тунела, премахването му вместо това чупи този път. А динамичен запис, изтрит без да се адресира неговият публикуващ, ще се появи отново при следващото събитие по регистрация.

Прочетете записа, преди да смените регистратора

Направете заявка за точното напълно квалифицирано име от мрежата, която съобщава проблема, и сравнете отговорите с действителните интерфейси и слушатели на сървъра. Едно име, което връща няколко адреса, е нормално; въпросът е дали всеки от тях е използваем от клиента, който го получава.

dig +short files.corp.example A
dig @10.20.0.10 +short files.corp.example A
Resolve-DnsName files.corp.example -Server 10.20.0.10 -Type A

Първата заявка използва локалния резолвер, втората пита конкретен DNS сървър директно, а третата прави същото от PowerShell в Windows. Сравняването им отделя стария клиентски кеш от авторитетния отговор. Ако директната заявка вече връща адреса на тунела, проблемът е в публикуваните данни, а не в локалното кеширане.

Запишете времевата марка на записа и дали DNS конзолата го показва като динамичен. Този единствен атрибут ви казва кое от трите условия по-горе се прилага и това е разликата между петминутно почистване и поправка, която издържа.

Поправете публикуващия или записа, но знайте кое

Ако записът е динамичен и нежелан, трайната поправка е да спрете този интерфейс да се регистрира. Windows предлага настройки за регистрация за всеки интерфейс, а DNS клиентската услуга публикува отново при следващата връзка или промяна на адреса. Изключването на регистрацията за адаптера за комутируем достъп оставя регистрацията на LAN адаптера непокътната, което обикновено е желаното.

Внимавайте с превключватели за цялата машина. Глобална настройка, която изключва динамичното обновяване, засяга всеки интерфейс на този хост, включително този, на чиято регистрация разчитат други клиенти. На контролер на домейн същото предупреждение важи с по-голяма сила, защото хостът може да притежава и записи за местоположение на услуги, от които клиентите зависят за вход.

Ако записът е статичен, той е поставен там умишлено и разговорът е с този, който го е поставил. Изтриването на статичен запис, защото днес е неудобен, премахва единственото доказателство защо съществува. И в двата случая изтрийте стария отговор само след като публикуващият е обработен, и запишете какво сте променили, за да може следващият човек да различи умишлен запис от случайност.

Проверете от клиентската мрежа, която се провали

Проверката принадлежи на мрежата, която съобщи симптома, а не на сървъра. Изчистете кеша на клиентския резолвер чрез поддържания механизъм, после повторете първоначалната заявка и първоначалната връзка към услугата по име.

ipconfig /flushdns
ipconfig /displaydns | findstr /i files.corp.example

Първата команда изчиства кеша на Windows резолвера, а втората показва дали името отново е кеширано и кой адрес е запазен. Успешна връзка от сървъра към себе си не доказва нищо за LAN клиент, а премахването на маршрут към нежелания адрес не поправя това, което DNS публикува.

Накрая повторете събитието, което преди въвеждаше адреса: свържете отново VPN клиента или подновете сесията за комутируем достъп. Проверете публикуваното име отново след тази промяна в жизнения цикъл. Поправка, която издържа само до следващата връзка, беше почистване, а не поправка, и знанието кое от двете сте направили е разликата между затваряне на тикета и отварянето му отново следващата седмица.