Co naprawdę robi pole Proxy w profilu VPN Apple
Wypełnienie pola proxy nie zamienia VPN w HTTP. W grę wchodzą dwa połączenia, a pole dociera tylko do jednego z nich.
Wypełnienie pola Proxy w konfiguracji VPN Apple sprawia wrażenie, że powinno przekierować tunel przez port sieciowy. Tak się nie dzieje. Pole wybiera pośrednika na poziomie aplikacji dla ruchu, który zgodna aplikacja zdecyduje się tam wysłać. Natomiast połączenie samego klienta VPN z jego bramą zależy od protokołu, nasłuchu i transportu, które skonfigurowałeś, i to są osobne decyzje.
Dwa połączenia, dwóch właścicieli
Każda taka konfiguracja obejmuje połączenie klienta z bramą oraz połączenie aplikacji z miejscem docelowym. Sekcja Proxy dotyczy drugiego, choć znajduje się w tym samym profilu co pierwsze.
| Connection | What decides its behaviour |
|---|---|
| VPN client to VPN gateway | The supported protocol, the listening port, the transport and the network policy in between |
| Application to a selected proxy | The application's own proxy support, the configured proxy policy, and the route to that next hop |
Dokumentacja ustawień proxy Apple wymienia HTTP, HTTPS, SOCKS i automatyczną konfigurację proxy, co opisuje wybory proxy aplikacji. Żaden z tych wpisów nie mówi, jak pakiet IPsec lub WireGuard dociera do bramy.
Oto szybka kontrola, która to rozstrzyga. Podaj port i protokół, które klient VPN raportuje w swoim logu. Jeśli ta linia nadal mówi UDP 500 lub UDP 51820, pole proxy niczego w niej nie zmieniło.
Kiedy pole jest właściwym narzędziem
Istnieje realny przypadek, w którym proxy stoi przed tunelem, ale to funkcja klienta, a nie pole profilu. Podręcznik OpenVPN dokumentuje --http-proxy dla połączeń TCP przenoszonych przez proxy HTTP CONNECT. Użycie wymaga odpowiedniej opcji klienta, osiągalnej w ten sposób bramy i proxy, które zezwala na CONNECT do używanego portu.
Jeśli twój klient udostępnia tę opcję, a sieć zezwala na CONNECT do portu, może to działać. Jeśli klient jej nie udostępnia, wypełnienie systemowego proxy nie ma żadnego wpływu na tunel.
Kiedy nic nie zmienia
Profil IKEv2 lub IPsec nie staje się tunelem HTTP dlatego, że pole proxy jest wypełnione. WireGuard też nie, bo jego format konfiguracji nie zna pojęcia proxy. Zmiana portu bramy nie zmienia też jej protokołu. A punkt końcowy odpowiadający na zwykły HTTPS nie jest automatycznie nasłuchem VPN.
Ta sama pułapka łapie ludzi, którzy kopiują profile z ery PPTP ze starych poradników iPad. Opcje nadal istnieją w interfejsie; usługa za nimi nie mówi już tym protokołem.
Decydowanie, którą warstwę naprawić
Zapytaj, która warstwa zawiodła, zanim cokolwiek zmienisz. Jeśli klient nie może ustanowić sesji, problemem jest transport, a pole proxy nie ma znaczenia. Jeśli tunel działa, ale jedna aplikacja nie dociera do swojego serwera, warto sprawdzić proxy aplikacji. Jeśli tunel działa, a wszystkie aplikacje zawodzą, podejrzani są routing i DNS wewnątrz tunelu.
W pierwszym przypadku zapytaj operatora, jaki zatwierdzony alternatywny transport lub sieć obsługuje. OpenVPN przez TCP 443 istnieje, ponieważ niektóre sieci pozwalają tylko na to, i nadal wymaga, aby serwer go nasłuchiwał.
Nie traktuj zablokowanego portu UDP jako zgody na improwizację. Zachowaj kontrole certyfikatu lub tożsamości bramy w nienaruszonym stanie zamiast je wyłączać, żeby uścisk dłoni pasował.
Potwierdź obie warstwy po kolei
Najpierw potwierdź tunel: sprawdź na stronie statusu klienta ustanowioną sesję i niezerową liczbę bajtów. Następnie odczytaj ustawienie proxy bezpośrednio, używając scutil --proxy dla obowiązującej konfiguracji lub networksetup -getwebproxy Wi-Fi dla zapisanej wartości. Potem przetestuj jedną aplikację, która respektuje systemowe proxy, i jedną, która je ignoruje, bo wiele natywnych aplikacji je ignoruje.
Trzy wyniki, trzy różne poprawki.
Jeśli obie warstwy zgłaszają sukces, a aplikacja nadal zawodzi, sprawdź split tunneling, DNS i własne ustawienia sieciowe aplikacji. To trzecia warstwa i ona też nie jest polem proxy.