Kolejność usług w macOS nie kontroluje tras VPN

Coś w witrynie zawodzi, kolega przypomina sobie, że istnieje kolejność usług, a Wi-Fi zostaje przeciągnięty ponad Ethernet. Nic się nie zmienia, bo ta lista nigdy nie decydowała, dokąd trafia cel VPN. Apple daje połączeniom VPN pierwszeństwo przed zwykłymi i trzyma je poza tym przestawianiem, więc przełącznik odpowiada na węższe pytanie niż zadane. Awaria wymaga wybranej trasy i resolvera, a nie nowego rankingu.

Co zmienia kolejność usług, a czego nigdy nie dotyka

„Ustaw kolejność usług” znajduje się w Ustawieniach systemowych, Sieć, w menu Działanie, i szereguje zwykłe połączenia, gdy aktywne są dwa lub więcej. Ten szereg wybiera usługę główną, która dostarcza trasę domyślną i część zachowania resolvera. To rozstrzygnięcie między równymi, nie przełącznik dla prywatnych celów za tunelem. Laptop z Wi-Fi i adapterem Ethernet USB używa go, by odpowiedzieć na rozsądne pytanie, a to pytanie nie dotyczy tunelu.

Profil VPN niesie uwzględnione trasy, wykluczone cele i czasem reguły dla aplikacji, i to one decydują, co wchodzi do tunelu; menu kolejności ich nie edytuje. Dlatego profil z dzielonym tunelem może zostawić ruch publiczny na zewnątrz, podczas gdy VPN nadal przewyższa każdy interfejs fizyczny. Przeciągnięcie Wi-Fi na górę nie czyni prywatnego zakresu osiągalnym i nie zatrzyma celu, który profil już uwzględnia. Lista przesuwa interfejsy; profil przesuwa prefiksy. Apple dokumentuje pierwszeństwo na swojej stronie kolejności usług sieciowych, którą warto raz przeczytać, zanim cokolwiek przestawisz.

Przeczytaj trasę, którą maszyna faktycznie wybrała

Zapytaj maszynę, dokąd prowadzi konkretny adres, poleceniem route get 10.20.4.10, a następnie powtórz to dla IPv6 poleceniem route -n get -inet6 2001:db8::10. Obie rodziny to osobne decyzje, więc działająca trasa IPv4 nic nie mówi o v6, a bezpośrednio podłączona podsieć lub bardziej szczegółowy prefiks i tak bije ogólną etykietę połączenia, i właśnie dlatego etykieta wciąż wprowadza ludzi w błąd.

Jeśli dane wyjściowe wymieniają interfejs tunelu, profil przechwycił cel, a kolejność nie ma znaczenia. Jeśli wymieniają interfejs fizyczny, profil tego nie zrobił, i żadne przeciąganie nie zmieni tabeli prefiksów. Oba wyniki wymieniają też adres źródłowy, którego użyłaby maszyna, i to jest pole, które warto zacytować przy porównywaniu dwóch uruchomień. Zapisz wynik, zanim cokolwiek zmienisz, bo to jedyny dowód, jaki potem będziesz mieć.

DNS rozwiązuje według nazwy, nie interfejsu

Resolvery z zakresem i specyficzne dla domeny oznaczają, że odpowiedź może się różnić według nazwy, a nie według interfejsu. scutil --dns wypisuje konfigurację resolvera, której system faktycznie używa, wraz z wpisami z zakresem. Kolejność usług wpływa na to, która usługa dostarcza resolver domyślny, ale zakres specyficzny dla nazwy i tak może wygrać.

Dlatego ping do adresu może działać, gdy nazwa hosta zawodzi, lub odwrotnie. Przeczytaj oba wyniki, zanim wybierzesz winnego.

Zmień profil, a potem przeczytaj ponownie oba wyniki

Gdy polityka celu wymaga zmiany, właścicielem jest profil VPN: uwzględnione trasy, wykluczone trasy i wszelkie reguły dzielonego tunelu, które obsługuje dostawca. Zmiana interfejsów tylko przenosi spór. Na Macu zarządzanym zdalnie najpierw zapisz bieżący stan sieci, bo utrata tunelu na maszynie, do której nie możesz dotrzeć, to podróż, a nie wycofanie.

Odtwórz awarię, przeczytaj trasę, przeczytaj resolver, zmień jedną rzecz, a potem ponownie przeczytaj te same dwa wyniki. Mieszanie kilku usług i profili naraz zostawia maszynę, której nikt nie potrafi wyjaśnić, łącznie z osobą, która ją naprawiła. Test kończy się, gdy oba wyniki zgadzają się z zamierzoną zmianą. Jeśli nadal się różnią, profil i maszyna opisują dwie różne polityki, a zmienić trzeba profil.