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 изгледа здраво.

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