Адаптер OpenVPN мигает в Windows? Проверьте дублирующийся IP

В Windows адаптер OpenVPN, который получает адрес, сбрасывает его и повторяет это каждые несколько секунд, обычно не является ошибкой DHCP. Адаптеру предписывают использовать адрес, на который уже отвечает что-то другое, поэтому Windows помечает его как непригодный, и клиент начинает заново. Журнал клиента молчит, потому что конфликт решается ниже, внутри собственного сетевого стека операционной системы.

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

Начните с журнала событий Windows, а не с журнала клиента

Windows записывает конфликты адресов в системный журнал с идентификаторами событий 4198 и 4199. Первый сообщает об обнаруженном конфликте для адреса, второй — что интерфейс не смог использовать адрес, с которым был настроен. Ни один не упоминает OpenVPN, и именно поэтому их легко пропустить.

Извлеките последние события и сравните их отметки времени с циклом обновления адаптера: Get-WinEvent -FilterHashtable @{LogName='System'; Id=4198,4199} -MaxEvents 40 | Format-Table TimeCreated,Id,Message -Wrap. Конфликт каждые пятнадцать секунд соответствует клиенту, который повторно пробует тот же адрес у владельца, продолжающего отвечать на него. Одиночный конфликт при подключении скорее указывает на разовое столкновение. В любом случае следующий вопрос — кто ещё держит адрес.

Три схемы помещают два узла на один адрес

Спросите сервер, кто, по его мнению, держит адрес, а затем спросите сеть, кто на него отвечает. grep -H ifconfig-push /etc/openvpn/ccd/* перечисляет каждый закреплённый адрес туннеля и сертификат, которому он принадлежит. ip -4 neigh show dev tap0 показывает, что мост узнал на втором уровне. Сравнение этих двух списков находит большинство дубликатов меньше чем за минуту.

Три схемы объясняют почти все: запись в client-config-dir закрепляет один адрес за двумя сертификатами, сегмент tap, подключённый к мосту, выдаёт машине адрес, который другой узел уже имеет статически, или устаревший файл аренды возвращает адрес, который ещё подключённый клиент считает своим. Третий случай самый коварный, потому что ifconfig-pool-persist намеренно повторно использует адреса для известных клиентов.

Сделайте адрес уникальным, а не соревнуйтесь за него

Порядок загрузки решает лишь, кто победит сегодня, поэтому считайте временным любое исправление, основанное на последовательности перезапуска. Дайте каждому клиенту его собственную строку ifconfig-push или выделяйте статические адреса из диапазона, которого не касается ни один интерфейс моста или сервера. Проверьте также список клиентов на дублирующиеся общие имена, потому что duplicate-cn позволяет двум сессиям делить одну личность и, следовательно, один закреплённый адрес. Если устройству, подключённому к мосту, действительно нужен фиксированный адрес, перенесите его в собственную подсеть или зарезервируйте его из пула в месте, которое сервер записывает.

Удаляйте файл persist только после того, как узнаете, какие аренды он содержит, иначе следующее переподключение снова раздаст те же адреса.

Перезапустите в правильном порядке и подтвердите одного владельца на адрес

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

Если клиент всё ещё не может удержать свой адрес, проверьте, не несёт ли его интерфейс моста на том же узле. Мост, унаследовавший адрес от устройства поставщика, будет отвечать на ARP для него даже тогда, когда VPN-сервер уже передал этот адрес клиенту.

Наблюдайте полный цикл обновления, прежде чем закрыть заявку

Одно чистое измерение ничего не доказывает. Наблюдайте за адаптером не менее десяти минут и принудительно переподключитесь в середине: Get-NetIPAddress -InterfaceAlias "OpenVPN*" | Select-Object IPAddress,AddressState. Адрес должен пережить переподключение и остаться в предпочтительном состоянии.

Затем повторно выполните запрос событий из первого шага и убедитесь, что он не возвращает ничего нового. Тихий журнал на протяжении переподключения — доказательство того, что конфликт исчез, тогда как тихий журнал после одного подключения означает лишь, что гонка ещё не произошла. Наконец, проверьте ресурс, ради которого существует туннель, потому что мост, потерявший адрес, может сломать путь поставщика, тогда как сам VPN выглядит здоровым.

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