OpenVPN adapteris Windows sistemoje mirksi? Patikrinkite pasikartojantį IP

Windows sistemoje OpenVPN adapteris, kuris gauna adresą, jo atsisako ir tai kartoja kas kelias sekundes, paprastai nėra DHCP klaida. Adapteriui liepiama naudoti adresą, į kurį jau atsako kažkas kitas, todėl Windows pažymi jį kaip netinkamą, o klientas pradeda iš naujo. Kliento žurnalas lieka tylus, nes konfliktas sprendžiamas žemiau, pačios operacinės sistemos tinklo kamiene.

Šis skirtumas svarbus, nes kiekvienas trikčių šalinimo žingsnis, nukreiptas į tunelio konfigūraciją, praleis pasikartojantį adresą serverio pusėje.

Pradėkite nuo Windows įvykių žurnalo, o ne nuo kliento žurnalo

Windows adresų konfliktus įrašo sistemos žurnale su įvykių ID 4198 ir 4199. Pirmasis praneša apie adresui aptiktą konfliktą, antrasis praneša, kad sąsaja negalėjo naudoti adreso, su kuriuo buvo sukonfigūruota. Nė vienas nemini OpenVPN, ir būtent todėl juos lengva praleisti.

Ištraukite naujausius įvykius ir palyginkite jų laiko žymes su adapterio atnaujinimo ciklu: Get-WinEvent -FilterHashtable @{LogName='System'; Id=4198,4199} -MaxEvents 40 | Format-Table TimeCreated,Id,Message -Wrap. Konfliktas kas penkiolika sekundžių atitinka klientą, kuris iš naujo bando tą patį adresą prieš savininką, kuris vis dar į jį atsako. Vienas konfliktas prisijungimo metu labiau rodo į vienkartinį susidūrimą. Bet kuriuo atveju kitas klausimas yra, kas dar turi tą adresą.

Trys išdėstymai padeda du mazgus ant vieno adreso

Paklauskite serverio, kas, jo manymu, turi adresą, tada paklauskite tinklo, kas į jį atsako. grep -H ifconfig-push /etc/openvpn/ccd/* išvardija kiekvieną prisegtą tunelio adresą ir sertifikatą, kuriam jis priklauso. ip -4 neigh show dev tap0 parodo, ko tiltas išmoko antrame sluoksnyje. Palyginus šiuos du sąrašus, dauguma dublikatų randami greičiau nei per minutę.

Trys išdėstymai paaiškina beveik visus: client-config-dir įrašas prisega vieną adresą dviem sertifikatams, tiltu sujungtas tap segmentas duoda mašinai adresą, kurį kitas mazgas jau turi statiškai, arba pasenęs nuomos failas grąžina adresą, kurį dar prisijungęs klientas mano turįs. Trečiasis atvejis yra slaptiausias, nes ifconfig-pool-persist sąmoningai pakartotinai naudoja adresus žinomiems klientams.

Padarykite adresą unikalų, o ne lenktyniaukite dėl jo

Įkrovos tvarka nusprendžia tik, kas laimės šiandien, todėl bet kokį taisymą, pagrįstą paleidimo iš naujo seka, laikykite laikinu. Duokite kiekvienam klientui jo paties ifconfig-push eilutę arba skirkite statinius adresus iš diapazono, kurio neliečia jokia tilto ar serverio sąsaja. Patikrinkite klientų sąrašą ir dėl pasikartojančių bendrų pavadinimų, nes duplicate-cn leidžia dviem sesijoms dalytis viena tapatybe ir todėl vienu prisegtu adresu. Jei tiltu sujungtam įrenginiui tikrai reikia fiksuoto adreso, perkelkite jį į savo potinklį arba rezervuokite jį iš telkinio vietoje, kurią serveris įrašo.

Ištrinkite persist failą tik žinodami, kokias nuomas jis saugo, kitaip kitas prisijungimas vėl išdalys tuos pačius adresus.

Paleiskite iš naujo teisinga tvarka ir patvirtinkite vieną savininką kiekvienam adresui

Pakeitimą pirmiausia pritaikykite serveriui, tada iš naujo prijunkite klientus, kad kiekvienas dalyvis užsiregistruotų prie pataisyto telkinio. Jei klientus paleisite iš naujo pirmiausia, jie liks su adresais, kuriuos serveris vis dar laiko užimtais. Po paleidimo iš naujo perskaitykite būsenos failą ir patvirtinkite, kad kiekvienas bendras pavadinimas pasirodo vieną kartą su vienu adresu. Dvi eilutės vienam pavadinimui reiškia, kad sena sesija niekada nebuvo uždaryta, o ne tai, kad telkinys sulaužytas.

Jei klientas vis dar negali išlaikyti savo adreso, patikrinkite, ar jo neneša to paties mazgo tilto sąsaja. Tiltas, paveldėjęs adresą iš tiekėjo įrenginio, atsakys į ARP dėl jo net tada, kai VPN serveris jau perdavė tą adresą klientui.

Stebėkite visą atnaujinimo ciklą prieš uždarydami bilietą

Vienas švarus nuskaitymas nieko neįrodo. Stebėkite adapterį bent dešimt minučių ir viduryje priverskite prisijungti iš naujo: Get-NetIPAddress -InterfaceAlias "OpenVPN*" | Select-Object IPAddress,AddressState. Adresas turėtų išlikti po prisijungimo iš naujo ir likti pageidaujamoje būsenoje.

Tada dar kartą paleiskite pirmojo žingsnio įvykių užklausą ir patvirtinkite, kad ji negrąžina nieko naujo. Tylus žurnalas per prisijungimą iš naujo yra įrodymas, kad konfliktas dingo, o tylus žurnalas po vieno prisijungimo reiškia tik tai, kad lenktynės dar neįvyko. Galiausiai išbandykite išteklių, dėl kurio egzistuoja tunelis, nes tiltas, praradęs savo adresą, gali sulaužyti tiekėjo kelią, nors pats VPN atrodo sveikas.

Užrašykite telkinio diapazoną, kiekvieną prisegtą adresą ir jį turintį mazgą serverio pastabose. Tada kitas susidūrimas pastebimas per minutes, o ne reikalauja visos popietės jam vėl atrasti.