Een lokaal IP-adresconflict oplossen na verbinding met een VPN

Al deze meldingen klinken hetzelfde en betekenen iets anders: de laptop klaagt over een adresconflict, maar slechts af en toe, en meestal terwijl de VPN actief is. Drie verschillende storingen veroorzaken die melding: een echte dubbeling op je eigen verbinding, een overlap waarbij het externe netwerk jouw LAN-bereik gebruikt en niets gedupliceerd is, en een tunnel die één adres aan twee peers heeft gegeven. De reparatie verschilt per geval, en de verkeerde verplaatst het symptoom in plaats van het weg te nemen. Bepaal dus eerst welk geval je hebt voordat je iets aanpast.

Drie storingen met één foutmelding

Een duplicaat betekent dat twee machines op hetzelfde segment allebei één adres opeisen. De kernel merkt dat omdat het antwoord op zijn eigen probe van een ander MAC komt, en wat er daarna gebeurt hangt van de stack af: Linux logt het, Windows schakelt de interface uit en schrijft een regel in het systeemlogboek, en een DHCP-client kan het aanbod weigeren.

Een overlap dupliceert helemaal geen adres. Je LAN is 192.168.1.0/24, het kantoornetwerk is ook 192.168.1.0/24, en nu wijst de route naar kantoor naar adressen die ook je printer en je NAS zijn. Niets is in conflict in de ARP-zin; het pakket gaat simpelweg naar het verkeerde apparaat op een van de twee netwerken.

Een poolbotsing is de schuld van de tunnel zelf. Twee peers zijn met of krijgen hetzelfde tunneladres toegewezen, dus de server kan ze niet uit elkaar houden wanneer hij retourverkeer stuurt. Een van de twee clients ziet een werkende handshake en geen data, wat op een routeringsprobleem lijkt maar het niet is.

Test 1: staat het duplicaat op je eigen segment?

Begin met op te sommen welke adressen je machine echt heeft, niet welke je denkt te hebben ingesteld. Een adres van een VPN-adapter is privé voor de tunnel en is niet hetzelfde als het adres dat websites zien, dus een gedeelde publieke uitgang is geen conflict.

ip -br addr
ip neigh
ip route show table all | grep -E 'wg|tun|ppp'

Op Windows komt dezelfde informatie uit ipconfig /all en Get-NetIPAddress, met de buurcache in arp -a. Als het betwiste adres op de fysieke adapter staat en de melding ook zonder actieve VPN verschijnt, is de VPN een omstander en moet je ophouden die te onderzoeken.

Om een duplicaat te bewijzen in plaats van te gokken, peil je het adres vanaf een apparaat dat het niet bezit. arping -D verstuurt de peiling met een brongadres van nul, dus een antwoord van een onverwacht MAC bewijst dat een andere host al voor dat adres antwoordt.

sudo arping -D -I eth0 -c 3 192.168.1.50

Zoek daarna de eigenaar via de netwerkbeheerder in plaats van zelf een ander adres te kiezen. Statische toewijzingen die alleen in iemands notities staan, printers met een vast adres en reserveringen op de DHCP-server zijn de gebruikelijke boosdoeners, en een apparaat dat uit staat bezit nog steeds zijn lease.

Test 2: overlappen de twee netwerken elkaar?

Vergelijk de prefix die de tunnel je geeft met de prefixen op je eigen interfaces. Als het externe bereik gelijk is aan je LAN of dat omvat, is de fout een overlap, en het verraderlijke teken is dat een host die zonder VPN bereikbaar is donker wordt, of dat je eigen printer op een kantooradres antwoordt.

ip route get 192.168.1.10
ip -br addr show

De route-opzoeking vertelt je welke interface de kernel zou gebruiken, en dat antwoord is de hele diagnose. Als er tunnel staat voor een adres dat bij je lokale printer hoort, heb je een overlap en hoe vaak je de lease ook vernieuwt, dat verandert niets.

