OpenVPN-adaptern fladdrar i Windows? Kontrollera om det finns en dubbel IP

I Windows är en OpenVPN-adapter som tar en adress, släpper den och upprepar det varje par sekunder vanligtvis inte en DHCP-bugg. Adaptern får order om att använda en adress som något annat redan svarar på, så Windows markerar den som oanvändbar och klienten börjar om. Klientloggen förblir tyst eftersom konflikten löses under den, inne i operativsystemets egen nätverksstack.

Den skillnaden spelar roll, eftersom varje felsökningssteg som riktas mot tunnelkonfigurationen kommer att missa en dubbeladress på serversidan.

Börja med Windows-händelseloggen, inte klientloggen

Windows registrerar adresskonflikter i systemloggen, med händelse-ID 4198 och 4199. Den första rapporterar en konflikt som hittats för en adress, den andra rapporterar att ett gränssnitt inte kunde använda adressen det var konfigurerat med. Ingen av dem nämner OpenVPN, och det är just därför de är lätta att förbise.

Hämta de senaste händelserna och jämför deras tidsstämplar med adapterns förnyelsecykel: Get-WinEvent -FilterHashtable @{LogName='System'; Id=4198,4199} -MaxEvents 40 | Format-Table TimeCreated,Id,Message -Wrap. En konflikt var femtonde sekund matchar en klient som försöker igen med samma adress mot en ägare som fortsätter att svara på den. En enstaka konflikt vid anslutningen pekar i stället på en engångskollision. Hur som helst är nästa fråga vem mer som håller adressen.

Tre arrangemang sätter två värdar på en adress

Fråga servern vem den anser har adressen och fråga sedan nätverket vem som svarar på den. grep -H ifconfig-push /etc/openvpn/ccd/* listar varje fastlåst tunneladress och certifikatet den tillhör. ip -4 neigh show dev tap0 visar vad bron har lärt sig på lager två. Att jämföra de två listorna hittar de flesta dubbletter på under en minut.

Tre arrangemang förklarar nästan alla: en post i client-config-dir låser en adress till två certifikat, ett broat tap-segment ger en maskin en adress som en annan värd redan har statiskt, eller en inaktuell lease-fil returnerar en adress som en klient som fortfarande är ansluten tror sig äga. Det tredje fallet är det listigaste, eftersom ifconfig-pool-persist medvetet återanvänder adresser för kända klienter.

Gör adressen unik i stället för att tävla om den

Startordningen avgör bara vem som vinner i dag, så behandla varje rättelse som bygger på omstartsordningen som tillfällig. Ge varje klient sin egen ifconfig-push-rad, eller tilldela statiska adresser från ett intervall som ingen bro- eller servergränssnitt rör. Gå också igenom klientlistan efter dubblerade common names, eftersom duplicate-cn låter två sessioner dela en identitet och därmed en fastlåst adress. Om en broad enhet verkligen behöver en fast adress, flytta den till sitt eget subnät eller reservera den från poolen på en plats som servern registrerar.

Radera persist-filen först när du vet vilka leases den innehåller, annars delar nästa återanslutning ut samma adresser igen.

Starta om i rätt ordning och bekräfta en ägare per adress

Använd ändringen på servern först och återanslut sedan klienterna, så att varje deltagare registrerar sig mot den korrigerade poolen. Om klienterna startas om först behåller de adresser som servern fortfarande anser är upptagna. Läs statusfilen efter omstarten och bekräfta att varje common name visas en gång med en adress. Två poster för ett namn betyder att en gammal session aldrig stängdes, inte att poolen är trasig.

Om en klient fortfarande inte kan behålla sin adress, kontrollera om ett brogränssnitt på samma värd bär den. En bro som ärvt en adress från en leverantörsenhet svarar på ARP för den även när VPN-servern redan har gett adressen till en klient.

Följ med genom en full förnyelsecykel innan du stänger ärendet

En enda ren avläsning bevisar ingenting. Följ adaptern i minst tio minuter och tvinga fram en återanslutning i mitten: Get-NetIPAddress -InterfaceAlias "OpenVPN*" | Select-Object IPAddress,AddressState. Adressen bör överleva återanslutningen och stanna i ett föredraget tillstånd.

Kör sedan händelsefrågan från första steget igen och bekräfta att den inte returnerar något nytt. En tyst logg genom en återanslutning är beviset på att konflikten är borta, medan en tyst logg efter en enda anslutning bara betyder att kapplöpningen ännu inte har inträffat. Testa slutligen resursen som tunneln finns för, eftersom en bro som förlorat sin adress kan bryta en leverantörsväg medan själva VPN:en ser frisk ut.

Skriv poolintervallet, varje fastlåst adress och värden som äger den i servernoteringarna. Då tar det minuter att upptäcka nästa kollision i stället för en hel eftermiddag att återupptäcka den.