Uruchamianie zapisanego VPN-a Mac z terminala za pomocą scutil --nc

Masz zapisaną usługę VPN w Ustawieniach systemowych i chcesz, aby terminal ją uruchomił. W macOS obsługiwaną ścieżką jest scutil --nc, ale tylko dla usług należących do własnego menedżera połączeń sieciowych systemu. Pasek menu nie jest API: klienci innych firm zwykle mają własną automatyzację, a profil wypchnięty przez usługę zarządzania może odmówić lokalnego uruchomienia. To lista kontrolna, którą wykonuję: znajdź dokładną usługę, odczytaj jej stan, uruchom ją, poczekaj na zmianę stanu, a następnie udowodnij, że ruch naprawdę korzysta z tunelu. Zatrzymaj się na pierwszym kroku, który się nie zgadza, bo każde późniejsze polecenie zakłada, że poprzednie się udało.

Znajdź usługę, zanim spróbujesz ją uruchomić

Zacznij od spisu, a nie od zapamiętanej nazwy profilu:

scutil --nc help
scutil --nc list

Każdy wiersz łączy stan z identyfikatorem usługi, typem i nazwą wyświetlaną. Identyfikator to wartość, przeciw której pisze się skrypty, ponieważ nazwy wyświetlane się powtarzają i można je edytować. Podręcznik scutil Apple’a dokumentuje tryb połączenia sieciowego, a zainstalowane --nc help jest autorytatywną listą podpoleceń na tym Macu; nie zakładaj, że flaga ze starszego przewodnika nadal istnieje w twojej wersji macOS.

Pusta lista to wynik, nie błąd. Usługa utworzona przez klienta dostawcy lub profil zarządzania może być aktywna, choć tutaj niewidoczna, albo widoczna z typem, którym natywny kontroler nie potrafi sterować. W takim przypadku użyj narzędzia dostawcy lub dokumentacji profilu. Tworzenie równoległego natywnego profilu tylko po to, by mieć co uruchomić, to zły interes.

Odczytaj bieżący stan i potwierdź selektor

Zapytaj usługę o stan przed uruchomieniem, aby wiedzieć, co powinno zmienić udane uruchomienie:

scutil --nc status "Office VPN"

Jeśli dwie usługi dzielą nazwę wyświetlaną, nazwa jest niejednoznaczna. Podaj zamiast tego identyfikator; polecenie akceptuje oba, ale tylko identyfikator gwarantuje wybór jednej usługi. Przed analizą w skrypcie sprawdź, czy słowo stanu jest znane — zwykle Connected, Disconnected, Connecting lub Disconnecting. Sprawdź też, czy profil jest zarządzany, bo zablokowana konfiguracja może przyjąć polecenie i mimo to je zignorować lub poprosić o potwierdzenie.

To wywołanie stanu jest tanie, więc używaj go jako strażnika w automatyzacji: uruchamiaj tylko gdy stan to Disconnected, i nie traktuj Connecting jako błędu. Jeśli usługa jest już Connected, pomiń uruchomienie zamiast przerywać działający tunel.

Uruchom połączenie i poczekaj na ustabilizowanie stanu

Żądanie uruchomienia jest asynchroniczne. Polecenie wraca, gdy żądanie zostanie przyjęte, a nie gdy zakończy się uwierzytelnianie lub zostaną zainstalowane trasy. Uruchom je, następnie odpytuj stan z ograniczonym oczekiwaniem i przerwij, jeśli usługa wróci do Disconnected:

scutil --nc start "Office VPN"
n=0
while [ "$n" -lt 30 ]; do
  state=$(scutil --nc status "Office VPN" | head -n 1)
  [ "$state" = "Connected" ] && break
  [ "$state" = "Disconnected" ] && { echo "start failed"; exit 1; }
  sleep 2
  n=$((n + 1))
done

Stan Connecting, który nigdy się nie rozwiązuje, zwykle wskazuje na dane logowania, MFA lub serwer, a nie na scutil. Polecenie nie może zapewnić interaktywnego logowania, więc profil oczekujący tokena lub klucza sprzętowego pozostanie w Connecting i w końcu się wycofa. Przeczytaj słowo stanu, zanim dodasz ponowienia; pętla przeciw monitowi uwierzytelniania nie może się udać.

