OpenVPN-adapteren hakk på Windows? Sjekk for ein dobbel IP

På Windows er ein OpenVPN-adapter som tek ei adresse, slepp henne og gjer det om att kvart par sekund normalt ikkje ein DHCP-feil. Adapteren vert beden om å bruke ei adresse som noko anna alt svarar på, så Windows merkjer henne som ubrukeleg, og klienten startar på nytt. Klientloggen held seg stille fordi konflikten vert løyst under han, inne i operativsystemet sin eigen nettverksstakk.

Den skilnaden spelar rolle, fordi kvart feilsøkingssteg retta mot tunnelkonfigurasjonen vil oversjå ein dobbeladresse på serversida.

Start med Windows-hendingsloggen, ikkje klientloggen

Windows registrerer adressekonfliktar i systemloggen, med hendings-ID-ane 4198 og 4199. Den første rapporterer ein konflikt som er funnen for ei adresse, den andre rapporterer at eit grensesnitt ikkje kunne bruke adressa det var konfigurert med. Ingen av dei nemner OpenVPN, og nettopp derfor er dei lette å oversjå.

Hent dei siste hendingane og samanlikn tidsstempla deira med fornyingssyklusen til adapteren: Get-WinEvent -FilterHashtable @{LogName='System'; Id=4198,4199} -MaxEvents 40 | Format-Table TimeCreated,Id,Message -Wrap. Ein konflikt kvart femtande sekund passar med ein klient som prøver den same adressa på nytt mot ein eigar som held fram med å svare på henne. Ein einaste konflikt ved tilkopling peikar heller mot ein eingongskollisjon. Uansett er det neste spørsmålet kven andre som held adressa.

Tre ordningar set to vertar på éi adresse

Spør serveren kven han meiner har adressa, og spør deretter nettverket kven som svarar på henne. grep -H ifconfig-push /etc/openvpn/ccd/* viser kvar fastlåst tunneladresse og sertifikatet ho høyrer til. ip -4 neigh show dev tap0 viser kva brua har lært på lag to. Å samanlikne dei to listene finn dei fleste duplikata på under eitt minutt.

Tre ordningar forklarer nesten alle: ein oppføring i client-config-dir festar éi adresse til to sertifikat, eit brua tap-segment gjev ein maskin ei adresse som ein annan vert alt har statisk, eller ei utdatert lease-fil returnerer ei adresse som ein klient som framleis er tilkopla meiner han eig. Det tredje tilfellet er det lurnaste, fordi ifconfig-pool-persist medvite brukar adresser om att for kjende klientar.

Gjer adressa unik i staden for å kappast om henne

Oppstartsrekkjefølgja avgjer berre kven som vinn i dag, så handsam kvar retting basert på omstartssrekkjefølgja som mellombels. Gje kvar klient si eiga ifconfig-push-linje, eller tildel statiske adresser frå eit område som ingen bru- eller servergrensesnitt rører. Gå òg gjennom klientlista for dupliserte common names, fordi duplicate-cn lèt to økter dele éin identitet og dermed éi fastlåst adresse. Viss ein brua eining verkeleg treng ei fast adresse, flytt henne til sitt eige subnett eller reserver henne frå poolen på ein stad serveren registrerer.

Slett persist-fila først når du veit kva leasar ho held, elles deler neste gjenoppkopling ut dei same adressene igjen.

Start på nytt i rett rekkjefølgje og stadfest éin eigar per adresse

Bruk endringa på serveren først, og kople deretter klientane til på nytt, slik at kvar deltakar registrerer seg mot den retta poolen. Viss klientane vert starta på nytt først, held dei adresser som serveren framleis meiner er opptekne. Etter omstarten les du statusfila og stadfestar at kvart common name viser seg éin gong med éi adresse. To oppføringar for eitt namn tyder at ei gammal økt aldri vart lukka, ikkje at poolen er øydelagd.

Viss ein klient framleis ikkje klarar å halde på adressa si, sjekk om eit brugrensesnitt på same vert ber henne. Ei bru som har arva ei adresse frå ein leverandøreining, vil svare på ARP for henne sjølv når VPN-serveren alt har gjeve adressa til ein klient.

Fylg med gjennom ein full fornyingssyklus før du lukkar saka

Éin rein avlesing bevisar ingenting. Fylg med på adapteren i minst ti minutt og tving fram ei gjenoppkopling i midten: Get-NetIPAddress -InterfaceAlias "OpenVPN*" | Select-Object IPAddress,AddressState. Adressa bør overleve gjenoppkoplinga og halde seg i ein føretrekt tilstand.

Køyr deretter hendingsspørjinga frå første steg på nytt og stadfest at ho ikkje returnerer noko nytt. Ein stille logg gjennom ei gjenoppkopling er beviset på at konflikten er borte, medan ein stille logg etter éi einskild tilkopling berre tyder at kapplaupet enno ikkje har skjedd. Til slutt testar du ressursen tunnelen finst for, fordi ei bru som mista adressa si kan øydeleggje ein leverandørveg medan sjølve VPN-en ser sunn ut.

Skriv poolområdet, kvar fastlåst adresse og verten som eig henne i servernotata. Då tek det minutt å få auge på neste kollisjon i staden for ein heil ettermiddag å gjenoppdage han.