Dlaczego 403 z witryny VPN nie jest awarią proxy

Użytkownicy rozłączają VPN, trafiają na 403 w witrynie wewnętrznej i zgłaszają, że proxy jest zepsute. Tę stronę mogą wygenerować trzy odrębne rzeczy: źródło odrzuciło żądanie, proxy przekazujące odmówiło otwarcia tunelu albo proxy zażądało własnych poświadczeń. Każda z nich jest poprawną odpowiedzią na inne pytanie, a spłaszczenie ich do jednej ogólnej strony błędu niszczy jedyny dowód, jaki masz. Posortuj odmowę według komponentu, który ją wygenerował, a następnie porównaj ścieżkę sieciową, której każdy komponent faktycznie używa.

Nazwij komponent, który wygenerował 403

Kod stanu HTTP należy do strony, która go wysłała. Gdy źródło zwraca 403, przeanalizowało żądanie i uznało, że wywołujący może nie mieć zasobu, co jest odpowiedzią autoryzacyjną, a nie problemem transportowym. Gdy proxy przekazujące odpowiada 403 na CONNECT, odmówiło zbudowania tunelu w ogóle i nic powyżej nie zostało nigdy połączone. Gdy odpowiada 407, chce własnych poświadczeń, które nie mają nic wspólnego z logowaniem do aplikacji.

RFC 9110 definiuje te role, w tym wyzwanie specyficzne dla proxy. Przeczytaj własny status odpowiedzi i każdy nagłówek Proxy-Authenticate przed przeczytaniem treści, ponieważ przyjazna strona błędu HTML zwykle ukrywa, który komponent ją napisał.

Co tunel CONNECT ukrywa przed przekaźnikiem bajtów

Gdy proxy zwraca 200 na CONNECT, przekazuje bajty, a przeglądarka utrzymuje własną sesję TLS ze źródłem. Proxy przekazujące bajty nie może więc odczytać zaszyfrowanego 403 wewnątrz tej sesji i nigdy nie staje się autorem odmowy. Odmowa przed otwarciem tunelu to zupełnie inne zdarzenie, wygenerowane o warstwę niżej.

Odwrotne proxy kończące TLS jest w innej pozycji: posiada granicę TLS, analizuje HTTP i może legalnie przepisywać lub przechwytywać odpowiedzi. Ta zdolność jest wyborem konfiguracji, a nie ogólną właściwością proxy, i nie uprawnia do omijania polityki dostępu aplikacji. Odczytywanie odpowiedzi jest zdolnością; decyzja, co wywołujący może zobaczyć, pozostaje zadaniem źródła.

Praktyczną konsekwencją jest to, że musisz wiedzieć, który z trzech kształtów uruchamiasz, zanim zinterpretujesz 403. Dodanie reguł inspekcji HTTP do proxy strumieniowego nie daje mu widoczności, a oczekiwanie, że przekaźnik bajtów wyjaśni odmowę źródła, wyśle cię do niewłaściwego dziennika.

Porównaj ścieżkę wyjścia proxy z adresem tunelu przeglądarki

Przeglądarka połączona z VPN nie przenosi automatycznie osobnego serwera proxy na ten tunel. Źródło widzi adres wyjścia proxy, a jeśli proxy nadal wychodzi przez lokalną trasę domyślną, chroniona witryna widzi adres, któremu nigdy nie skonfigurowano zaufania. Wewnętrzny adres VPN na laptopie jest niewidoczny dla tego źródła. To najczęstsza przyczyna, dla której działający tunel wciąż daje 403 z witryny, która zachowuje się poprawnie wobec wszystkich innych.

Przetestuj obie ścieżki osobno, aby adresów nie można było pomylić.

curl -sS -o /dev/null -w 'status=%{http_code}\n' --noproxy '*' https://198.51.100.20/private
curl -sS -o /dev/null -w 'status=%{http_code}\n' -x http://203.0.113.10:3128 https://198.51.100.20/private

Pierwsze żądanie pokazuje, co źródło odpowiada na twój własny adres, drugie — co odpowiada na adres proxy. Pasująca para 403 wskazuje na reguły autoryzacji źródła; 200, po którym następuje 403, wskazuje na ścieżkę proxy. Zapytaj właściciela źródła, jakie adresy źródłowe zestaw reguł faktycznie dopuszcza, zamiast zakładać, że pula VPN jest uwzględniona.

Przetestuj każdą granicę żądaniem, które ją izoluje

Wyizoluj warstwę proxy, prosząc ją o coś, czego nie może odmówić z powodów aplikacyjnych. CONNECT do hosta, do którego proxy ma dostęp, z odrzuconym wyjściem, mówi ci, czy dopuszczanie do tunelu w ogóle działa.

curl -sSv -o /dev/null -x http://203.0.113.10:3128 https://198.51.100.20/ 2>&1 | grep -E 'CONNECT|HTTP/1.1|Proxy-Authenticate'

Jeśli to wypisze 200 dla CONNECT, a potem uścisk TLS, dopuszczanie proxy jest w porządku, a późniejsze 403 przyszło od źródła. Jeśli wypisze 407, podaj poświadczenia proxy przez --proxy-user i powtórz, zanim wyciągniesz jakikolwiek wniosek o witrynie. Jeśli wypisze 403 w wierszu CONNECT, własna lista dozwolonych proxy jest granicą do zbadania, a aplikacja nie jest zaangażowana.

Trzymaj poświadczenia poza historią powłoki i poza wklejonymi transkryptami. Hasło proxy wpisane w wierszu poleceń jest widoczne dla innych lokalnych użytkowników, a przechwycony ślad CONNECT z poświadczeniami jest gorszy niż brak śladu.

Zachowaj werdykt czytelny, zamiast przepisywać stronę

Gdy wiesz, który komponent odmówił, zachowaj tę odpowiedź. Odwrotne proxy, które zmienia nazwę 403 źródła na limit czasu 504 lub zastępuje je stroną sukcesu, ukrywa decyzję autoryzacyjną za historią dostępności i wysyła następnego respondenta do niewłaściwego zespołu. Niestandardowe strony błędów są w porządku, gdy zachowują status i dodają kontekst.

Buforowanie zasługuje na taką samą staranność. RFC 9111 reguluje, jak współdzielone pamięci podręczne mogą ponownie używać odpowiedzi, a odmowa wygenerowana dla jednego wywołującego nie może zostać przekazana innemu tak, jakby była pozwoleniem. Jeśli odpowiedzi odmowy są w ogóle przechowywane, trzymaj je prywatne i ograniczone, i nigdy nie dodawaj publicznej reguły świeżości tylko po to, by zmniejszyć ruch nadrzędny.

Zakończ pisemnym werdyktem, który nazywa komponent, wygenerowany status i adres źródłowy, który widziało źródło. Zapisz dokładne żądanie, obowiązujące ustawienia proxy i czas, aby następny raport można było porównać z tymi samymi dowodami zamiast wyprowadzać go ponownie z pamięci. Ten zapis odpowiada na następny raport w sekundach i powstrzymuje ponowne diagnozowanie tego samego 403 jako awarii VPN.