Oprava konfliktu místní IP adresy po připojení k VPN

Každé z těchto hlášení zní stejně a znamená něco jiného: notebook si stěžuje na konflikt adres, ale jen někdy a většinou když je VPN aktivní. Tři samostatné závady dávají tuto zprávu: skutečný duplikát na vašem vlastním spoji, překryv, kdy vzdálená síť používá váš rozsah LAN a nic se neduplikuje, a tunel, který dal jednu adresu dvěma protějškům. Oprava se v každém případě liší a ta špatná symptom přesouvá, místo aby ho odstranila. Rozhodněte tedy, který případ máte, než cokoli upravíte.

Tři závady se stejnou chybovou zprávou

Duplikát znamená, že dva stroje ve stejném segmentu si nárokují jednu adresu. Jádro si toho všimne, protože odpověď na jeho vlastní sondu přichází z jiného MAC, a co se stane dál, závisí na zásobníku: Linux to zapíše do logu, Windows rozhraní vypne a zapíše záznam do systémového logu, a DHCP klient může nabídku odmítnout.

Překryv neduplikuje žádnou adresu. Vaše LAN je 192.168.1.0/24, síť v kanceláři je také 192.168.1.0/24, a teď trasa do kanceláře ukazuje na adresy, které jsou zároveň vaše tiskárna a vaše NAS. Ve smyslu ARP není nic v konfliktu; paket prostě jde na špatné zařízení v jedné ze dvou sítí.

Kolize v poolu je chyba samotného tunelu. Dva protějšky byly nakonfigurovány se stejnou adresou tunelu nebo ji dostaly, takže je server při odesílání zpětného provozu nerozliší. Jeden ze dvou klientů vidí fungující handshake a žádná data, což se čte jako problém směrování a není.

Test 1: je duplikát na vašem vlastním segmentu?

Začněte výpisem toho, co váš stroj skutečně drží, ne toho, co si pamatujete, že jste nastavili. Adresa adaptéru VPN je soukromá pro tunel a není stejná jako adresa, kterou vidí weby, takže sdílený veřejný výstup není konflikt.

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

Ve Windows stejné informace dávají ipconfig /all a Get-NetIPAddress, s cache sousedů v arp -a. Pokud je sporná adresa na fyzickém adaptéru a stížnost se objeví bez běžící VPN, je VPN jen divák a měli byste přestat diagnostikovat ji.

Abyste duplikát dokázali místo hádání, otestujte adresu ze zařízení, které ji nevlastní. arping -D posílá sondu s nulovou zdrojovou adresou, takže odpověď z nečekaného MAC dokazuje, že na tuto adresu už odpovídá jiný hostitel.

sudo arping -D -I eth0 -c 3 192.168.1.50

Potom najděte vlastníka přes správce sítě, místo abyste si sami vybrali jinou adresu. Statická přiřazení, která žijí jen v něčích poznámkách, tiskárny s pevnou adresou a rezervace na DHCP serveru jsou obvyklí viníci, a vypnuté zařízení stále vlastní svůj pronájem.

Test 2: překrývají se obě sítě?

Porovnejte prefix, který vám tunel dává, s prefixy na vašich rozhraních. Pokud se vzdálený rozsah rovná vaší LAN nebo ji obsahuje, závadou je překryv, a vodítkem je, že hostitel dostupný bez VPN zmizí, nebo vaše tiskárna odpovídá na kancelářskou adresu.

ip route get 192.168.1.10
ip -br addr show

Vyhledání trasy vám řekne, které rozhraní by jádro použilo, a tato odpověď je celá diagnóza. Pokud u adresy, která patří vaší místní tiskárně, uvede tunel, máte překryv a žádné obnovení pronájmu to nezmění.

Existují tři poctivé cesty ven a obvykle je dostupná jen jedna. Vzdálená strana může maskovat provoz pro překrývající se podsíť, takže váš klient vidí jen adresu tunelu serveru. Tunel může nést užší vzdálený prefix, který s vaší LAN nekoliduje. Nebo může klient směrovat podle zdrojové adresy pomocí pravidel zásad, což funguje, ale je křehké a těžko předatelné kolegovi.

Přečíslování kancelářské sítě je málokdy vaše rozhodnutí. Přečíslování vlastní LAN, abyste se kolizi vyhnuli, je větší změna, než většina lidí čeká, jakmile jsou ve hře tiskárny, kamery a statičtí hostitelé.

Test 3: přidělil tunel jednu adresu dvakrát?

WireGuard žádný pool adres nemá. Každý protějšek je identifikován svým veřejným klíčem a prefixy v AllowedIPs, takže duplikát vznikne, když je stejná adresa tunelu zapsána do dvou záznamů protějšků nebo je stejný pár klíčů nainstalován na dvou strojích.

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

Počítadla provozu jsou zde užitečný sloupec: protějšek, který ukazuje nedávný handshake, ale žádný přenos, je buď špatně adresovaný, nebo ho zastiňuje jiný záznam nárokující si stejný prefix. Dejte prefix právě jednomu protějšku a každému zařízení jeho vlastní pár klíčů.

OpenVPN pool má a častou kolizí je sdílený klientský profil s pevným řádkem --ifconfig zkopírovaný na druhý stroj. Pak oba klienti žádají stejnou adresu tunelu a server přijme tu session, kterou zpracuje první. Vyčerpání poolu s --duplicate-cn dává podobný výsledek, když několik session jednoho certifikátu soutěží o jeden záznam.

Pro tento případ čtěte log serveru, ne log klienta. Server ví, která session si nárokovala kterou adresu, a opakující se adresy jsou tam vidět jako varování, která se ke klientovi nikdy nedostanou.

Opravte u zdroje a potom znovu zkontrolujte obě zařízení

Na pořadí záleží. Nejprve opravte duplikát v LAN, protože klient, který neudrží adresu, neudrží ani tunel. Potom opravte zřizování na straně VPN, protože klientská úprava přiřazení z poolu se při dalším připojení zruší. Nakonec se vypořádejte s duplikovanými identitami: samostatné páry klíčů ve WireGuardu, samostatné certifikáty nebo alespoň samostatné profily v OpenVPN.

U klienta je mechanická část krátká. Uvolněte a obnovte DHCP pronájem, nebo požádejte o změnu adresy na serveru kvůli rezervaci. Nepište náhodnou adresu, která vypadá volná.

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

Pak ověřte z obou konců, ne z jednoho. Potvrďte bránu, potom službu, kterou skutečně potřebujete, potom se znovu připojte a opakujte. Pokud byla zapojena dvě zařízení, zkontrolujte obě: přesun jedné adresy nechá to druhé se zastaralými záznamy sousedů nebo starým pronájmem, který se později vrátí.

Co cestou nedělat

Neumlčujte symptom. Detekce duplicitních adres je to, co vám brání vzít adresu, která se už používá, a její vypnutí mění viditelný konflikt na občasné ztráty paketů, které se hledají mnohem obtížněji. Totéž platí pro přijetí varování o certifikátu od nečekaného hostitele: to vůbec není problém s adresou a prokliknutí skrývá jinou závadu.

Nezměňujte také adresování spravované sítě sami. Zapište původní nastavení, zeptejte se vlastníka, když se adresa přiděluje centrálně, a držte změnu dost malou na to, aby šla vrátit. Pravidla RFC 5227 pro detekci konfliktů adres vysvětlují, co správná sonda dokazuje, což stojí za to vědět, než konflikt označíte za skutečný.