Az OpenVPN adapter villog a Windows alatt? Ellenőrizze a duplikált IP-t

Windows alatt az az OpenVPN-adapter, amely felvesz egy címet, eldobja, majd néhány másodpercenként megismétli ezt, általában nem DHCP-hiba. Az adapternak olyan címet mondanak, amelyre már más válaszol, ezért a Windows használhatatlannak jelöli, és a kliens újrakezdi. A kliens naplója csendben marad, mert az ütközést alatta, magának az operációs rendszernek a hálózati veremében oldják meg.

Ez a különbség számít, mert minden, az alagút konfigurációjára irányuló hibaelhárítási lépés elnéz egy duplikált címet a kiszolgáló oldalán.

Kezdje a Windows eseménynaplójával, ne a kliens naplójával

A Windows a címütközéseket a rendszernaplóban rögzíti, 4198 és 4199 esemény-azonosítóval. Az első egy címhez észlelt ütközést jelent, a második azt jelenti, hogy egy interfész nem tudta használni azt a címet, amellyel konfigurálták. Egyik sem említi az OpenVPN-t, és éppen ezért könnyű őket figyelmen kívül hagyni.

Kérje le a legutóbbi eseményeket, és hasonlítsa össze az időbélyegüket az adapter megújítási ciklusával: Get-WinEvent -FilterHashtable @{LogName='System'; Id=4198,4199} -MaxEvents 40 | Format-Table TimeCreated,Id,Message -Wrap. A tizenöt másodpercenkénti ütközés olyan kliensnek felel meg, amely ugyanazt a címet próbálja újra egy olyan tulajdonossal szemben, amely továbbra is válaszol rá. Egyetlen ütközés a csatlakozáskor inkább egyszeri ütközésre utal. Mindkét esetben a következő kérdés az, ki más tartja a címet.

Három elrendezés tesz két gazdagépet egy címre

Kérdezze meg a kiszolgálót, ki szerinte a cím birtokosa, majd kérdezze meg a hálózatot, ki válaszol rá. grep -H ifconfig-push /etc/openvpn/ccd/* felsorolja az összes rögzített alagútcímet és a hozzá tartozó tanúsítványt. ip -4 neigh show dev tap0 megmutatja, mit tanult a híd a második rétegen. A két lista összehasonlítása a legtöbb duplikátumot egy perc alatt megtalálja.

Három elrendezés magyarázza szinte az összeset: a client-config-dir bejegyzés egy címet két tanúsítványhoz rögzít, egy áthidalt tap szegmens olyan címet ad egy gépnek, amely már statikusan egy másik gazdagépé, vagy egy elavult bérletfájl olyan címet ad vissza, amelyet egy még csatlakozott kliens a sajátjának hisz. A harmadik eset a legravaszabb, mert a ifconfig-pool-persist szándékosan újrahasználja a címeket az ismert kliensek számára.

Tegye egyedivé a címet ahelyett, hogy versenyezne érte

A rendszerindítási sorrend csak azt dönti el, ki nyer ma, ezért tekintsen minden, az újraindítási sorrendre épülő javítást ideiglenesnek. Adjon minden kliensnek saját ifconfig-push sort, vagy osszon ki statikus címeket olyan tartományból, amelyet egyetlen híd- vagy kiszolgálói interfész sem érint. Ellenőrizze a klienslistát duplikált közös nevekre is, mert a duplicate-cn engedi, hogy két munkamenet egy identitást és ezáltal egy rögzített címet osszon meg. Ha egy áthidalt eszköznek valóban állandó címre van szüksége, helyezze át a saját alhálózatába, vagy foglalja le a készletből olyan helyen, amelyet a kiszolgáló rögzít.

Csak akkor törölje a persist fájlt, ha tudja, milyen bérleteket tartalmaz, különben a következő újracsatlakozás ugyanazokat a címeket osztja ki újra.

Indítsa újra a helyes sorrendben, és erősítse meg, hogy címenként egy tulajdonos van

Először a kiszolgálón alkalmazza a módosítást, majd csatlakoztassa újra a klienseket, hogy minden résztvevő a javított készlet ellen regisztráljon. Ha először a klienseket indítja újra, azok olyan címekkel maradnak, amelyeket a kiszolgáló még foglaltnak hisz. Az újraindítás után olvassa el az állapotfájlt, és erősítse meg, hogy minden közös név egyszer, egy címmel jelenik meg. Egy névhez két bejegyzés azt jelenti, hogy egy régi munkamenet soha nem zárult be, nem azt, hogy a készlet megsérült.

Ha egy kliens még mindig nem tudja megtartani a címét, ellenőrizze, hogy nem hordozza-e egy hídfelület ugyanazon a gazdagépen. Az a híd, amely egy szállítóeszköztől örökölt címet, ARP-választ ad rá akkor is, amikor a VPN-kiszolgáló már átadta azt a címet egy kliensnek.

Figyelje meg egy teljes megújítási cikluson át, mielőtt lezárja a jegyet

Egyetlen tiszta leolvasás semmit sem bizonyít. Figyelje az adaptert legalább tíz percig, és a közepén kényszerítsen ki egy újracsatlakozást: Get-NetIPAddress -InterfaceAlias "OpenVPN*" | Select-Object IPAddress,AddressState. A címnek túl kell élnie az újracsatlakozást, és előnyben részesített állapotban kell maradnia.

Ezután futtassa újra az első lépés eseménylekérdezését, és erősítse meg, hogy nem ad vissza semmi újat. Az újracsatlakozáson át tartó csendes napló bizonyítja, hogy az ütközés elmúlt, míg az egyetlen csatlakozás utáni csendes napló csak azt jelenti, hogy a verseny még nem történt meg. Végül tesztelje azt az erőforrást, amelyért az alagút létezik, mert az a híd, amely elvesztette a címét, elronthat egy szállítói útvonalat, miközben maga a VPN egészségesnek tűnik.

Jegyezze fel a készlet tartományát, minden rögzített címet és az azt birtokló gazdagépet a kiszolgáló megjegyzéseibe. Akkor a következő ütközés percek alatt észrevehető, nem kell egy egész délután újra felfedezni.