Er zijn drie eerlijke uitwegen, en meestal is er maar één beschikbaar voor jou. De externe kant kan verkeer voor het overlappende subnet masqueraden, zodat je client alleen het tunneladres van de server ziet. De tunnel kan een smaller extern prefix vervoeren dat niet botst met je LAN. Of de client kan met beleidsregels op bronadres routeren, wat werkt maar kwetsbaar is en lastig aan een collega over te dragen.

Het kantoor netwerk hernummeren is zelden jouw beslissing. Je eigen LAN hernummeren om de botsing te ontwijken is een grotere verandering dan de meeste mensen verwachten zodra printers, camera's en statische hosts meespelen.

Test 3: heeft de tunnel één adres twee keer uitgegeven?

WireGuard heeft geen adressenpool. Elke peer wordt geïdentificeerd door zijn publieke sleutel en door de prefixen in AllowedIPs, dus een duplicaat ontstaat wanneer hetzelfde tunneladres in twee peer-regels wordt geschreven of hetzelfde sleutelpaar op twee machines wordt geïnstalleerd.

wg show all allowed-ips
wg show wg0 latest-handshakes
wg show wg0 transfer

Verkeerstellers zijn hier de nuttige kolom: een peer met een recente handshake maar zonder overdracht is verkeerd geadresseerd of wordt overschaduwd door een andere regel die hetzelfde prefix opeist. Zet een prefix op precies één peer en geef elk apparaat zijn eigen sleutelpaar.

OpenVPN heeft wel een pool, en de gebruikelijke botsing is een gedeeld clientprofiel met een vaste --ifconfig-regel dat naar een tweede machine is gekopieerd. Beide clients vragen dan hetzelfde tunneladres aan, en de server accepteert de sessie die hij het eerst verwerkt. Pooluitputting met --duplicate-cn geeft een vergelijkbaar resultaat wanneer meerdere sessies van één certificaat om één regel strijden.

Lees hiervoor de serverlog in plaats van de clientlog. De server weet welke sessie welk adres heeft opgeëist, en herhaalde adressen zijn daar zichtbaar als waarschuwingen die de client nooit bereiken.

Repareer bij de bron en controleer daarna beide apparaten

De volgorde is belangrijk. Los eerst een LAN-duplicaat op, want een client die geen adres kan houden, kan ook geen tunnel vasthouden. Repareer daarna de toewijzing aan de VPN-kant, want een aanpassing aan een pooltoewijzing op de client wordt bij de volgende verbinding ongedaan gemaakt. Pak ten slotte dubbele identiteiten aan: aparte sleutelparen op WireGuard, aparte certificaten of op zijn minst aparte profielen op OpenVPN.

Op de client is het mechanische deel kort. Geef een DHCP-lease vrij en vraag een nieuwe aan, of vraag om het adres op de server voor een reservering te wijzigen. Typ geen willekeurig adres dat er vrij uitziet.

sudo dhclient -r eth0 && sudo dhclient eth0
ipconfig /release && ipconfig /renew

Controleer daarna vanaf beide uiteinden, niet vanaf één. Bevestig de gateway, dan de dienst die je echt nodig hebt, en verbind daarna opnieuw en herhaal. Als er twee apparaten bij betrokken waren, controleer ze beide: het verplaatsen van één adres laat het andere achter met verouderde buurentries of een oude lease die later terugkomt.

Wat je onderweg niet moet doen

Demp het symptoom niet. Duplicate address detection is wat voorkomt dat je een adres neemt dat al in gebruik is, en het uitschakelen ervan verandert een zichtbaar conflict in intermitterend pakketverlies dat veel moeilijker te traceren is. Hetzelfde geldt voor het accepteren van een certificaatwaarschuwing van een onverwachte host: dat is helemaal geen adresprobleem, en er doorheen klikken verbergt een andere storing.

Verander de adressering van een beheerd netwerk ook niet op eigen houtje. Leg de oorspronkelijke instelling vast, vraag het de eigenaar wanneer het adres centraal wordt toegewezen, en houd de wijziging klein genoeg om terug te draaien. De RFC 5227-regels voor het detecteren van adresconflicten leggen uit wat een correcte peiling bewijst, wat de moeite waard is om te weten voordat je een conflict echt noemt.