Адаптер 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 изглежда здрав.

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