Napraw konflikt lokalnego adresu IP po połączeniu z VPN

Wszystkie te komunikaty brzmią tak samo i znaczą coś innego: laptop zgłasza konflikt adresu, ale tylko czasami i najczęściej przy włączonym VPN. Trzy różne usterki dają ten komunikat: prawdziwy duplikat w Twojej własnej sieci, nakładanie się, w którym sieć zdalna używa Twojego zakresu LAN i nic nie jest zduplikowane, oraz tunel, który przydzielił jeden adres dwóm peerom. Naprawa jest inna w każdym przypadku, a niewłaściwa przenosi objaw, zamiast go usunąć. Zdecyduj więc, który przypadek masz, zanim cokolwiek zmienisz.

Trzy usterki o jednym komunikacie błędu

Duplikat oznacza, że dwie maszyny w tym samym segmencie roszczą sobie jeden adres. Jądro to zauważa, bo odpowiedź na jego własną sondę przychodzi z innego adresu MAC, a to, co dzieje się dalej, zależy od stosu: Linux zapisuje to w logu, Windows wyłącza interfejs i zapisuje wpis w logu systemowym, a klient DHCP może odrzucić ofertę.

Nakładanie się nie duplikuje żadnego adresu. Twoja sieć LAN to 192.168.1.0/24, sieć biurowa też ma 192.168.1.0/24, a teraz trasa do biura wskazuje adresy, które są również Twoją drukarką i Twoim NAS. Nic nie jest w konflikcie w sensie ARP; pakiet po prostu trafia do niewłaściwego urządzenia w jednej z dwóch sieci.

Kolizja w puli to wina samego tunelu. Dwa peery skonfigurowano z tym samym adresem tunelu albo przydzielono im go, więc serwer nie potrafi ich rozróżnić, wysyłając ruch powrotny. Jeden z dwóch klientów widzi działający handshake i brak danych, co wygląda na problem z routingiem, ale nim nie jest.

Test 1: czy duplikat jest w Twoim własnym segmencie?

Zacznij od wypisania tego, co Twoja maszyna naprawdę ma, a nie tego, co pamiętasz, że skonfigurowałeś. Adres adaptera VPN jest prywatny dla tunelu i nie jest tym samym adresem, który widzą strony internetowe, więc współdzielone publiczne wyjście nie jest konfliktem.

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

W Windows te same informacje pochodzą z ipconfig /all i Get-NetIPAddress, a pamięć podręczna sąsiadów jest w arp -a. Jeśli sporny adres jest na karcie fizycznej, a komunikat pojawia się bez włączonego VPN, VPN jest tylko obserwatorem i powinieneś przestać go diagnozować.

Aby udowodnić duplikat, a nie zgadywać, sonduj adres z urządzenia, które go nie posiada. arping -D wysyła sondę z zerowym adresem źródłowym, więc odpowiedź z nieoczekiwanego adresu MAC dowodzi, że inny host już odpowiada za ten adres.

sudo arping -D -I eth0 -c 3 192.168.1.50

Potem znajdź właściciela przez administratora sieci, zamiast samemu wybierać inny adres. Przypisania statyczne żyjące tylko w czyichś notatkach, drukarki ze stałym adresem i rezerwacje na serwerze DHCP to zwykli winowajcy, a wyłączone urządzenie nadal posiada swoją dzierżawę.

Test 2: czy dwie sieci się nakładają?

Porównaj prefiks, który daje Ci tunel, z prefiksami na własnych interfejsach. Jeśli zakres zdalny jest równy Twojej sieci LAN lub ją zawiera, usterką jest nakładanie się, a zdradza je to, że host osiągalny bez VPN gaśnie albo Twoja własna drukarka odpowiada na adres biurowy.

ip route get 192.168.1.10
ip -br addr show

Wyszukiwanie trasy mówi, którego interfejsu użyłoby jądro, i ta odpowiedź to cała diagnoza. Jeśli dla adresu należącego do Twojej lokalnej drukarki wskazuje tunel, masz nakładanie się i żadne odnawianie dzierżawy tego nie zmieni.

