Åtgärda en lokal IP-adresskonflikt efter anslutning till en VPN

Alla dessa rapporter låter likadana och betyder olika saker: datorn klagar på en adresskonflikt, men bara ibland, och mest medan VPN:et är uppe. Tre olika fel ger det meddelandet: en verklig dubblett på din egen länk, en överlappning där fjärrnätverket använder ditt LAN-intervall och ingenting alls är dubblerat, och en tunnel som gav en adress till två peers. Reparationen skiljer sig i varje fall, och den felaktiga flyttar symptomet i stället för att ta bort det. Bestäm därför vilket fall du har innan du ändrar något.

Tre fel som delar ett felmeddelande

En dubblett betyder att två maskiner på samma segment båda gör anspråk på en adress. Kärnan märker det eftersom svaret på dess egen sond kommer från en annan MAC-adress, och vad som händer sedan beror på stacken: Linux loggar det, Windows inaktiverar gränssnittet och skriver en post i systemloggen, och en DHCP-klient kan avböja erbjudandet.

En överlappning dubblerar ingen adress alls. Ditt LAN är 192.168.1.0/24, kontorsnätet är också 192.168.1.0/24, och nu pekar rutten till kontoret på adresser som också är din skrivare och din NAS. Ingenting är i konflikt i ARP-mening; paketet går helt enkelt till fel enhet i ett av de två nätverken.

En poolkollision är tunnelns eget fel. Två peers konfigurerades med eller tilldelades samma tunneladress, så servern kan inte skilja dem åt när den skickar returtrafik. En av de två klienterna ser en fungerande handskakning och ingen data, vilket låter som ett routningsproblem men inte är det.

Test 1: sitter dubbletten på ditt eget segment?

Börja med att lista vad din maskin faktiskt har, inte vad du minns att du konfigurerade. En VPN-adapters adress är privat för tunneln och är inte samma adress som webbplatser ser, så en delad publik utgång är ingen konflikt.

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

I Windows kommer samma information från ipconfig /all och Get-NetIPAddress, med granncachen i arp -a. Om den omtvistade adressen sitter på det fysiska gränssnittet och klagomålet dyker upp utan att VPN:et körs, är VPN:et en åskådare och du bör sluta felsöka det.

För att bevisa en dubblett i stället för att gissa, sondera adressen från en enhet som inte äger den. arping -D skickar sonden med en nollbaserad källadress, så ett svar från en oväntad MAC bevisar att en annan värd redan svarar för adressen.

sudo arping -D -I eth0 -c 3 192.168.1.50

Hitta sedan ägaren via nätverksadministratören i stället för att själv välja en annan adress. Statiska tilldelningar som bara finns i någons anteckningar, skrivare med fast adress och reservationer på DHCP-servern är de vanliga bovarna, och en enhet som är avstängd äger fortfarande sin lease.

Test 2: överlappar de två nätverken varandra?

Jämför prefixet som tunneln ger dig med prefixen på dina egna gränssnitt. Om fjärrintervallet är lika med eller innehåller ditt LAN är felet en överlappning, och det avslöjande tecknet är att en värd som nås utan VPN:et blir svart, eller att din egen skrivare svarar på en kontorsadress.

ip route get 192.168.1.10
ip -br addr show

Routuppslaget berättar vilket gränssnitt kärnan skulle använda, och det svaret är hela diagnosen. Om det säger tunneln för en adress som tillhör din lokala skrivare har du en överlappning och hur mycket du än förnyar leasen ändras det inte.

Det finns tre ärliga vägar ut, och bara en är vanligtvis tillgänglig för dig. Fjärrsidan kan maskera trafik för det överlappande subnätet, så din klient bara ser serverns tunneladress. Tunneln kan bära ett smalare fjärrprefix som inte kolliderar med ditt LAN. Eller så kan klienten routa efter källadress med policyregler, vilket fungerar men är ömtåligt och svårt att lämna över till en kollega.

Att numrera om kontorsnätet är sällan ditt beslut. Att numrera om ditt eget LAN för att undvika kollisionen är en större förändring än de flesta väntar sig när skrivare, kameror och statiska värdar är inblandade.

Test 3: delade tunneln ut en adress två gånger?

WireGuard har ingen adresspool. Varje peer identifieras av sin publika nyckel och av prefixen i AllowedIPs, så en dubblett uppstår när samma tunneladress skrivs in i två peer-poster eller samma nyckelpar installeras på två maskiner.

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

Trafikräknare är den användbara kolumnen här: en peer som visar en nylig handskakning men ingen överföring är antingen feladresserad eller överskuggad av en annan post som gör anspråk på samma prefix. Sätt ett prefix på exakt en peer och ge varje enhet sitt eget nyckelpar.

OpenVPN har en pool, och den vanliga kollisionen är en delad klientprofil med en fast --ifconfig-rad kopierad till en andra maskin. Båda klienterna begär då samma tunneladress, och servern accepterar den session den behandlar först. Utmattning av poolen med --duplicate-cn ger ett liknande resultat när flera sessioner av ett certifikat tävlar om en post.

Läs serverloggen i stället för klientloggen för det här. Servern vet vilken session som gjorde anspråk på vilken adress, och upprepade adresser syns där som varningar som aldrig når klienten.

Reparera vid källan och kontrollera sedan båda enheterna

Ordningen spelar roll. Åtgärda först en LAN-dubblett, för en klient som inte kan behålla en adress kan inte heller hålla en tunnel. Åtgärda sedan provisioneringen på VPN-sidan, för en klientändring av en pooltilldelning ångras vid nästa anslutning. Ta till sist itu med dubblerade identiteter: separata nyckelpar på WireGuard, separata certifikat eller åtminstone separata profiler på OpenVPN.

På klienten är den mekaniska delen kort. Släpp och förnya en DHCP-lease, eller be att adressen ändras på servern för en reservation. Skriv inte in en slumpmässig adress som ser ledig ut.

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

Verifiera sedan från båda ändar, inte en. Bekräfta gatewayen, sedan tjänsten du faktiskt behöver, och återanslut därefter och upprepa. Om två enheter var inblandade, kontrollera båda: att flytta en adress lämnar den andra med inaktuella grannposter eller en gammal lease som dyker upp igen senare.

Vad du inte ska göra på vägen

Tysta inte symptomet. Duplicate address detection är det som hindrar dig från att ta en adress som redan används, och att stänga av det förvandlar en synlig konflikt till intermittent paketförlust som är mycket svårare att spåra. Samma sak gäller att acceptera en certifikatvarning från en oväntad värd: det är inte alls ett adressproblem, och att klicka igenom den döljer ett annat fel.

Ändra inte heller adresseringen i ett hanterat nätverk på egen hand. Anteckna den ursprungliga inställningen, fråga ägaren när adressen tilldelas centralt, och håll ändringen liten nog att backa. RFC 5227 regler för detektering av adresskonflikter förklarar vad en korrekt sond bevisar, vilket är värt att veta innan du kallar en konflikt verklig.