Ustawienia VPN na Macu nie uruchamiają serwera: gdzie mieszka brama

Dwa różne zadania noszą nazwę VPN w macOS, a panel ustawień obsługuje tylko jedno z nich. Jeśli chcesz, aby ruch tego Maca wychodził przez dostawcę lub zdalną bramę, wystarczy wpis klienta. Jeśli chcesz z pokoju hotelowego dotrzeć do drukarki, NAS-a lub strony administracyjnej w domowej sieci, coś w tej sieci musi przyjmować połączenia z zewnątrz, a obecny Mac nie jest tym czymś od razu. Trzy pytania rozstrzygają, w którym przypadku jesteś, i warto na nie odpowiedzieć, zanim wpiszesz adres w pole.

Wpis klienta nazywa cel, a nie nasłuch

W Ustawieniach systemowych > Sieć > VPN w macOS Ventura i nowszych pola, które starsze wydania trzymają w Preferencjach sieci, opisują, jak dotrzeć do cudzego punktu końcowego: adres serwera, zdalny ID, konto lub certyfikat oraz opcjonalne reguły łączenia na żądanie. Zapisanie tego wpisu przechowuje połączenie w konfiguracji sieci Twojego Maca. Nic w tym procesie nie wiąże portu, nie otwiera nasłuchu ani nie rejestruje zdalnego użytkownika.

Możesz to sprawdzić z powłoki. Na Macu, który podejrzewasz o serwowanie, uruchom sudo lsof -nP -iUDP i poszukaj portów używanych przez Twój protokół: 500 i 4500 dla IKEv2, 1194 dla domyślnego OpenVPN, 51820 dla WireGuard. Maszyna będąca tylko klientem pokazuje gniazda powiązane ze zdalnym adresem i portem, a nie dowiązanie wieloznaczne, do którego dotarłoby cokolwiek w internecie. Tunele działające w Network Extension mogą ukryć się przed lsof, więc i tak sprawdź panel stanu aplikacji; czego nie znajdziesz, to ustawienia Apple, które zamieniają tego Maca w bramę.

Trzy pytania rozdzielają dwie role

Przejdź przez nie po kolei. Pierwsze zwykle rozstrzyga resztę, a trzecie to miejsce, w którym najbardziej myli się planowanie specyficzne dla Maca.

1. Kto zaczyna rozmowę? Jeśli Twój Mac dzwoni na zewnątrz i druga strona odpowiada, potrzebujesz klienta. Jeśli urządzenia w internecie muszą dzwonić do środka, by dotrzeć do Twojej sieci, potrzebujesz bramy z publicznym punktem wejścia, a Mac może pozostać klientem tej bramy.

2. Co musi być osiągalne, gdy tunel jest podniesiony? Jedna usługa na jednym hoście to decyzja o przekierowaniu portów. Cała podsieć, wraz z rozwiązywaniem nazw, to decyzja o routingu i DNS, i zmienia to, co brama musi przekazywać, a nie to, co mówi wpis klienta.

3. Które wydanie systemu uruchamia stronę przyjmującą? Dla Maców to pytanie ma twardą odpowiedź. Apple wymienia VPN jako usunięte z macOS Server 5.7.1, a sama aplikacja macOS Server została wycofana 21 kwietnia 2022; komunikat o historii usługi to strona, którą trzeba przeczytać, gdy stary poradnik prowadzi Cię przez pole wyboru usługi VPN, której już nie ma.

Gdy pierwszą odpowiedzią jest „ktoś z zewnątrz zaczyna”, przestań szukać przełącznika w panelu klienta Maca i wybierz host, który zakończy tunel.

Gdzie brama może mieszkać zamiast tego

Cztery układy pokrywają większość przypadków domowych i małego biura. Router z prawdziwym trybem serwera, a nie trybem klienta z inną etykietą, kończy tunel na brzegu i utrzymuje małą liczbę hostów, kosztem związania z obsługą protokołów tego firmware. NAS lub stale włączony mini PC uruchamia pakiet serwera producenta i zostawia czytelne logi. Mała maszyna w chmurze daje publiczny adres, który kontrolujesz, i dociera do domu drugim tunelem. Nakładka mesh zbudowana na WireGuard albo zarządzana usługa przekazująca między partnerami omija przychodzące przekierowanie portów, każąc obu końcom dzwonić na zewnątrz.

Granicą między tymi opcjami jest zwykle Twoje łącze internetowe, a nie oprogramowanie. Jeśli dostawca umieści Cię za NAT-em klasy operatorskiej, żadna ilość przekierowań portów na routerze nie da osiągalnego punktu wejścia, a uczciwą odpowiedzią jest układ z przekaźnikiem lub mesh. Porównaj adres WAN raportowany przez router z adresem widzianym przez świat zewnętrzny; jeśli się różnią, a wartość routera leży w zakresie prywatnym lub współdzielonym, planuj przypadek przekaźnika.

Niezależnie od wybranego hosta przekazuj jeden protokół na jednym porcie, a nie zakres, i trzymaj Maca poza ścieżką przychodzącą, chyba że ten konkretny produkt dokumentuje rolę serwera dla wydania macOS, które uruchamiasz.

Potwierdź rolę, zanim rozdostępnisz profile

Na kandydacie na bramę udowodnij, że nasłuch istnieje, zamiast wierzyć, że instalator go utworzył. W macOS oznacza to sudo lsof -nP -iUDP filtrowany do portów powyżej, plus sudo pfctl -s nat, jeśli reguły filtra pakietów są częścią projektu. W Linuxie ss -lunp pokazuje te same fakty bez dwuznaczności.

Potem przetestuj spoza sieci, używając samego protokołu. Ping dowodzi niewiele: ICMP bywa filtrowany i nic nie mówi o UDP 51820. Uścisk dłoni klienta ze szczegółowym logowaniem, uruchomiony z telefonu na danych komórkowych, to najtańszy prawdziwy test, bo przechodzi tą samą drogą co zdalny współpracownik.

Dopiero potem dotykasz profili klientów. Na Macu scutil --nc list wypisuje usługi VPN znane systemowi; jeśli zbudowanej właśnie bramy nie ma wśród nich, konfigurujesz inną maszynę niż testowana. Jeśli uścisk dłoni udaje się w sieci LAN, ale zawodzi z zewnątrz, błąd jest w ścieżce przychodzącej: reguła NAT, CGNAT dostawcy albo firewall na bramie, w tej kolejności.

Zanim cokolwiek zbudujesz, rozstrzygnij cztery punkty:

• Która strona inicjuje połączenie, Twój Mac czy urządzenie zdalne.
• Czy wydanie systemu i produkt hosta przyjmującego naprawdę wspierają rolę serwera.
• Czy Twój dostawca w ogóle daje osiągalny publiczny adres.
• Który pojedynczy port i protokół przyjmie brama, i która usługa za nią odpowiada.

Następny krok jest konkretny: wybierz host bramy, potwierdź jej nasłuch z zewnątrz i dopiero wtedy utwórz na Macu wpis klienta, który na nią wskazuje.