OpenVPN-adapter flappert op Windows? Controleer op een dubbele IP

Op Windows is een OpenVPN-adapter die een adres neemt, het weer loslaat en dat elke paar seconden herhaalt meestal geen DHCP-bug. De adapter krijgt de opdracht een adres te gebruiken waar al iets anders op antwoordt, dus markeert Windows het als onbruikbaar en begint de client opnieuw. Het clientlog blijft stil omdat het conflict eronder wordt opgelost, binnen de eigen netwerkstack van het besturingssysteem.

Dat onderscheid is belangrijk, want elke troubleshootingsstap gericht op de tunnelconfiguratie zal een dubbel adres aan de serverkant missen.

Begin met het Windows-gebeurtenislog, niet met het clientlog

Windows registreert adresconflicten in het systeemlog, met gebeurtenis-ID's 4198 en 4199. De eerste meldt een conflict dat voor een adres is gevonden, de tweede meldt dat een interface het adres niet kon gebruiken waarmee hij was geconfigureerd. Geen van beide noemt OpenVPN, en juist daarom zijn ze makkelijk over het hoofd te zien.

Haal de recente gebeurtenissen op en vergelijk hun tijdstempels met de vernieuwingscyclus van de adapter: Get-WinEvent -FilterHashtable @{LogName='System'; Id=4198,4199} -MaxEvents 40 | Format-Table TimeCreated,Id,Message -Wrap. Een conflict elke vijftien seconden past bij een client die hetzelfde adres opnieuw probeert tegen een eigenaar die erop blijft antwoorden. Een enkel conflict bij het verbinden wijst juist op een eenmalige botsing. Hoe dan ook, de volgende vraag is wie het adres nog meer heeft.

Drie opstellingen zetten twee hosts op één adres

Vraag de server wie volgens hem het adres heeft, en vraag dan het netwerk wie erop antwoordt. grep -H ifconfig-push /etc/openvpn/ccd/* somt elk vastgezet tunneladres op en het certificaat waartoe het behoort. ip -4 neigh show dev tap0 laat zien wat de bridge op laag twee heeft geleerd. Het vergelijken van die twee lijsten vindt de meeste duplicaten in minder dan een minuut.

Drie opstellingen verklaren bijna alles: een item in client-config-dir zet één adres vast voor twee certificaten, een overbrugd tap-segment geeft een machine een adres dat een andere host al statisch heeft, of een verouderd lease-bestand geeft een adres terug waarvan een nog verbonden client denkt dat hij het bezit. Het derde geval is het gemeenste, omdat ifconfig-pool-persist opzettelijk adressen hergebruikt voor bekende clients.

Maak het adres uniek in plaats van erom te racen

De opstartvolgorde bepaalt alleen wie vandaag wint, dus behandel elke correctie die op de herstartvolgorde berust als tijdelijk. Geef elke client zijn eigen ifconfig-push-regel, of ken statische adressen toe uit een bereik dat geen bridge- of serverinterface raakt. Controleer de clientlijst ook op dubbele common names, want duplicate-cn laat twee sessies één identiteit en dus één vastgezet adres delen. Als een overbrugd apparaat echt een vast adres nodig heeft, verplaats het naar zijn eigen subnet of reserveer het uit de pool op een plek die de server vastlegt.

Verwijder het persist-bestand pas als je weet welke leases het bevat, anders deelt de volgende herverbinding dezelfde adressen opnieuw uit.

Herstart in de juiste volgorde en bevestig één eigenaar per adres

Pas de wijziging eerst op de server toe en verbind daarna de clients opnieuw, zodat elke deelnemer zich tegen de gecorrigeerde pool registreert. Als je de clients eerst herstart, houden ze adressen die de server nog als bezet beschouwt. Lees na de herstart het statusbestand en bevestig dat elke common name één keer met één adres voorkomt. Twee vermeldingen voor één naam betekenen dat een oude sessie nooit is gesloten, niet dat de pool stuk is.

Als een client zijn adres nog steeds niet kan behouden, controleer dan of een bridge-interface op dezelfde host het draagt. Een bridge die een adres van een leveranciersapparaat heeft geërfd, antwoordt ARP ervoor, zelfs wanneer de VPN-server dat adres al aan een client heeft gegeven.

Kijk een volledige vernieuwingscyclus lang mee voordat je het ticket sluit

Eén schone meting bewijst niets. Houd de adapter minstens tien minuten in het oog en forceer halverwege een herverbinding: Get-NetIPAddress -InterfaceAlias "OpenVPN*" | Select-Object IPAddress,AddressState. Het adres hoort de herverbinding te overleven en in een voorkeursstatus te blijven.

Voer daarna de gebeurtenisquery van de eerste stap opnieuw uit en bevestig dat die niets nieuws teruggeeft. Een stil log over een herverbinding heen is het bewijs dat het conflict weg is, terwijl een stil log na één verbinding alleen betekent dat de race nog niet heeft plaatsgevonden. Test ten slotte de resource waarvoor de tunnel bestaat, want een bridge die zijn adres kwijt is kan een leverancierspad breken terwijl de VPN zelf gezond lijkt.

Noteer het poolbereik, elk vastgezet adres en de host die het bezit in de servernotities. De volgende botsing is dan binnen enkele minuten te zien in plaats van een hele middag opnieuw te moeten worden ontdekt.