OpenVPN TAP w macOS: sprawdź klienta, zanim zaczniesz debugować

Stary profil trafia na współczesnego Maca, klient importuje go bez skargi, a połączenie spada albo nigdy nie przepuszcza ruchu. Zanim spędzisz popołudnie nad certyfikatami, przeczytaj wiersz urządzenia w profilu. Jeśli widnieje tam dev tap, prosisz klienta o interfejs w stylu Ethernet, a w macOS właśnie na tym żądaniu kończy się większość takich sesji.

Krok 1: upewnij się, że profil naprawdę wymaga TAP

Profile są zmieniane nazwami, pakowane i eksportowane ponownie, więc sprawdź plik, który faktycznie zaimportowałeś. Poszukaj dyrektywy urządzenia i każdego include, który może ją nadpisać. W większości przypadków dwie linie wyjścia rozstrzygają sprawę. Gdy występują zarówno dev, jak i dev-type, wygrywa późniejsza dyrektywa, i właśnie taki szczegół ukrywa skopiowany profil.

grep -nE "^[[:space:]]*(dev|dev-type)[[:space:]]" client.ovpn
ls -l ~/Library/Application\ Support/ 2>/dev/null

Jeśli plik zawiera dev tap lub dev tap0, klient musi zaimplementować interfejs TAP. Jeśli zawiera dev tun, dalsza część artykułu nie ma zastosowania, a usterka jest gdzie indziej.

Zapisz nazwę i wersję klienta, wersję macOS i źródło profilu. Te trzy fakty decydują, która z dwóch poniższych dróg jest w ogóle możliwa.

Krok 2: wiedz, co naprawdę zmienia tryb urządzenia

Interfejs TUN przenosi pakiety IP. Klient czyta i zapisuje pakiety adresowane do peera IP, a system operacyjny trasuje je jak każdy inny interfejs.

Interfejs TAP przenosi ramki Ethernet, w tym broadcast i ARP. To pozwala mostkowanemu serwerowi rozdawać adresy przez DHCP, a klientowi odkrywać urządzenia przez wołanie, i dlatego niektóre stare projekty na tym polegają.

Ceną jest to, że TAP wymaga sterownika, który przedstawia systemowi interfejs Ethernet. Apple wycofał model rozszerzenia jądra, na którym opierały się starsze sterowniki TAP dla Maca, a jego zamiennik API nie pojawia się magicznie w klientach, które nigdy nie zostały zaktualizowane, by go używać. Możliwość platformy i dostarczony produkt to dwie różne rzeczy.

Krok 3: wybierz między zgodnym klientem a migracją

Są dwie uczciwe drogi. Pierwsza to klient, którego wydawca deklaruje dla twojej wersji macOS i sprzętu, że obsługuje potrzebny układ TAP. Nie wpis na forum sprzed czterech lat i nie zarchiwizowany instalator: aktualne oświadczenie plus połączenie testowe.

Druga to przeniesienie usługi na TUN, co jest zmianą serwera tak samo jak klienta. Wymaga trasowanej topologii, puli adresów, wypychanych tras dla sieci zdalnych i drogi powrotnej z tych sieci do puli.

Nie działa zmiana tap na tun w lokalnej kopii i nadzieja. Serwer nadal mostkuje, klient mówi teraz IP, i nic się nie zgadza.

Krok 4: zbierz fakty, zanim zmienisz działającą usługę

Zostaw oryginalny profil nietknięty i zrób kopię do eksperymentów. Plik, który możesz przywrócić w minutę, jest wart więcej niż uporządkowany folder. Gdy zamiennik zadziała, usuń kopię celowo, zamiast zostawiać dwa profile wyglądające w liście identycznie. Ten jeden nawyk zapobiega większości zamieszania po nieudanej migracji. Zapisz obecne zachowanie, aby móc udowodnić, co się zmieniło: czy tunel wstaje, czy dostaje adres, czy docierasz do jednego znanego hosta i czy działa rozwiązywanie nazw.

Zadaj właścicielowi bramy trzy pytania. Czy serwer działa w topologii mostkowanej, czy trasowanej? Które prefiksy zdalne powinny być osiągalne? I czy jest okno serwisowe na zmianę konfiguracji, czy oczekuje się, że zadziała bez dotykania serwera?

Odpowiedzi decydują, czy dziś po południu rozwiązujesz problem klienta, czy w przyszłym tygodniu planujesz zmianę sieci.

Krok 5: zweryfikuj migrację z obu stron

Gdy serwer ma konfigurację trasowaną, a ty masz pasujący profil, testuj w tej kolejności: tunel się zestawia, klient otrzymuje adres z nowej puli, host po stronie zdalnej odpowiada, a nazwa rozwiązuje się przez wypchnięte ustawienie DNS.

Potem sprawdź to, co wcześniej zależało od zachowania Ethernetu. Jeśli aplikacja odkrywała urządzenia przez broadcast, nie znajdzie ich przez trasowany tunel, i żadna konfiguracja klienta tego nie przywróci. Taka aplikacja potrzebuje znanego adresu, lokalnego hosta pomocniczego albo innej metody odkrywania.

Zakończ jednym ponownym połączeniem i jednym restartem, bo profil działający tylko przy pierwszej próbie zwykle oznacza, że wypychane trasy lub ustawienie DNS nie są stosowane przy ponownym łączeniu.

Gdy nadal się nie udaje, przeczytaj pierwszy błąd

Klient, który nie potrafi utworzyć interfejsu, mówi o tym w logu, zwykle w pierwszych linijkach. Klient, który go tworzy, a potem nie przechodzi uwierzytelnienia, dawno minął kwestię urządzenia, a dalsze ściganie TAP marnuje sesję.

Zachowaj oryginalny profil i działającą konfigurację, dopóki zamiennik nie zostanie udowodniony. Wycofanie zmiany klienta jest szybkie; odbudowa mostkowanej sieci, którą ktoś rozebrał na podstawie przeczucia, już nie.