OpenVPN adapter na Windowsu neprestano pada? Provjerite duplikat IP-a

Na Windowsu, OpenVPN adapter koji uzme adresu, ispusti je i to ponavlja svakih nekoliko sekundi obično nije greška u DHCP-u. Adapteru se nalaže da koristi adresu na koju već odgovara nešto drugo, pa je Windows označi kao neupotrebljivu i klijent počinje iznova. Klijentski zapis ostaje tih jer se sukob rješava ispod njega, unutar mrežnog steka samog operativnog sistema.

Ta razlika je važna, jer će svaki korak otklanjanja smetnji usmjeren na konfiguraciju tunela propustiti duplikat adrese na strani servera.

Počnite od Windows zapisa događaja, a ne od klijentskog zapisa

Windows bilježi sukobe adresa u sistemskom zapisu, s ID-ovima događaja 4198 i 4199. Prvi prijavljuje otkriveni sukob za adresu, drugi prijavljuje da interfejs nije mogao koristiti adresu s kojom je konfigurisan. Nijedan ne spominje OpenVPN, i upravo zato ih je lako previdjeti.

Izvucite nedavne događaje i uporedite njihove vremenske oznake s ciklusom obnove adaptera: Get-WinEvent -FilterHashtable @{LogName='System'; Id=4198,4199} -MaxEvents 40 | Format-Table TimeCreated,Id,Message -Wrap. Sukob svakih petnaest sekundi odgovara klijentu koji iznova pokušava istu adresu kod vlasnika koji na nju nastavlja odgovarati. Jedan sukob u vrijeme povezivanja prije ukazuje na jednokratni sudar. U svakom slučaju, sljedeće pitanje je ko još drži adresu.

Tri rasporeda stavljaju dva hosta na jednu adresu

Pitajte server koga smatra vlasnikom adrese, a zatim pitajte mrežu ko na nju odgovara. grep -H ifconfig-push /etc/openvpn/ccd/* navodi svaku prikvačenu adresu tunela i certifikat kojem pripada. ip -4 neigh show dev tap0 pokazuje šta je most naučio na drugom sloju. Poređenje tih dvaju spiskova pronalazi većinu duplikata za manje od minute.

Tri rasporeda objašnjavaju skoro sve: unos u client-config-dir prikvačuje jednu adresu za dva certifikata, premosni tap segment daje mašini adresu koju drugi host već ima statički, ili zastarjeli fajl zakupa vraća adresu za koju klijent koji je još povezan smatra da je njegova. Treći slučaj je najpodmukliji, jer ifconfig-pool-persist namjerno ponovo koristi adrese za poznate klijente.

Učinite adresu jedinstvenom umjesto da se otimate za nju

Redoslijed podizanja odlučuje samo ko će danas pobijediti, pa svako rješenje zasnovano na redoslijedu restarta tretirajte kao privremeno. Dajte svakom klijentu sopstvenu liniju ifconfig-push ili dodijelite statičke adrese iz opsega koji ne dira nijedan most ni serverski interfejs. Provjerite i spisak klijenata na duplikate uobičajenih imena, jer duplicate-cn dopušta dvjema sesijama da dijele jedan identitet i time jednu prikvačenu adresu. Ako premosnom uređaju zaista treba fiksna adresa, premjestite ga u njegovu podmrežu ili ga rezervišite iz pula na mjestu koje server bilježi.

Izbrišite persist fajl tek kada znate koje zakupa drži, inače će sljedeće ponovno povezivanje opet podijeliti iste adrese.

Restartujte pravim redoslijedom i potvrdite jednog vlasnika po adresi

Primijenite promjenu prvo na serveru, a zatim ponovo povežite klijente, da se svaki učesnik registruje prema ispravljenom pulu. Ako prvo restartujete klijente, oni ostaju s adresama koje server još smatra zauzetim. Nakon restarta pročitajte statusni fajl i potvrdite da se svako uobičajeno ime pojavljuje jednom s jednom adresom. Dva unosa za jedno ime znače da se stara sesija nikad nije zatvorila, a ne da je pul pokvaren.

Ako klijent i dalje ne može zadržati svoju adresu, provjerite nosi li je mostovni interfejs na istom hostu. Most koji je naslijedio adresu od uređaja dobavljača odgovarat će na ARP za nju čak i kada je VPN server tu adresu već predao klijentu.

Gledajte kroz cijeli ciklus obnove prije nego zatvorite tiket

Jedno čisto očitanje ništa ne dokazuje. Gledajte adapter najmanje deset minuta i u sredini prisilno ponovo povežite: Get-NetIPAddress -InterfaceAlias "OpenVPN*" | Select-Object IPAddress,AddressState. Adresa bi trebala preživjeti ponovno povezivanje i ostati u poželjnom stanju.

Zatim ponovo pokrenite upit događaja iz prvog koraka i potvrdite da ne vraća ništa novo. Tih zapis tokom ponovnog povezivanja dokaz je da je sukob nestao, dok tih zapis nakon jednog povezivanja znači samo da se utrka još nije dogodila. Na kraju testirajte resurs zbog kojeg tunel postoji, jer most koji je izgubio adresu može pokvariti put dobavljača dok sam VPN izgleda zdravo.

Zabilježite opseg pula, svaku prikvačenu adresu i host koji je drži u serverske bilješke. Sljedeći sudar tada se uočava za nekoliko minuta umjesto da se ponovo otkriva cijelo popodne.