Status VPN w macOS z terminala: scutil, trasy czy ping

Gdzieś w skrypcie wdrożeniowym jest sprawdzenie, czy tunel działa, zanim zacznie się kopiowanie. Dostępne są trzy odpowiedzi i nie znaczą tego samego: stan usługi zgłaszany przez scutil, trasa wybrana przez jądro i to, czy druga strona naprawdę odpowiada. Ich porównanie to różnica między sprawdzeniem, które przewiduje kopiowanie, a takim, które tylko ozdabia log.

Trzy odpowiedzi na pytanie, czy VPN działa

Stan usługi to fakt płaszczyzny sterowania. macOS wie, że konfiguracja jest połączona, bo tak powiedział jej proces klienta. Trasa to fakt płaszczyzny danych: jądro wyśle ten cel przez ten interfejs. Osiągalność to fakt od końca do końca i może zawieść z powodów, których żadna z pozostałych dwóch nie widzi.

Użyteczne sprawdzenie łączy pierwsze dwie i używa trzeciej jako potwierdzenia, że tamte dwie nie kłamały. Każda osobno to zgadywanie ze znacznikiem czasu.

Czytaj identyfikator, nie nazwę wyświetlaną

scutil --nc list
scutil --nc status "Office"

Lista wypisuje jeden wiersz na usługę, a każdy wiersz zawiera stan w nawiasie, potem identyfikator usługi, typ i nazwę wyświetlaną. Skrypt pisz według identyfikatora, bo nazwa wyświetlana to coś, co ktoś wpisał w Ustawieniach systemowych, i może się zmienić bez ostrzeżenia. Polecenie stanu wypisuje jedno słowo, a dla niektórych typów usług statystyki po nim; porównuj to pierwsze słowo zamiast szukać nazwy w całym wyjściu, która pojawia się też gdzie indziej.

Uruchomienie usługi może wywołać prośbę o autoryzację albo zostać wprost odrzucone, gdy profil jest zarządzany. Ta odmowa nie jest usterką tunelu; to oświadczenie polityki o tym, komu wolno go podnieść.

Klient innej firmy ukrywa się przed listą

Pusta lista nie oznacza, że nie ma VPN. Konfiguracje utworzone we własnych ustawieniach sieciowych systemu pojawiają się tutaj; klient dostawcy, profil zarządzania albo aplikacja innej firmy mogą utrzymywać aktywny tunel, którego to polecenie nigdy nie widzi. Własne narzędzie jest autorytetem dla własnej usługi. Pytanie scutil o klienta, który nigdy się w nim nie zarejestrował, zwraca nic, a nic to nie ta sama odpowiedź co rozłączony.

Gdy lista jest pusta, ale ruch jest wyraźnie szyfrowany, szukaj interfejsu: urządzenie utun lub ppp z adresem w oczekiwanym zakresie jest dowodem, że coś ustanowiło tunel. To słabszy sygnał niż stan usługi, więc łącz go ze sprawdzeniem trasy, zamiast traktować interfejs jako dowód tożsamości. Kilku klientów może utworzyć kilka takich interfejsów i tylko jeden z nich należy do tunelu, który miałeś na myśli.

Stan to nie trasowanie

Połączona usługa mówi, że tunel istnieje. Nie mówi, że twoja destynacja go używa. Przeczytaj adresy, a potem zapytaj jądro bezpośrednio:

ifconfig | grep -A4 utun
netstat -rn -f inet
route -n get 10.40.0.20

Klient pełnego tunelu instaluje domyślną trasę przez tunel; klient tunelu dzielonego instaluje konkretne prefiksy prywatne. Oba zgłaszają Connected, a skrypt sprawdzający tylko stan ochoczo pojedzie złą drogą. Zatrzymanie tunelu niekoniecznie usuwa trasy zainstalowane przez innego klienta, i to jeden ze sposobów, w jakie maszyna ma jednocześnie połączoną usługę i nieaktualną trasę. Patrz na destynację, która cię interesuje, nie na całą tabelę tras.

Nazewnictwo to osobny problem

Inne maszyny nie docierają do Maca po nazwie, choć jego adres działa, i jest to zgłaszane jako usterka VPN. Lokalna nazwa hosta, nazwa hosta i rekord DNS to trzy różne rzeczy. scutil --get LocalHostName pokazuje nazwę Bonjour; sudo scutil --set HostName mac-office ustawia nazwę, którą zgłasza system.

Żadne z tych ustawień nie tworzy rekordu w strefie biurowej. Jeśli inne hosty muszą rozwiązać nazwę przez DNS, właściciel strefy musi ją dodać albo skrypt powinien użyć adresu. Ustawienie stabilnej nazwy czyni ogłoszenia spójnymi; nie sprawia, że resolver odpowiada.

Zapisz w skrypcie razem identyfikator usługi i oczekiwany kształt trasy, i sprawdź oba przed kopiowaniem. Tunel, który działa, ale jest trasowany w złą stronę, zawodzi dokładnie tak jak brak tunelu, a wiersz logu mówiący Connected wyśle następną osobę w złe miejsce.