Adapter OpenVPN migocze w Windows? Sprawdź duplikat adresu IP

W Windows adapter OpenVPN, który pobiera adres, porzuca go i powtarza to co kilka sekund, zwykle nie jest błędem DHCP. Adapterowi każe się używać adresu, na który już odpowiada coś innego, więc Windows oznacza go jako bezużyteczny i klient zaczyna od nowa. Dziennik klienta pozostaje cichy, bo konflikt jest rozwiązywany poniżej, w samym stosie sieciowym systemu operacyjnego.

To rozróżnienie ma znaczenie, ponieważ każdy krok diagnozy skierowany na konfigurację tunelu pominie zduplikowany adres po stronie serwera.

Zacznij od dziennika zdarzeń Windows, a nie od dziennika klienta

Windows zapisuje konflikty adresów w dzienniku systemowym, z identyfikatorami zdarzeń 4198 i 4199. Pierwszy zgłasza wykryty konflikt dla adresu, drugi zgłasza, że interfejs nie mógł użyć adresu, z którym został skonfigurowany. Żaden z nich nie wspomina OpenVPN i właśnie dlatego łatwo je przeoczyć.

Pobierz ostatnie zdarzenia i porównaj ich znaczniki czasu z cyklem odnowienia adaptera: Get-WinEvent -FilterHashtable @{LogName='System'; Id=4198,4199} -MaxEvents 40 | Format-Table TimeCreated,Id,Message -Wrap. Konflikt co piętnaście sekund odpowiada klientowi, który ponawia ten sam adres wobec właściciela nadal na niego odpowiadającego. Pojedynczy konflikt w momencie połączenia wskazuje raczej na jednorazową kolizję. Tak czy inaczej, następne pytanie brzmi, kto jeszcze ma ten adres.

Trzy układy stawiają dwa hosty na jednym adresie

Zapytaj serwer, kto jego zdaniem ma adres, a potem zapytaj sieć, kto na niego odpowiada. grep -H ifconfig-push /etc/openvpn/ccd/* wymienia każdy przypięty adres tunelu i certyfikat, do którego należy. ip -4 neigh show dev tap0 pokazuje, czego most nauczył się w drugiej warstwie. Porównanie tych dwóch list znajduje większość duplikatów w mniej niż minutę.

Trzy układy wyjaśniają prawie wszystkie przypadki: wpis w client-config-dir przypina jeden adres do dwóch certyfikatów, mostkowany segment tap daje maszynie adres, który inny host już ma statycznie, albo nieaktualny plik dzierżawy zwraca adres, który wciąż połączony klient uważa za swój. Trzeci przypadek jest najpodstępniejszy, bo ifconfig-pool-persist celowo ponownie używa adresów dla znanych klientów.

Uczyń adres unikalnym, zamiast ścigać się o niego

Kolejność rozruchu decyduje tylko o tym, kto wygra dziś, więc każdą poprawkę opartą na kolejności restartów traktuj jako tymczasową. Daj każdemu klientowi jego własną linię ifconfig-push albo przydzielaj statyczne adresy z zakresu, którego nie dotyka żaden interfejs mostu ani serwera. Przejrzyj też listę klientów pod kątem zduplikowanych nazw wspólnych, bo duplicate-cn pozwala dwóm sesjom dzielić jedną tożsamość, a więc i jeden przypięty adres. Jeśli mostkowane urządzenie naprawdę potrzebuje stałego adresu, przenieś je do własnej podsieci albo zarezerwuj go z puli w miejscu, które serwer rejestruje.

Usuń plik persist dopiero wtedy, gdy wiesz, jakie dzierżawy zawiera, inaczej następne ponowne połączenie znów rozda te same adresy.

Uruchom ponownie we właściwej kolejności i potwierdź jednego właściciela na adres

Najpierw zastosuj zmianę na serwerze, potem połącz klientów ponownie, aby każdy uczestnik zarejestrował się wobec poprawionej puli. Ponowne uruchomienie klientów jako pierwszych zostawia ich z adresami, które serwer nadal uważa za zajęte. Po restarcie odczytaj plik stanu i potwierdź, że każda nazwa wspólna występuje raz z jednym adresem. Dwa wpisy dla jednej nazwy oznaczają, że stara sesja nigdy się nie zamknęła, a nie że pula jest zepsuta.

Jeśli klient nadal nie może utrzymać swojego adresu, sprawdź, czy nie niesie go interfejs mostu na tym samym hoście. Most, który odziedziczył adres po urządzeniu dostawcy, odpowie na ARP dla niego nawet wtedy, gdy serwer VPN już przekazał ten adres klientowi.

Obserwuj przez pełny cykl odnowienia, zanim zamkniesz zgłoszenie

Jedno czyste odczytanie niczego nie dowodzi. Obserwuj adapter co najmniej dziesięć minut i wymuś w środku ponowne połączenie: Get-NetIPAddress -InterfaceAlias "OpenVPN*" | Select-Object IPAddress,AddressState. Adres powinien przetrwać ponowne połączenie i pozostać w preferowanym stanie.

Następnie uruchom ponownie zapytanie o zdarzenia z pierwszego kroku i potwierdź, że nie zwraca niczego nowego. Cichy dziennik w trakcie ponownego połączenia jest dowodem, że konflikt zniknął, podczas gdy cichy dziennik po jednym połączeniu oznacza tylko, że wyścig jeszcze nie nastąpił. Na koniec przetestuj zasób, dla którego istnieje tunel, bo most, który utracił adres, może zepsuć ścieżkę dostawcy, podczas gdy sam VPN wygląda zdrowo.

Zapisz zakres puli, każdy przypięty adres i hosta, który go posiada, w notatkach serwera. Wtedy następną kolizję zauważa się w kilka minut, zamiast poświęcać całe popołudnie na ponowne jej odkrycie.