OpenVPN адаптерот на Windows постојано паѓа? Проверете дупликат IP

На Windows, OpenVPN адаптер што зема адреса, ја испушта и го повторува тоа на секои неколку секунди обично не е грешка во DHCP. На адаптерот му се кажува да користи адреса на која веќе одговара нешто друго, па Windows ја означува како неупотреблива и клиентот почнува одново. Дневникот на клиентот останува тивок затоа што судирот се решава под него, во сопствениот мрежен стек на оперативниот систем.

Таа разлика е важна, зашто секој чекор за отстранување проблеми насочен кон конфигурацијата на тунелот ќе пропушти дупликат адреса на страната на серверот.

Започнете со дневникот на настани на Windows, не со дневникот на клиентот

Windows ги запишува судирите на адреси во системскиот дневник, со ID на настан 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 изгледа здраво.

Запишете го опсегот на базенот, секоја закачена адреса и хостот што ја држи во белешките на серверот. Тогаш следниот судир се забележува за неколку минути наместо да бара цело попладне за повторно откривање.