Zaimportowane trasy VPN różnią się od działającego klienta? Porównaj oba

Jakaś usługa prywatna odpowiada przez VPN, a zwykły ruch internetowy zachowuje się zupełnie inaczej niż na komputerze kolegi, i aż kusi, by uznać, że klient Ubuntu jest zepsuty. Ten wniosek pomija jeden krok. Działająca operacja prywatna i odmienna ścieżka publiczna to dwie obserwacje, a różnica zwykle tkwi w polityce ruchu zainstalowanej przez każdego klienta, a nie w samym kliencie.

Porównanie zapisanej konfiguracji z rzeczywistym stanem sieci to trzy polecenia, które odpowiadają na pytanie, które próbowały rozstrzygnąć domysły.

Najpierw zapisany profil, potem stan rzeczywisty

Zaimportowane połączenie OpenVPN staje się osobnym profilem NetworkManager. Plik .ovpn, z którego pochodzi, przestaje być źródłem prawdy w chwili zakończenia importu, więc późniejsza edycja tego pliku niczego nie zmienia w używanym połączeniu. To pierwsze miejsce, w którym porównanie idzie źle, i idzie źle po cichu.

nmcli -f connection.id,connection.uuid,ipv4.never-default,ipv4.routes,ipv4.dns connection show office-vpn

Czytaj UUID, gdy nazwy się zderzają; zduplikowane nazwy przetrwają reinstalacje i przywracanie profili, a godzinę można spędzić na edycji kopii, która nie jest używana. Widoczne wartości opisują zapisaną intencję: czy profil może przejąć trasę domyślną, jakie trasy zapisano oraz jakich resolverów i domen wyszukiwania żąda. Nie opisują tego, co stało się przy aktywacji połączenia, ponieważ wtyczka lub push z serwera mogą dodać stan, którego profil nie wymienia. Dlatego następne polecenie ma znaczenie.

Potem sprawdź, co system faktycznie zrobił z tą intencją, w tym reguły polityki i każdą tabelę, a nie tylko główną. Zapisane właściwości są danymi wejściowymi, a zainstalowane tabele są wynikiem.

ip -4 rule show
ip -4 route show table all

Dwa cele, jedno porównanie

Wybierz jeden działający cel prywatny i jeden zwykły cel publiczny, a następnie zapytaj jądro, którą ścieżką pójdzie każdy z nich. Wykonanie tego na obu maszynach zamienia mglistą różnicę w konkretną.

ip -4 route get 10.40.0.20
ip -4 route get 203.0.113.20

Adresy są przykładami do zastąpienia własnymi; liczy się para, a nie liczby. Porównaj interfejs, adres źródłowy i tabelę wskazaną w każdym wyniku. Gdy wyszukiwanie prywatne wskazuje tunel i wyszukiwanie publiczne również wskazuje tunel, masz pełny tunel, a drugi klient może mieć dzielony, albo odwrotnie.

Nie wymagaj, aby oba programy klienckie drukowały identyczny tekst. redirect-gateway def1 w OpenVPN jest zwykle wyrażany jako dwie trasy połowicznego prefiksu zamiast jednej domyślnej, a menedżer, który pokazuje je inaczej, nie jest przez to błędny. Oceń pokrycie, które pokazują wyszukiwania, a nie formatowanie.

Gdzie oba klienty mogą się legalnie różnić

Domyślne ustawienia klientów to wybory polityki i mogą się nie zgadzać. Jeden produkt może preferować pełny tunel, inny zachować lokalną domyślną trasę i kierować tylko prefiksy prywatne, a trzeci podążać za tym, co wypchnął serwer. Różnica jest wadą tylko wtedy, gdy przeczy wymaganiu, które otrzymałeś.

Porównuj więc każdego klienta z zatwierdzoną intencją tunelu dzielonego lub pełnego, a nie klientów ze sobą. Jeśli wymaganie mówi, że ruch prywatny ma iść tunelem, a lokalna ścieżka internetowa ma pozostać lokalna, to pełny tunel jest błędem, a tunel dzielony jest poprawny, niezależnie od tego, który klient co zrobił. Zapisz intencję, zanim spojrzysz na którąkolwiek konfigurację, inaczej pierwszy sprawdzony klient po cichu stanie się standardem.

DNS to druga oś i zawodzi niezależnie. Poprawna trasa nadal może wysyłać zapytania do resolvera, który nie potrafi odpowiedzieć za strefę prywatną, a poprawny resolver nie naprawi błędnej trasy. Sprawdź jedno i drugie, a nazwę prywatną, która się rozwiązuje, podczas gdy adres prywatny nie, traktuj jako dowód, że obie warstwy są rozwiązywane osobno.

Utrzymaj porównanie w czystości

Uruchamiaj jednego właściciela połączenia naraz. Sesja OpenVPN z wiersza poleceń działająca obok zaimportowanego profilu instaluje własne trasy i własny stan resolvera, a powstała mieszanka nie jest zachowaniem żadnego z klientów. Zdemontuj jeden, zanim zmierzysz drugi. Uruchom ponownie komputer, jeśli nie wiesz, co jeszcze trzyma stan, bo nieaktualna trasa sprzed godziny wygląda dokładnie jak problem z polityką.

Utrzymaj też wszystko inne bez zmian: ten sam endpoint, to samo konto, te same wersje oprogramowania, ta sama sieć. Sukces na laptopie kolegi z Windows testuje innego klienta, inną integrację resolvera i być może inny profil serwera, więc nie jest dowodem w sprawie menedżera Ubuntu.

Dokumentacja ustawień IPv4 NetworkManagera precyzyjnie definiuje never-default i właściwości zapisanych tras, co warto przeczytać przed zmianą zarządzanej wartości. I pamiętaj o zakresie tego porównania: dotyczy IPv4 i nic nie mówi o odpowiedniej polityce IPv6, która ma własne wartości domyślne i własny sposób zaskakiwania.