Netgear OpenVPN: TUN i TAP nasłuchują na różnych portach

Telefon łączy się z VPN routera bez skargi, a laptop używający profilu z tej samej strony pobierania kończy się przekroczeniem czasu. Nic w certyfikatach nie zmieniło się między tymi dwiema próbami, ponieważ laptop nigdy nie dotarł do punktu, w którym certyfikaty mają znaczenie. Router publikuje osobne nasłuchy dla TUN i TAP, a działający profil musi wybrać ten, który należy do jego własnego typu urządzenia.

Ustalenie, której z trzech możliwych usterek się trzymać, to tutaj cała praca: portu, typu urządzenia czy negocjacji szyfru kanału danych.

Trzy rzeczy, które muszą się zgadzać

Typ urządzenia, linia interfejsu profilu i port nasłuchu tworzą jeden wybór, nie trzy. Profil deklarujący dev tun i celujący w nasłuch TAP nie może ukończyć sesji, a odwrotnie zawodzi tak samo. Dla swojego modelu i firmware czytaj port z własnej strony VPN routera, a nie z poradnika, ponieważ numery zmieniają się między wersjami. Zapisz model i wersję firmware obok tego numeru, aby następna osoba mogła to zweryfikować.

Raporty z terenu wspominają parę, na przykład 12973 dla TUN i 12974 dla TAP na jednym firmware, a inny numer na innym. Czytaj je jako dowód, że wersje się różnią, a nie jako stałe do skopiowania. Profil potrzebuje wtedy nazwy hosta odpowiedniej do odległości: dynamicznej nazwy DNS routera, a nie adresu WAN, który się zmieni.

Po poprawieniu portu i linii interfejsu profil wygląda jak zwykła konfiguracja klienta z jedną linią remote i jedną linią dev. Jeśli te dwie się nie zgadzają, żadna liczba powtórzeń nie daje sesji.

Czytaj dziennik w kolejności, w jakiej jest wypisywany

Klient OpenVPN zgłasza zdarzenia w kolejności, w jakiej następują, więc ostatnia linia przed ciszą wskazuje warstwę do sprawdzenia. Gdy przebieg kończy się na TLS Error: TLS key negotiation failed lub po prostu czeka na pierwszą odpowiedź i poddaje się, porównanie certyfikatów nigdy nie nastąpiło. Wskazuje to na osiągalność, na nasłuch albo na port, za którym nic nie ma. Żadnego z nich nie naprawia wymiana pliku CA.

Przebieg, który dociera do VERIFY OK i potem zawodzi, znajduje się zupełnie gdzie indziej, z własnymi przyczynami. Rozdzielenie tych dwóch wyników przed dotknięciem plików zapobiega klasycznej okrężnej drodze przez pakiety certyfikatów, o które nigdy nie pytano. Gdy uzgadnianie jest zakończone, ale tunel nie wstaje, patrz na negocjację szyfru, a nie na osiągalność.

Dodaj listę szyfrów, której oczekuje nowoczesny klient

Nowsze klienty OpenVPN odrzucają starsze wartości domyślne, które firmware konsumencki nadal oferuje, a objawem jest niepowodzenie negocjacji zaraz po udanym uzgodnieniu. Poprawka to jedna linia profilu nazywająca to, co klient przyjmie: ustaw data-ciphers na AES-256-GCM, AES-128-GCM, CHACHA20-POLY1305 i AES-128-CBC w tej kolejności. Każdy algorytm, którego router nie implementuje, po prostu nigdy nie jest wybierany, więc dłuższa lista kosztuje tylko nieco dłuższą negocjację.

Wymienianie szyfrów nie uczy routera tego, czego nie ma. Jeśli negocjacja nadal zawodzi, sprawdź, czy strona routera ma własne ustawienie szyfru i czy to ustawienie zawiera co najmniej jeden wpis, który klient akceptuje. Dwie listy bez wspólnego elementu dają dokładnie takie samo niepowodzenie jak zły port, dlatego oba końce zasługują na spojrzenie.

Zaimportuj raz zamiast ręcznie edytować kopie

Import poprawionego pliku do NetworkManager pozwala uniknąć folderu pełnego nieco różnych profili: nmcli connection import type openvpn file client.ovpn, a potem podnieś go po nazwie. Trzymaj zaimportowany profil jako jedyną kopię, którą edytujesz, i usuwaj duplikaty gromadzące się przy powtarzanych pobraniach.

Następnie przetestuj spoza LAN. Łączenie z tej samej sieci dowodzi bardzo niewiele, ponieważ ruch może w ogóle nie przechodzić przez tunel. Potwierdź, że żądanie naprawdę wychodzi przez router, a nie tylko że klient pokazuje stan połączenia.

Zdecyduj, co zrobić z ostrzeżeniami

Firmware konsumencki zwykle tworzy własny urząd certyfikacji, a klienty skarżą się na weryfikację w sposób, którego firmware nie potrafi stłumić. Oceń, czy ta skarga ma znaczenie dla tego, co chronisz, zamiast traktować każde ostrzeżenie jako krytyczne, i nie wyłączaj weryfikacji globalnie, aby uciszyć jedną wiadomość. Ostrzeżenie, które oceniłeś, jest udokumentowanym ryzykiem; wyłączone ustawienie weryfikacji jest nieudokumentowane.

Gdy firmware nie oferuje żadnego wspieranego sposobu naprawienia ostrzeżenia, które naprawdę ma znaczenie, ta luka przemawia za hostowaniem VPN gdzie indziej. Wybór między naprawą profilu, akceptacją ostrzeżenia i przeniesieniem punktu końcowego to decyzja o tym, jak bardzo ufasz temu certyfikatowi. Podejmij ją świadomie i zapisz, którą opcję wybrałeś, zamiast klikać okna dialogowe, aż ikona stanie się zielona.