Są trzy uczciwe drogi wyjścia, a zwykle dostępna jest dla Ciebie tylko jedna. Strona zdalna może maskować ruch dla nakładającej się podsieci, dzięki czemu klient widzi tylko adres tunelu serwera. Tunel może przenosić węższy prefiks zdalny, który nie koliduje z Twoją siecią LAN. Albo klient może routować według adresu źródłowego za pomocą reguł polityki, co działa, ale jest kruche i trudne do przekazania koledze.

Zmiana numeracji sieci biurowej rzadko należy do Ciebie. Zmiana numeracji własnej sieci LAN, by uniknąć kolizji, to większa zmiana, niż większość ludzi się spodziewa, gdy w grę wchodzą drukarki, kamery i hosty ze statycznymi adresami.

Test 3: czy tunel przydzielił jeden adres dwa razy?

WireGuard nie ma puli adresów. Każdy peer jest identyfikowany przez swój klucz publiczny i przez prefiksy w AllowedIPs, więc duplikat pojawia się, gdy ten sam adres tunelu zostanie wpisany w dwa wpisy peerów albo ten sam klucz zostanie zainstalowany na dwóch maszynach.

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

Liczniki ruchu to przydatna kolumna: peer, który pokazuje świeży handshake, ale brak transferu, jest albo źle zaadresowany, albo przyćmiony przez inny wpis roszczący sobie ten sam prefiks. Przypisz prefiks dokładnie jednemu peerowi i daj każdemu urządzeniu własną parę kluczy.

OpenVPN ma pulę, a typowa kolizja to współdzielony profil klienta ze stałą linią --ifconfig skopiowany na drugą maszynę. Oba klienty proszą wtedy o ten sam adres tunelu, a serwer akceptuje tę sesję, którą przetworzy pierwszą. Wyczerpanie puli z --duplicate-cn daje podobny wynik, gdy kilka sesji jednego certyfikatu konkuruje o jeden wpis.

Czytaj log serwera, a nie log klienta. Serwer wie, która sesja zajęła który adres, a powtarzające się adresy widać tam jako ostrzeżenia, które nigdy nie docierają do klienta.

Napraw u źródła, potem sprawdź oba urządzenia

Kolejność ma znaczenie. Najpierw napraw duplikat w sieci LAN, bo klient, który nie potrafi utrzymać adresu, nie utrzyma też tunelu. Potem napraw przydzielanie po stronie VPN, bo zmiana przypisania z puli po stronie klienta jest cofana przy następnym połączeniu. Na końcu zajmij się zduplikowanymi tożsamościami: osobne pary kluczy w WireGuard, osobne certyfikaty albo przynajmniej osobne profile w OpenVPN.

Po stronie klienta część mechaniczna jest krótka. Zwolnij i odnów dzierżawę DHCP albo poproś o zmianę adresu na serwerze dla rezerwacji. Nie wpisuj losowego adresu, który wygląda na wolny.

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

Potem sprawdź z obu końców, nie z jednego. Potwierdź bramę, potem usługę, której naprawdę potrzebujesz, a następnie połącz się ponownie i powtórz. Jeśli w grę wchodziły dwa urządzenia, sprawdź oba: przeniesienie jednego adresu zostawia drugie z nieaktualnymi wpisami sąsiadów albo starą dzierżawą, która wróci później.

Czego nie robić po drodze

Nie wyciszaj objawu. Wykrywanie zduplikowanych adresów to właśnie to, co powstrzymuje Cię przed zajęciem adresu już używanego, a wyłączenie go zamienia widoczny konflikt w sporadyczną utratę pakietów, którą znacznie trudniej prześledzić. To samo dotyczy akceptowania ostrzeżenia o certyfikacie od nieoczekiwanego hosta: to wcale nie jest problem z adresem, a kliknięcie go ukrywa inną usterkę.

Nie zmieniaj też samodzielnie adresacji sieci zarządzanej. Zapisz pierwotne ustawienie, zapytaj właściciela, gdy adres jest przydzielany centralnie, i utrzymaj zmianę na tyle małą, by dało się ją cofnąć. Zasady wykrywania konfliktów adresów z RFC 5227 wyjaśniają, co dowodzi poprawna sonda, co warto wiedzieć, zanim uznasz konflikt za prawdziwy.