Które narzędzie macOS może zmusić jedną aplikację do ruchu wyłącznie przez VPN?

Jedna linijka w dokumencie wymagań — „ta aplikacja może korzystać z VPN i niczego więcej” — po cichu prosi o dwa mechanizmy, których nie zapewnia żaden pojedynczy przełącznik. Ruch potrzebuje ścieżki przez zamierzony tunel, a ruch, który wyszedłby bezpośrednio, musi zostać odrzucony. Narzędzia, które jedno z nich robią dobrze, a drugie wcale, są częste, dlatego porównanie pytające tylko, czy coś potrafi blokować, pewnie odpowiada na połowę pytania. Najpierw zapisz granicę, potem wybierz komponenty, które pokrywają obie jej połowy.

Dwa wymagania ukryte w jednym zdaniu

Kierowanie to część, która umieszcza połączenie w tunelu lub proxy. Odmowa to część, która nie pozwala temu samemu połączeniu wyjść inną drogą. Implementują je różne komponenty, zawodzą na różne sposoby, a produkt może być znakomity w jednym, nie mówiąc nic o drugim:

Czytaj tabelę jako listę kontrolną, nie jako ranking. Żaden wiersz nie wypełnia obu środkowych kolumn, a wiersze, które je pokrywają, to dwa współpracujące komponenty: jeden posiada ścieżkę, drugi odmowę. Kolumna tożsamości ma znaczenie z innego powodu, bo reguła, która nie potrafi nazwać aplikacji, nie może wyegzekwować reguły o tej aplikacji. Cokolwiek wdrożysz, musi odpowiedzieć na wszystkie trzy, inaczej granica w dokumencie wymagań nie jest granicą na maszynie.

Samo kierowanie zostawia wyjście

Ustawienie proxy aplikacji to najjaśniejszy przykład kierowania bez odmowy. Może kierować żądania aplikacji, która respektuje proxy systemowe, i nie obejmuje niczego innego: proces pomocniczy, aktualizator, usługa w tle lub inny protokół mogą pójść własną drogą, nigdy nie czytając tego ustawienia. Wybór punktu końcowego SOCKS w jednym panelu nie tworzy więc polityki zakazu bezpośredniego wyjścia dla aplikacji. Jeśli wymaganie dotyczy aplikacji jako całości, zapytaj, które komponenty reguła rzeczywiście identyfikuje.

Profil VPN dla aplikacji kieruje lepiej niż proxy, bo to platforma decyduje, które aplikacje wchodzą do tunelu zamiast każdej aplikacji decydować samodzielnie. Mimo to niczego nie odmawia: profil daje ścieżkę, a ruch, który do niej nie pasuje, idzie zwykłą trasą. Właśnie ta luka jest miejscem, w którym drugi komponent zasługuje na swoje miejsce, i dlatego produkty wyglądające jak jeden przełącznik są zwykle dwa.

Sama odmowa psuje aplikację

Dokumentacja Apple o filtrach treści opisuje wyrok pozwól-albo-zablokuj dotyczący ruchu, gdy przechodzi przez stos sieciowy. Ten wyrok nie jest tunelem ani połączeniem proxy, bo decyduje, czy coś może trwać dalej, a nie dokąd zmierza. Sam filtr doskonale egzekwuje odmowę i zostawia aplikację bezużyteczną, z czystymi dziennikami i bez wyjaśnienia. Wyrok filtra może zatrzymać połączenie, ale nigdy nie dostarcza tunelu, więc łączenie go z kierowaniem jest decyzją projektową, a nie opcjonalnym dodatkiem.

Lokalnie zarządzany zestaw reguł PF stoi na drugim końcu tego spektrum. To uzasadniona decyzja wsparcia na maszynie, którą posiada administrator, i nie jest automatycznie podstawą produktu do dystrybucji, bo kto posiada zestaw reguł, posiada też jego interakcje z innymi użytkownikami zapory, ścieżkę aktualizacji i odzyskiwanie, gdy reguła jest błędna. Dodanie PF do produktu nie usuwa tego pytania o własność; ono je definiuje.

Wdrożenie decyduje, czy reguła będzie istnieć także jutro

To, jak Network Extension jest wdrażany na platformach Apple, zależy od typu dostawcy, pakowania i wersji systemu operacyjnego przed tobą. Rozszerzenie aplikacji w macOS działa w kontekście użytkownika i kończy się, gdy ten użytkownik się wyloguje, natomiast rozszerzenie systemowe ma kontekst globalny, niezależny od sesji. Jeśli ochrona musi przetrwać wylogowanie, ta różnica jest całym projektem, a nie przypisem. Potwierdź ścieżkę wdrożenia, zanim obiecasz zachowanie, bo ten sam kod ląduje inaczej w zależności od dostarczanego typu rozszerzenia.

Dostępność kodu źródłowego to odrębna kwestia od egzekwowania. Czytanie repozytorium mówi, jak coś zaimplementowano, a nie co zainstalowany plik binarny może robić na tej maszynie. Podpisywanie, instalacja i autoryzacja nadal obowiązują, a instrukcje zbudowane wokół przestarzałego rozszerzenia jądra lub sztuczki z wstrzykiwaniem biblioteki opisują inną platformę i inne podejście do ryzyka, jakkolwiek dobrze kiedyś działały.

Przypadek akceptacyjny, który nazywa aplikację

Wybierz jedną czynność, którą aplikacja wykonuje sama, zanotuj adres, do którego powinna dotrzeć, i czy jest to IPv4 czy IPv6, a następnie powtórz tę samą czynność w zatwierdzonym stanie bez tunelu. Drugie uruchomienie musi dać zadeklarowaną odmowę, a nie cichą bezpośrednią ponowną próbę. To jest ta połowa, którą ludzie zostawiają niesprecyzowaną, i jedyna połowa, która dowodzi, że odmowa w ogóle istnieje. Uruchom to najpierw przy dostępnym tunelu, aby różnica między dwoma wynikami mogła pochodzić tylko z brakującego tunelu.

Potem przejdź przez przejścia, które nazywa wymaganie: ponowne uruchomienie aplikacji, uruchomienie procesu pomocniczego, ponowne połączenie tunelu, zmianę sieci przez maszynę oraz wylogowanie lub restart, gdy mają zastosowanie. Strona publicznego IP w przeglądarce nie jest testem gniazd innej aplikacji, więc nie może tego zastąpić. Tam, gdzie żadne wspierane wdrożenie nie obejmuje rzeczywistego zachowania aplikacji, autoryzowane odizolowane środowisko z jawną bramą i bez alternatywnego wyjścia jest decyzją o ograniczeniu z własnym kosztem zarządzania, a nie zamiennikiem pola wyboru.

Zakończ, zapisując cztery pozycje: z jakich komponentów składa się aplikacja, kto posiada kierowanie, kto posiada odmowę i stany, w których reguła musi nadal obowiązywać. Publiczne repozytorium może być jednym kryterium wyboru, ale nie jest jedną z czterech, i to te pozycje rozstrzygają, czy dane narzędzie spełnia wymaganie sieciowe.