Резервная аренда после возврата туннеля площадки: обновить или подождать?

Канал площадки поднят, туннель установлен, а компьютеры филиала по-прежнему не достают до файлового сервера. Во время сбоя шли двое часов, и только одни из них закончились. Туннель восстановился, когда вернулся шифрованный путь; адрес каждого клиента восстанавливается, когда его текущая аренда заканчивается или заменяется. Сравнение этих двух временных шкал объясняет разрыв быстрее, чем чтение журналов межсетевого экрана.

Двое часов, и одни из них — не туннель

С DHCP поверх VPN и локальным резервом устройство может выдавать временные локальные аренды, пока удалённый путь DHCP недоступен. Временная длительность обычно считается в минутах: этого достаточно мало, чтобы скрыть проблему, и достаточно много, чтобы пережить короткий сбой. Когда туннель возвращается, резерв перестаёт предлагать такие аренды. Он не заходит в клиент и не отменяет аренду, которую тот уже держит. Этот клиент сохраняет адрес, маску, шлюз и резолвер до обновления или истечения срока, и поэтому здоровый туннель и сломанный компьютер могут сосуществовать до конца аренды.

Держите реализацию и версию программного обеспечения привязанными к этому утверждению. Имена таймеров и значения по умолчанию различаются между выпусками SonicOS, и старый интерфейс не доказывает, что делает новый.

Сравните два шага восстановления

Шаг A — подождать. Он ничего не стоит, ничем не рискует и оставляет каждому клиенту обновление по его собственному графику. Шаг B — принудительно освободить и обновить аренду на пострадавшем клиенте: это сразу даёт нужный адрес, но прерывает всё, что клиент делает. На одном компьютере принудительное обновление обычно быстрее и его легко обосновать. В лаборатории или на платёжном терминале посреди транзакции ожидание безопаснее, а запланированное обновление вне рабочих часов лучше обоих вариантов.

ipconfig /all
ipconfig /release
ipconfig /renew

Прочитайте вывод, прежде чем что-либо освобождать. Если адрес, шлюз и DNS уже соответствуют обычному диапазону, клиент восстановился сам, а оставшаяся проблема в другом месте. На клиенте Linux эквивалент — освобождение и обновление аренды через сетевой менеджер, а не адрес, исправленный вручную, иначе менеджер перезапишет ваше изменение при следующем событии.

Читайте предложение, а не только адрес

Адрес сам по себе не говорит, кто его выдал. Важны идентификатор сервера в предложении, срок аренды и то, совпадают ли шлюз и резолвер с резервным диапазоном или с обычным.

tcpdump -ni any 'port 67 or port 68'

Снимайте во время обновления, потому что тихий интерфейс говорит, что клиент так и не спросил. Если предложение приходит от локального резерва, пока туннель поднят, логика выбора по-прежнему считает удалённый путь недоступным, и принудительные обновления на клиентах лишь повторят тот же результат. Сопоставьте запись с событиями туннеля по одним и тем же часам. Обновление ключей или короткий обрыв, заканчивающийся за секунды до запроса клиента, — вероятная причина; чистый туннель с резервным ответом — это проблема конфигурации на пути выбора.

Где сравнение переворачивается

Если пострадали сразу многие клиенты, обновления по каждому превращаются в очередь прерываний и звонок в поддержку. В этом случае смотрите на резервный диапазон и процедуру восстановления, а не на клиентов, потому что группа восстановилась вместе и восстановится вместе снова.

Если пострадал только один клиент, а соседи в порядке, верно обратное: переменная — это аренда этого клиента, его резервирование или поведение его собственного клиента DHCP, а изменение на всей площадке — неправильный инструмент.

Статические адреса и резервирования требуют третьего ответа. Клиента, привязанного к адресу, не спасти обновлением, а резервирование, конфликтующее с резервным диапазоном, создаёт дубликат, который выглядит как сбой маршрутизации, пока вы не сравните два плана адресов.

Запишите процедуру выхода

Заранее решите, для чего нужен резерв, как долго клиент может держать временный адрес и кому разрешено принудительно обновлять аренду в рабочее время. Запишите ответ там, где его найдёт дежурный инженер, рядом с определением диапазона. Затем проверьте это один раз намеренно: оборвите туннель, посмотрите, что получает клиент, восстановите туннель и запишите, сколько времени клиенту нужно, чтобы вернуть обычные настройки. Это одно упражнение заменяет большую часть догадок в следующий раз, когда канал площадки дрогнет.

Закончите подтверждением ресурса, а не адреса. Доступ к файловому серверу, разрешение его имени и доступ в интернет — это три отдельные проверки, и только последняя никогда не вызывала сомнений.