OpenVPN-i adapter vilgub Windowsis? Kontrollige duplikaat-IP-d

Windowsis ei ole OpenVPN-i adapter, mis võtab aadressi, viskab selle ära ja kordab seda iga paari sekundi järel, tavaliselt DHCP viga. Adapterile öeldakse, et kasutada aadressi, millele vastab juba miski muu, seega märgib Windows selle kasutuskõlbmatuks ja klient alustab otsast peale. Kliendi logi jääb vaikseks, sest konflikt lahendatakse sellest allpool, operatsioonisüsteemi enda võrgupinus.

See erinevus on oluline, sest iga tunnelikonfiguratsioonile suunatud tõrkeotsingu samm jätab serveripoolse duplikaataadressi tähelepanuta.

Alustage Windowsi sündmuselogist, mitte kliendilogist

Windows registreerib aadressikonfliktid süsteemilogis sündmuse ID-dega 4198 ja 4199. Esimene teatab aadressi jaoks tuvastatud konfliktist, teine teatab, et liides ei saanud kasutada aadressi, millega see oli konfigureeritud. Kumbki ei maini OpenVPN-i ja just seetõttu on neid lihtne tähelepanuta jätta.

Tõmmake viimased sündmused ja võrrelge nende ajatempleid adapteri uuendustsükliga: Get-WinEvent -FilterHashtable @{LogName='System'; Id=4198,4199} -MaxEvents 40 | Format-Table TimeCreated,Id,Message -Wrap. Konflikt iga viieteistkümne sekundi järel vastab kliendile, kes proovib sama aadressi uuesti omaniku vastu, kes jätkab sellele vastamist. Üksik konflikt ühenduse hetkel viitab pigem ühekordsele kokkupõrkele. Mõlemal juhul on järgmine küsimus, kes veel seda aadressi hoiab.

Kolm paigutust panevad kaks hosti ühele aadressile

Küsige serverilt, kes selle arvates aadressi hoiab, ja seejärel küsige võrgult, kes sellele vastab. grep -H ifconfig-push /etc/openvpn/ccd/* loetleb iga kinnitatud tunneliaadressi ja sertifikaadi, mille juurde see kuulub. ip -4 neigh show dev tap0 näitab, mida sild on teisel kihil õppinud. Nende kahe nimekirja võrdlemine leiab enamiku duplikaatidest vähem kui minutiga.

Kolm paigutust seletavad peaaegu kõiki: client-config-dir kirje kinnitab ühe aadressi kahe sertifikaadi jaoks, sillatud tap-segment annab masinale aadressi, mis teisel hostil on juba staatiliselt, või aegunud rendifail tagastab aadressi, mida veel ühendatud klient arvab endale kuuluvat. Kolmas juhtum on kõige salakavalam, sest ifconfig-pool-persist kasutab teadaolevate klientide jaoks aadresse tahtlikult uuesti.

Tehke aadress unikaalseks, selle asemel et selle eest võistelda

Alglaadimise järjekord otsustab ainult, kes täna võidab, seega kohtle iga taaskäivituse järjekorral põhinevat parandust ajutisena. Andke igale kliendile tema oma ifconfig-push rida või eraldage staatilised aadressid vahemikust, mida ükski silla- ega serveriliides ei puuduta. Kontrollige kliendinimekirja ka duplikaatsete ühisnimede suhtes, sest duplicate-cn lubab kahel seansil jagada ühte identiteeti ja seega ühte kinnitatud aadressi. Kui sillatud seadmel on tõesti vaja fikseeritud aadressi, viige see oma alamvõrku või broneerige see basseinist kohas, mille server salvestab.

Kustutage persist-fail alles siis, kui teate, milliseid rendilepinguid see sisaldab, muidu jagab järgmine taasthendus samad aadressid uuesti välja.

Taaskäivitage õiges järjekorras ja kinnitage üks omanik aadressi kohta

Rakendage muudatus esmalt serveril ja seejärel ühendage kliendid uuesti, et iga osaleja registreeruks parandatud basseini vastu. Kui taaskäivitate kliendid esimesena, jäävad need aadressidega, mida server peab endiselt hõivatuks. Pärast taaskäivitust lugege olekufaili ja kinnitage, et iga ühisnimi esineb üks kord ühe aadressiga. Kaks kirjet ühe nime kohta tähendavad, et vana seanss ei sulgunud kunagi, mitte et bassein on katki.

Kui klient ei suuda ikka oma aadressi hoida, kontrollige, kas seda kannab sama hosti sillaliides. Sild, mis on pärandanud aadressi tarnijaseadmelt, vastab sellele ARP-iga ka siis, kui VPN-server on selle aadressi juba kliendile andnud.

Jälgige tervet uuendustsüklit enne pileti sulgemist

Üks puhas lugemine ei tõesta midagi. Jälgige adapterit vähemalt kümme minutit ja sundige keskel taasthendust: Get-NetIPAddress -InterfaceAlias "OpenVPN*" | Select-Object IPAddress,AddressState. Aadress peaks taasthenduse üle elama ja jääma eelistatud olekusse.

Seejärel käivitage esimese sammu sündmusepäring uuesti ja kinnitage, et see ei tagasta midagi uut. Vaikne logi taasthenduse vältel on tõestus, et konflikt on kadunud, samas kui vaikne logi pärast ühte ühendust tähendab vaid seda, et võidujooks pole veel toimunud. Lõpuks testige ressurssi, mille jaoks tunnel olemas on, sest aadressi kaotanud sild võib katki teha tarnija tee, samal ajal kui VPN ise paistab terve.

Kirjutage basseini vahemik, iga kinnitatud aadress ja seda omav host serveri märkmetesse. Siis võtab järgmise kokkupõrke märkamine minuteid, mitte tervet pärastlõunat selle uuesti avastamiseks.