OpenVPN-adapteren hakker på Windows? Sjekk for en dobbel IP

På Windows er en OpenVPN-adapter som tar en adresse, slipper den og gjentar det hvert par sekunder normalt ikke en DHCP-feil. Adapteren blir bedt om å bruke en adresse som noe annet allerede svarer på, så Windows markerer den som ubrukelig, og klienten starter på nytt. Klientloggen forblir stille fordi konflikten løses under den, inne i operativsystemets egen nettverksstakk.

Den forskjellen betyr noe, fordi hvert feilsøkingstrinn rettet mot tunnelkonfigurasjonen vil overse en dobbeladresse på serversiden.

Start med Windows-hendelsesloggen, ikke klientloggen

Windows registrerer adressekonflikter i systemloggen, med hendelses-ID-ene 4198 og 4199. Den første rapporterer en konflikt som er funnet for en adresse, den andre rapporterer at et grensesnitt ikke kunne bruke adressen det var konfigurert med. Ingen av dem nevner OpenVPN, og nettopp derfor er de lette å overse.

Hent de siste hendelsene og sammenlign tidsstemplene deres med adapterens fornyelsessyklus: Get-WinEvent -FilterHashtable @{LogName='System'; Id=4198,4199} -MaxEvents 40 | Format-Table TimeCreated,Id,Message -Wrap. En konflikt hvert femtende sekund passer med en klient som prøver den samme adressen på nytt mot en eier som fortsetter å svare på den. En enkelt konflikt ved tilkobling peker heller mot en engangskollisjon. Uansett er det neste spørsmålet hvem andre som holder adressen.

Tre ordninger setter to verter på én adresse

Spør serveren hvem den mener har adressen, og spør deretter nettverket hvem som svarer på den. grep -H ifconfig-push /etc/openvpn/ccd/* viser hver fastlåst tunneladresse og sertifikatet den tilhører. ip -4 neigh show dev tap0 viser hva broen har lært på lag to. Å sammenligne de to listene finner de fleste duplikatene på under et minutt.

Tre ordninger forklarer nesten alle: en oppføring i client-config-dir fester én adresse til to sertifikater, et broet tap-segment gir en maskin en adresse som en annen vert allerede har statisk, eller en utdatert lease-fil returnerer en adresse som en klient som fortsatt er tilkoblet mener den eier. Det tredje tilfellet er det snikeste, fordi ifconfig-pool-persist bevisst gjenbruker adresser for kjente klienter.

Gjør adressen unik i stedet for å kappes om den

Oppstartsrekkefølgen avgjør bare hvem som vinner i dag, så behandle enhver rettelse basert på omstartsrekkefølgen som midlertidig. Gi hver klient sin egen ifconfig-push-linje, eller tildel statiske adresser fra et område som ingen bro- eller servergrensesnitt berører. Gå også gjennom klientlisten for dupliserte common names, fordi duplicate-cn lar to økter dele én identitet og dermed én fastlåst adresse. Hvis en broet enhet virkelig trenger en fast adresse, flytt den til sitt eget subnett eller reserver den fra poolen på et sted serveren registrerer.

Slett persist-filen først når du vet hvilke leaser den holder, ellers deler neste gjenoppkobling ut de samme adressene igjen.

Start på nytt i riktig rekkefølge og bekreft én eier per adresse

Bruk endringen på serveren først, og koble deretter klientene til på nytt, slik at hver deltaker registrerer seg mot den rettede poolen. Hvis klientene startes på nytt først, beholder de adresser som serveren fremdeles mener er opptatt. Etter omstarten leser du statusfilen og bekrefter at hvert common name vises én gang med én adresse. To oppføringer for ett navn betyr at en gammel økt aldri ble lukket, ikke at poolen er ødelagt.

Hvis en klient fortsatt ikke klarer å beholde adressen sin, sjekk om et brogrensesnitt på samme vert bærer den. En bro som har arvet en adresse fra en leverandørenhet, vil svare på ARP for den selv når VPN-serveren allerede har gitt adressen til en klient.

Følg med gjennom en full fornyelsessyklus før du lukker saken

Én ren avlesning beviser ingenting. Følg med på adapteren i minst ti minutter og tving frem en gjenoppkobling i midten: Get-NetIPAddress -InterfaceAlias "OpenVPN*" | Select-Object IPAddress,AddressState. Adressen bør overleve gjenoppkoblingen og forbli i en foretrukket tilstand.

Kjør deretter hendelsesspørringen fra første trinn på nytt og bekreft at den ikke returnerer noe nytt. En stille logg gjennom en gjenoppkobling er beviset på at konflikten er borte, mens en stille logg etter én enkelt tilkobling bare betyr at kappløpet ennå ikke har skjedd. Til slutt tester du ressursen tunnelen finnes for, fordi en bro som mistet adressen sin kan ødelegge en leverandørvei mens selve VPN-en ser sunn ut.

Skriv poolområdet, hver fastlåst adresse og verten som eier den i servernotatene. Da tar det minutter å få øye på neste kollisjon i stedet for en hel ettermiddag å gjenoppdage den.