Nie traktuj kodu wyjścia powłoki jako gotowości. Użytecznym sygnałem jest ciąg stanu, po którym następuje dowód, że tunel przenosi ruch. Polecenie uruchomienia, które wraca cicho, nadal może pozostawić cię z połączeniem, które nigdy się nie uwierzytelnia.

Udowodnij, że tunel przenosi ruch, a nie tylko mówi Connected

Connected opisuje połączenie, a nie decyzję o routingu. Natywne usługi PPP i IKEv2 tworzą interfejs ppp lub utun i instalują trasy, podczas gdy tunel dzielony celowo zostawia trasę domyślną nietkniętą. Sprawdź interfejsy i obie rodziny adresów:

ifconfig -l
netstat -rn -f inet
netstat -rn -f inet6
scutil --dns

Znajdź interfejs utworzony przez usługę, zamiast zgadywać numer, a następnie zapytaj tablicę routingu, którego interfejsu używa konkretny cel: route -n get 10.0.0.10, zastępując go hostem wewnętrznym. Jeśli zgłasza interfejs fizyczny, tunel działa, ale nie przenosi tego przepływu. Sprawdź trasy tunelu dzielonego, kolejność resolverów i każdą lokalną regułę firewalla, która pozwala interfejsowi tunelu, ale nie procesowi.

Rozwiązywanie nazw to zwykły fałszywy negatyw. Nazwy wewnętrzne mogą być rozwiązywane przez zły resolver, gdy tunel jest całkiem zdrowy, co wygląda jak awaria VPN i nią nie jest. scutil --dns pokazuje kolejność, której użyje macOS; po zmianie resolvera wyczyść pamięć podręczną za pomocą dscacheutil -flushcache i sudo killall -HUP mDNSResponder.

Trzymaj dane logowania i uprawnienia poza wierszem poleceń

Nigdy nie umieszczaj hasła, wstępnie współdzielonego klucza ani tokena w argumentach. Argumenty są widoczne na listach procesów i trafiają do historii powłoki, a skopiowany zapis wsparcia może je ujawnić. Obsługa danych logowania przez sam profil — czy to element Keychain, monit systemowy, czy przepływ uwierzytelniania klienta — jest miejscem na sekrety.

Uruchamianie polecenia z sudo nie czyni interaktywnego logowania bezobsługowym. Zmienia efektywnego użytkownika, a nie dostępność monitu GUI, tokena sprzętowego czy keychaina logowania. LaunchAgent może uruchomić usługę po zalogowaniu użytkownika i odblokowaniu keychaina; LaunchDaemon zwykle nie dociera do tych części sesji użytkownika. Jeśli organizacja zarządza usługą, jej reguły cyklu życia wygrywają z każdym lokalnym skryptem.

Zatrzymaj usługę i sprawdź, że pozostała zatrzymana

Zatrzymaj tym samym selektorem, którego użyłeś do uruchomienia, a następnie odczytaj stan ponownie, zamiast zakładać, że tunel zniknął:

scutil --nc stop "Office VPN"
scutil --nc status "Office VPN"

Zatrzymanie, które wraca do Disconnected, nadal zostawia jedną rzecz do sprawdzenia: czy profil jest ustawiony na łączenie na żądanie, co może go przywrócić bez twojego skryptu. Jeśli inny klient ma trasy na tym samym Macu, te trasy mogą przetrwać natywne zatrzymanie. Ponownie sprawdź trasę, zanim uznasz, że maszyna jest poza VPN.

Dla opakowania uruchamianego ręcznie utrzymuj stałą kolejność: lista, stan, uruchomienie, odpytywanie, test trasy, zatrzymanie, weryfikacja. Nie analizuj przyjaznej nazwy z wolnego wyjścia, gdy identyfikator jest dostępny, i nie traktuj wyjścia polecenia uruchomienia jako gotowości. Menedżer połączeń raportuje stan; twoim dowodem jest stan plus trasa wskazująca na tunel.