Адаптер OpenVPN у Windows без кінця відвалюється? Перевірте дубльовану IP-адресу

У Windows адаптер OpenVPN, який отримує адресу, втрачає її та повторює це кожні кілька секунд, зазвичай не є помилкою DHCP. Адаптеру кажуть використовувати адресу, на яку вже відповідає щось інше, тож Windows позначає її непридатною, і клієнт починає спочатку. Журнал клієнта мовчить, бо конфлікт вирішується нижче, у власному мережевому стеку операційної системи.

Ця різниця важлива, адже кожен крок діагностики, спрямований на конфігурацію тунелю, пропустить дубльовану адресу на боці сервера.

Почніть із журналу подій Windows, а не з журналу клієнта

Windows записує конфлікти адрес у журнал System із кодами подій 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 виглядає здоровим.

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