Blokada VPN PF na Macu: polityka witryny, a nie funkcja do dostarczenia

To działa na twoim Macu, więc wygląda jak coś, co można przekazać użytkownikom. To założenie trzeba porzucić jako pierwsze. Apple w dokumencie TN3165 jasno stwierdza, że Packet Filter nie jest obsługiwanym API dla produktów powszechnie dystrybuowanych, i uznaje uprzywilejowaną, kontrolowaną administrację witryny za uzasadniony przypadek. Blokada VPN oparta na PF jest więc lokalną polityką operacyjną z właścicielem, a nie funkcją, którą można dostarczyć w aplikacji.

PF nie jest powierzchnią pakowania

Ta różnica nie jest akademicka. Dystrybuowany produkt zależny od PF dziedziczy każdą zmianę, którą Apple w nim wprowadza, każdy konflikt z innym narzędziem, które też pisze reguły, i żadnego zobowiązania wsparcia, że ten układ będzie działał. Witryna administrująca własnymi maszynami ma inną relację: może udokumentować zależność, przetestować ją z każdym wydaniem systemu i zaakceptować utrzymanie.

Niektóre rady dotyczące instalacji przekraczają granicę, którą warto nazwać. Nadpisanie całego systemowego zestawu reguł, aby załadować jedną kotwicę, edycja systemowej konfiguracji uruchamiania Apple lub wyłączenie System Integrity Protection nie są akceptowalnymi wymaganiami dla wielokrotnego użytku receptury. Jeśli opublikowany przewodnik wymaga któregokolwiek z nich, opisuje laboratorium, a nie politykę do wdrożenia.

Zapisz intencję ruchu wychodzącego przed składnią

Zdecyduj, co jest dozwolone, zanim wybierzesz jedno słowo kluczowe. Zwykle muszą istnieć trzy ścieżki: własny transport klienta VPN do jego serwera, chroniony ruch aplikacji wewnątrz tunelu oraz wszystko, co konfiguracja lub lokalne usługi naprawdę wymagają bezpośredniej ścieżki.

Każdemu proponowanemu wyjątkowi przypisz cel, transport i właściciela. Zezwolenie na każdy port do jednego punktu końcowego pozwala na znacznie więcej niż jeden transport używany przez tunel, a dodatkowa ekspozycja pojawia się bez czyjejkolwiek decyzji, że tak ma być. Zezwolenie na publiczny resolver to ta sama pułapka w przyjaźniejszym przebraniu: tworzy bezpośrednią ścieżkę DNS nawet przy wyłączonym tunelu, więc wyszukiwanie nazw nadal wycieka.

Użytecznym testem wyjątku jest to, czy potrafisz wskazać osobę, która o niego poprosiła, oraz awarię, której on zapobiega. Jeśli nie ma żadnej odpowiedzi, reguła jest prawdopodobnie obejściem błędnej konfiguracji, która inaczej pozostałaby niewidoczna.

Numery utun nie są tożsamością

MacOS tworzy interfejsy tunelu jako urządzenia utun, a numer przypisany twojemu VPN nie jest stabilny między restartami, ponownymi połączeniami czy obecnością innego klienta. Reguła wymieniająca kilka zgadywanych numerów nie jest polityką; to migawka jednego popołudnia.

Zakotwicz regułę w czymś, co identyfikuje zamierzonego dostawcę: plan adresów przydzielany przez tunel, proces będący właścicielem interfejsu lub konfiguracja utrzymywana przez samego klienta VPN. Następnie zapisz, jak działa ta identyfikacja, ponieważ osoba przeglądająca regułę za rok nie będzie miała twojej historii powłoki.

Uczyń załadowaną politykę przypisywalną

Nazwa kotwicy porządkuje reguły; nie dowodzi, że skuteczna polityka jest tą, którą zamierzałeś. Priorytet między kotwicami, reguły załadowane przez inne oprogramowanie i istniejący stan mogą zmienić wynik. Przejrzyj skuteczny zestaw z wszystkimi innymi właścicielami PF na tej maszynie i udokumentuj własność w tym samym miejscu co konfigurację. Dwóch właścicieli edytujących różne kotwice z różnymi założeniami to zwykły sposób, w jaki blokada zyskuje dziurę.

Trzymaj zestaw reguł w obsługiwanej ścieżce konfiguracji witryny, wersjonuj go i notuj, które wydania macOS przetestowano. Zmiana stosowana ręcznie i pamiętana przez jedną osobę nie jest utrzymywaną infrastrukturą, cokolwiek mówi nagłówek pliku.

Testuj przejścia, a nie stan połączenia

Zrzut ekranu zrobiony przy aktywnym tunelu nie dowodzi prawie niczego. Przejdź przez stany: uruchomienie przed jakimkolwiek połączeniem, działający tunel, tunel, który pada bez ostrzeżenia, celowe rozłączenie i przejście z Wi-Fi na hotspot. Każdy stan ma swoją odpowiedź, a ciekawe są awarie, nie szczęśliwa ścieżka.

W każdym stanie zapisz, co jest celowo osiągalne. Sprawdź IPv4 i IPv6 osobno, przetestuj rozwiązywanie nazw i uwzględnij przepływ, który został ustanowiony przed przejściem, ponieważ istniejące połączenia nie zawsze stosują się do nowej polityki. Przeglądarka, która zawodzi przy wyłączonym tunelu, to jeden punkt danych, a nie dowód, że każda inna ścieżka jest zablokowana.

Na koniec utrzymuj metodę odzyskiwania, która nie zależy od ścieżki sieciowej, którą zmieniasz. Znana dobra konfiguracja w pamięci lokalnej i udokumentowany sposób jej załadowania zamieniają blokadę w politykę; bez nich jedna zła wersja zamyka administratora poza maszyną, która miała być chroniona.