Vmesnik OpenVPN v Windowsih utripa? Preverite podvojeni IP

V Windowsih vmesnik OpenVPN, ki prevzame naslov, ga spusti in to ponovi vsakih nekaj sekund, običajno ni napaka DHCP. Vmesniku se naroči, naj uporabi naslov, na katerega že odgovarja nekaj drugega, zato ga Windows označi kot neuporabnega in odjemalec začne znova. Dnevnik odjemalca ostane tih, ker se konflikt rešuje pod njim, v samem omrežnem skladu operacijskega sistema.

Ta razlika je pomembna, ker bo vsak korak odpravljanja težav, usmerjen na konfiguracijo predora, spregledal podvojen naslov na strani strežnika.

Začnite z dnevnikom dogodkov Windows, ne z dnevnikom odjemalca

Windows beleži konflikte naslovov v sistemski dnevnik, z ID-jema dogodkov 4198 in 4199. Prvi poroča o zaznanem konfliktu za naslov, drugi poroča, da vmesnik ni mogel uporabiti naslova, s katerim je bil konfiguriran. Noben ne omenja OpenVPN, in prav zato ju je lahko spregledati.

Izvozite nedavne dogodke in primerjajte njihove časovne žige s ciklom obnavljanja vmesnika: Get-WinEvent -FilterHashtable @{LogName='System'; Id=4198,4199} -MaxEvents 40 | Format-Table TimeCreated,Id,Message -Wrap. Konflikt vsakih petnajst sekund ustreza odjemalcu, ki znova poskuša isti naslov pri lastniku, ki še vedno odgovarja nanj. Posamezen konflikt ob povezavi kaže bolj na enkratno kolizijo. V vsakem primeru je naslednje vprašanje, kdo drug ima naslov.

Tri postavitve postavijo dva gostitelja na en naslov

Vprašajte strežnik, kdo po njegovem mnenju ima naslov, nato pa vprašajte omrežje, kdo odgovarja nanj. grep -H ifconfig-push /etc/openvpn/ccd/* navede vsak pripet naslov predora in potrdilo, ki mu pripada. ip -4 neigh show dev tap0 pokaže, kaj se je most naučil na drugem sloju. Primerjava teh dveh seznamov najde večino dvojnikov v manj kot minuti.

Tri postavitve pojasnijo skoraj vse: vnos v client-config-dir pripne en naslov za dve potrdili, mostovljen segment tap da stroju naslov, ki ga ima drug gostitelj že statično, ali zastarela datoteka najema vrne naslov, za katerega še povezan odjemalec meni, da ga ima. Tretji primer je najbolj zvit, ker ifconfig-pool-persist namerno znova uporablja naslove za znane odjemalce.

Naredite naslov edinstven, namesto da bi se zanj dirkali

Vrstni red zagona odloči le, kdo danes zmaga, zato vsak popravek, ki temelji na zaporedju ponovnega zagona, obravnavajte kot začasnega. Vsakemu odjemalcu dajte lastno vrstico ifconfig-push ali dodelite statične naslove iz obsega, ki se ga ne dotakne noben mostni ali strežniški vmesnik. Preglejte tudi seznam odjemalcev za podvojena skupna imena, ker duplicate-cn dovoljuje dvema sejama, da si delita eno identiteto in s tem en pripet naslov. Če mostovljena naprava res potrebuje stalni naslov, jo premaknite v lastno podomrežje ali ga rezervirajte iz nabora na mestu, ki ga strežnik zabeleži.

Datoteko persist izbrišite šele, ko veste, katere najeme vsebuje, sicer bo naslednja ponovna povezava spet razdelila iste naslove.

Znova zaženite v pravem vrstnem redu in potrdite enega lastnika na naslov

Spremembo najprej uporabite na strežniku, nato znova povežite odjemalce, da se vsak udeleženec registrira glede na popravljeni nabor. Če najprej znova zaženete odjemalce, ostanejo z naslovi, ki jih strežnik še vedno šteje za zasedene. Po ponovnem zagonu preberite statusno datoteko in potrdite, da se vsako skupno ime pojavi enkrat z enim naslovom. Dva vnosa za eno ime pomenita, da se stara seja ni nikoli zaprla, ne da je nabor pokvarjen.

Če odjemalec še vedno ne more obdržati svojega naslova, preverite, ali ga nosi mostni vmesnik na istem gostitelju. Most, ki je podedoval naslov od naprave ponudnika, bo nanj odgovarjal z ARP tudi takrat, ko je strežnik VPN naslov že predal odjemalcu.

Opazujte celoten cikel obnavljanja, preden zaprete zahtevek

Eno čisto branje ne dokaže ničesar. Opazujte vmesnik vsaj deset minut in na sredini vsilite ponovno povezavo: Get-NetIPAddress -InterfaceAlias "OpenVPN*" | Select-Object IPAddress,AddressState. Naslov bi moral prestati ponovno povezavo in ostati v prednostnem stanju.

Nato znova zaženite poizvedbo po dogodkih iz prvega koraka in potrdite, da ne vrne ničesar novega. Tih dnevnik med ponovno povezavo je dokaz, da je konflikt izginil, medtem ko tih dnevnik po eni sami povezavi pomeni le, da se tekma še ni zgodila. Nazadnje preizkusite vir, zaradi katerega predor obstaja, ker most, ki je izgubil naslov, lahko pokvari pot ponudnika, medtem ko je sam VPN videti zdrav.

Zapišite obseg nabora, vsak pripet naslov in gostitelja, ki ga ima, v opombe strežnika. Naslednji trk je tako opazen v nekaj minutah, namesto da bi bilo treba popoldne znova ga odkrivati.