VPN czy proxy: co każde z nich obejmuje, a czego nie

Zarówno VPN, jak i proxy forward zmieniają adres, który widzi witryna, i na tym kończy się większość porównań. Różnicą, która decyduje o twojej konfiguracji, jest zasięg: proxy forward to pośrednik, którego twoja aplikacja sama wybiera, w odróżnieniu od proxy odwrotnego stojącego przed witryną, a VPN przenosi wszystko, co system operacyjny kieruje do tunelu. Szyfrowanie, obsługa DNS i zachowanie przy awarii wynikają z tego podziału. Wykonaj tych pięć kontroli po kolei, a pierwsza nieudana powie ci, którego narzędzia naprawdę potrzebujesz.

Które aplikacje obejmuje pośrednik?

Rozszerzenie proxy w przeglądarce dotyczy tylko tego profilu przeglądarki. Klienci poczty, menedżery pakietów i druga przeglądarka nadal korzystają z własnych ustawień, a niektóre aplikacje całkowicie ignorują systemowe zmienne proxy. VPN obejmuje to, co tablica routingu wysyła do tunelu, a to mogą być wszystkie aplikacje lub podzbiór przy tunelu dzielonym, zależnie od tras i polityki klienta.

Testuj aplikacje, które mają znaczenie, zamiast uogólniać na podstawie jednego wczytania strony. curl https://ifconfig.me przestrzega zmiennych proxy środowiska; aplikacja desktopowa może nie. W Windows netsh winhttp show proxy wypisuje proxy WinHTTP używane przez usługi, a to inne ustawienie niż w przeglądarce.

Czy przeskok jest szyfrowany i gdzie kończy się TLS?

Protokół proxy to miejsce spotkania, nie gwarancja. SOCKS5 przekazuje TCP bez szyfrowania, a zwykłe proxy HTTP przenosi wiersz żądania i nagłówki jako czysty tekst. HTTPS przez proxy używa CONNECT, więc sesja TLS nadal kończy się w miejscu docelowym, a nie na proxy. Poradnik MDN o serwerach proxy i tunelowaniu opisuje tę różnicę od strony protokołu.

VPN szyfruje odcinek między twoim urządzeniem a jego punktem końcowym. Poza punktem końcowym obowiązują te same zasady co w każdej innej sieci, dlatego sam tunel nie chroni aplikacji, która wysyła dane logowania zwykłym HTTP. Żaden z tych projektów nie ukrywa zalogowanego konta, pliku cookie ani odcisku przeglądarki.

curl -v -x http://127.0.0.1:3128 https://example.com/ -o /dev/null
curl -v -x socks5h://127.0.0.1:1080 https://example.com/ -o /dev/null

Szczegółowe wyjście pokazuje, czy curl wysłał CONNECT na port 443, czy zwykłe GET z pełnym URL-em. Z socks5h:// nazwa hosta trafia do proxy wewnątrz żądania SOCKS5, a następnie proxy przekazuje dalej TLS, którego nie potrafi odczytać, więc widzi nazwę i liczbę bajtów. Przez proxy http:// adres https:// jest CONNECT, więc to proxy też widzi nazwę i objętość celu, ale nie żądanie ani treść odpowiedzi.

Który resolver widzi nazwę?

Rozwiązywanie nazw może odbywać się lokalnie, zanim żądanie wyjdzie, lub zdalnie na proxy. W curl socks5h:// wysyła nazwę hosta do proxy, a socks5:// najpierw rozwiązuje ją lokalnie. Ustawienia proxy przeglądarki oferują porównywalną opcję DNS, a pliki PAC mogą kierować różne hosty na różne sposoby.

Dwa protokoły mogą ominąć proxy bez żadnego błędu konfiguracji. WebRTC zbiera kandydatów przez STUN, a QUIC uruchamia HTTP/3 po UDP, czego proxy TCP nie potrafi przenieść. Przeglądarka wróci do TCP, jeśli UDP 443 jest zablokowany, dlatego blokowanie UDP 443 na zaporze hosta (lub na routerze dla całej sieci), a nie flaga przeglądarki, to niezawodny sposób utrzymania HTTP/3 na ścieżce proxy.

Sprawdź resolver z perspektywy celu, a nie swojego laptopa. Żądanie, które przychodzi z adresem wyjściowym proxy, ale z nazwą rozwiązaną lokalnie, nadal mówi lokalnemu resolverowi, jakie strony odwiedzasz.

Co się dzieje, gdy pośrednik zawiedzie?

Jawne proxy zawodzi zamknięte: zatrzymaj proces proxy, a przeglądarka lub aplikacja zwróci błąd połączenia zamiast iść bezpośrednio. Konfiguracje PAC i WPAD to te, które zawodzą otwarcie - jeśli skryptu nie da się pobrać, klient wraca do DIRECT i witryna znów widzi twój prawdziwy adres. VPN może zawodzić otwarcie lub zamknięte zależnie od klienta i tego, czy aktywny jest kill switch lub reguła zapory.

Przetestuj przypadek awarii celowo: zatrzymaj usługę proxy i przeładuj; jeśli dostaniesz stronę błędu zamiast bezpośredniego wczytania, skieruj URL PAC na nieosiągalny host, aby zobaczyć zachowanie zapasowe. Jeśli strona nadal wczytuje się zwykłą trasą, proxy nie oferuje żadnej ochrony przed własną awarią, a to właściwość, którą warto znać przed poleganiem na nim.

Kolejność decyduje o tym, co widzi witryna. Proxy, którego ruch wychodzący idzie przez VPN, pozostawia witrynie adres punktu końcowego VPN; umieść proxy poza tunelem (VPN do proxy na zdalnym hoście), a witryna zobaczy zamiast tego adres wyjściowy tego proxy. W obu przypadkach dwa przeskoki mogą rejestrować różne rzeczy.

Pięć kontroli, po kolei

Poniższa lista kontrolna to cała decyzja w jednym miejscu. Zasięg jest pierwszy, bo usuwa większość niezgodności: jeśli aplikacja, która ma być objęta, nie respektuje ustawienia, nic dalej na liście jej nie uratuje.

Następnie potwierdź wynik aplikacją, która wywołała zmianę. Wczytaj stronę w skonfigurowanej przeglądarce, pobierz tę samą stronę przez curl i porównaj adres, który zgłasza każda z nich. Jeśli się różnią, nadal działa rozszerzenie, reguła PAC lub nadpisanie na poziomie aplikacji, i żadne strojenie tunelu tego nie naprawi.

Zapisz, co skonfigurowałeś: które aplikacje korzystają z proxy, czy DNS jest lokalny czy zdalny, czy UDP jest zablokowany i jakie jest zachowanie przy awarii. Właśnie ten mały spis umożliwia następne porównanie, bo „IP się zmieniło” nigdy nie powiedziało, która z tych pięciu kontroli się powiodła.