OpenVPN-adapter hakker på Windows? Tjek for en dobbelt IP

På Windows er en OpenVPN-adapter, der tager en adresse, dropper den og gentager det hvert par sekunder, normalt ikke en DHCP-fejl. Adapteren får besked på at bruge en adresse, som noget andet allerede svarer på, så Windows markerer den som ubrugelig, og klienten starter forfra. Klientloggen forbliver tavs, fordi konflikten løses nedenunder, inde i operativsystemets egen netværksstak.

Den forskel betyder noget, fordi hvert fejlfindingsskridt rettet mod tunnelkonfigurationen vil overse en dobbeltadresse på serversiden.

Start med Windows-hændelsesloggen, ikke klientloggen

Windows registrerer adressekonflikter i Systemloggen med hændelses-id 4198 og 4199. Den første rapporterer en konflikt, der er fundet for en adresse, den anden rapporterer, at en grænseflade ikke kunne bruge den adresse, den var konfigureret med. Ingen af dem nævner OpenVPN, og det er netop derfor, de er nemme at overse.

Hent de seneste hændelser, og sammenlign deres tidsstempler med adapterens fornyelsescyklus: 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, der forsøger den samme adresse igen over for en ejer, der bliver ved med at svare på den. En enkelt konflikt ved forbindelsestidspunktet peger i stedet på et engangssammenstød. Uanset hvad er det næste spørgsmål, hvem der ellers har adressen.

Tre ordninger sætter to værter på én adresse

Spørg serveren, hvem den mener har adressen, og spørg derefter netværket, hvem der svarer på den. grep -H ifconfig-push /etc/openvpn/ccd/* viser hver fastgjort tunneladresse og det certifikat, den hører til. ip -4 neigh show dev tap0 viser, hvad broen har lært på lag to. At sammenligne de to lister finder de fleste dubletter på under et minut.

Tre ordninger forklarer næsten alle: en client-config-dir-post fastgør én adresse til to certifikater, et broet tap-segment giver en maskine en adresse, som en anden vært allerede har statisk, eller en forældet lease-fil returnerer en adresse, som en klient, der stadig er forbundet, mener den ejer. Det tredje tilfælde er det snigende, fordi ifconfig-pool-persist bevidst genbruger adresser til kendte klienter.

Gør adressen unik i stedet for at kapløbe om den

Startrækkefølgen afgør kun, hvem der vinder i dag, så behandl enhver rettelse baseret på genstartsrækkefølge som midlertidig. Giv hver klient sin egen ifconfig-push-linje, eller tildel statiske adresser fra et interval, som ingen bro- eller servergrænseflade rører. Gennemgå også klientlisten for dobbelte common names, fordi duplicate-cn lader to sessioner dele én identitet og dermed én fastgjort adresse. Hvis en broet enhed virkelig har brug for en fast adresse, flyt den til sit eget undernet, eller reserver den fra puljen på et sted, som serveren registrerer.

Slet kun persist-filen, når du ved, hvilke leases den holder, ellers uddeler den næste genforbindelse de samme adresser igen.

Genstart i den rigtige rækkefølge, og bekræft én ejer per adresse

Anvend ændringen på serveren først, og genforbind derefter klienterne, så hver deltager registrerer sig mod den rettede pulje. Hvis klienterne genstartes først, beholder de adresser, som serveren stadig mener er optaget. Efter genstarten skal du læse statusfilen og bekræfte, at hvert common name optræder én gang med én adresse. To poster for ét navn betyder, at en gammel session aldrig blev lukket, ikke at puljen er i stykker.

Hvis en klient stadig ikke kan beholde sin adresse, skal du kontrollere, om en brogrænseflade på samme vært bærer den. En bro, der har arvet en adresse fra en leverandørenhed, svarer på ARP for den, selv når VPN-serveren allerede har givet adressen til en klient.

Hold øje gennem en fuld fornyelsescyklus, før du lukker sagen

Én ren aflæsning beviser intet. Hold øje med adapteren i mindst ti minutter, og fremtving en genforbindelse midt i: Get-NetIPAddress -InterfaceAlias "OpenVPN*" | Select-Object IPAddress,AddressState. Adressen bør overleve genforbindelsen og forblive i en foretrukken tilstand.

Kør derefter hændelsesforespørgslen fra første trin igen, og bekræft, at den ikke returnerer noget nyt. En tavs log gennem en genforbindelse er beviset på, at konflikten er væk, mens en tavs log efter en enkelt forbindelse kun betyder, at kapløbet endnu ikke er sket. Test til sidst den ressource, som tunnelen findes for, fordi en bro, der mistede sin adresse, kan ødelægge en leverandørvej, mens selve VPN'et ser sundt ud.

Skriv puljeintervallet, hver fastgjort adresse og den vært, der ejer den, i servernoterne. Så tager det minutter at få øje på det næste sammenstød i stedet for en hel eftermiddag at genopdage det.