Najczęstsza pułapka rozszerzeń proxy do przeglądarki to zakres działania: przejmują tylko ruch przeglądarki i mogą przejść na połączenie bezpośrednie, gdy żadna reguła nie pasuje. Artykuł dzieli rozszerzenia według zastosowań, wymienia kryteria oceny, takie jak protokół, uwierzytelnianie, uprawnienia i stan utrzymania, oraz podaje kroki testów własnych adresu wyjściowego i wycieków WebRTC.
Rozszerzenia proxy do przeglądarki mają granicę, o której często się zapomina: przejmują wyłącznie żądania wysyłane przez przeglądarkę. Aktualizacje systemu, klienty stacjonarne i inne aplikacje nadal korzystają z pierwotnej drogi. Najpierw ustal, co dokładnie ma przechodzić przez proxy, a dopiero potem wybieraj narzędzie — oszczędzi to później wielu diagnoz.
Najpierw podziel je według trzech zastosowań
Najczęstsza potrzeba to przełączanie na poziomie pojedynczej witryny: kilka domen ma iść przez proxy, a reszta łączy się bezpośrednio. Taki scenariusz steruje się listą reguł, a wartość rozszerzenia polega na szybkim przełączaniu i rozdzielaniu ruchu według domen.
Drugi typ to proxy globalne, w którym cały ruch przeglądarki wychodzi jednym punktem wyjściowym. Konfiguracja jest najprostsza, ale koszt jest natychmiastowy: gdy wyjście padnie, przeglądarka praktycznie nie ma internetu, co czyni codzienne użytkowanie niestabilnym.
Trzeci typ jest związany ze środowiskiem: każdy profil przeglądarki ma przypisane stałe wyjście, a profile nie wpływają na siebie. To podejście stosuje się przy wielu kontach lub wielu projektach prowadzonych równolegle; rozszerzenie jest tu raczej uzupełnieniem, bo samo wyjście konfiguruje się zwykle na niższym poziomie.
Na co patrzeć, oceniając rozszerzenie
Obsługa protokołów jest na pierwszym miejscu. Proxy HTTP i HTTPS obsługują tylko TCP, natomiast SOCKS5 jest bardziej ogólny, ale jego obsługa UDP zależy od implementacji, a wiele rozszerzeń przepuszcza UDP bez zmian albo całkowicie je odrzuca. Ma to znaczenie później, bo wiąże się bezpośrednio z tym, czy WebRTC wycieka.
Uważnie przyjrzyj się metodzie uwierzytelniania. Logowanie nazwą użytkownika i hasłem jest wygodne, ale dane uwierzytelniające zapisane w rozszerzeniu leżą lokalnie jawnym tekstem lub ze słabym szyfrowaniem, więc każdy inny użytkownik komputera może je odczytać; uwierzytelnianie listą dozwolonych adresów IP niczego nie zapisuje w rozszerzeniu, ale za cenę aktualizowania listy przy każdej zmianie sieci.
Zakres działania to miejsce, w którym najczęściej pojawiają się problemy. W trybie reguł domeny niedopasowane do żadnej reguły domyślnie idą bezpośrednio, a użytkownik może nie wiedzieć, jakich domen strona faktycznie żąda. Gdy witryna HTTPS nawiąże połączenie, rozszerzenie widzi tylko domenę, a nie konkretną ścieżkę, więc pomysł rozdzielania ruchu według ścieżki praktycznie nie działa.
Warto też sprawdzić zakres uprawnień. Jeśli rozszerzenie proxy prosi dodatkowo o dostęp do danych wszystkich witryn, informacji o kartach czy schowka, zapytaj, czy te uprawnienia mają związek z funkcją, którą rzekomo oferuje. Aktualizacje wersji manifestu rozszerzeń przeglądarek również zawężają dostępne interfejsy, dlatego część starszych rozszerzeń musiała zmienić architekturę.
W przypadku aktywności utrzymaniowej nie patrz na liczbę wpisów w dzienniku zmian, lecz na to, czy ktoś nadąża za zmianami po stronie źródłowej. Wśród rozszerzeń proxy wersja sklepowa Proxy SwitchyOmega została wycofana, a utrzymywany przez społeczność fork (na przykład linia ZeroOmega) przejął dalsze dostosowanie; rozszerzenia takie jak FoxyProxy mają wersje na kilka przeglądarek. To wyłącznie neutralne przykłady; które pasuje najlepiej, nadal zależy od powyższych punktów.
Ruch, którego nie obejmuje
Po zainstalowaniu rozszerzenia sama przeglądarka idzie przez proxy, ale inne programy na tym samym komputerze, usługi aktualizacji w tle oraz część ruchu wewnątrz przeglądarki, który nie podąża ścieżką żądań rozszerzenia, mogą nadal wychodzić lokalnym wyjściem. Sprawdzania spójności sieci nie można ograniczać do panelu rozszerzenia. Pełną izolację trzeba rozwiązać na poziomie proxy systemowego lub wyżej.
Testy własne: najpierw wyjście, potem wycieki
Pierwszy krok to sprawdzenie adresu wyjściowego. Otwórz kilka stron zwracających adres IP odwiedzającego i lokalizację, sprawdź raz w zwykłym oknie i raz w karcie pasującej do reguł, a potem porównaj wyniki. Jeśli reguła wskazuje proxy, a mimo to widzisz adres lokalny, reguła nie zadziałała albo domena nie została dopasowana. Sprawdzenie kilku witryn ujawnia przypadki, w których tylko część żądań idzie przez proxy.
Drugi krok to sprawdzenie WebRTC. Dedykowane strony testowe podają lokalne adresy kandydackie i publiczne adresy kandydackie uzyskane przez przeglądarkę; jeśli wśród publicznych pojawia się prawdziwy adres IP zamiast wyjścia proxy, ruch UDP nie idzie przez proxy, a skrypty strony nadal mogą ustalić twoją rzeczywistą lokalizację sieciową.
Trzeci krok to sprawdzenie DNS. Jeśli lokalizacja serwera rozwiązywania nazw jest bardzo odległa od lokalizacji wyjścia, niektóre witryny uznają środowisko za nietypowe.
Ostatni krok to ponowny test w oknie incognito. Wiele rozszerzeń domyślnie nie działa w trybie incognito i trzeba je ręcznie dopuścić w ustawieniach; pominięcie tego kroku prowadzi do całkowicie błędnych wniosków.
Po testach zdecyduj, jak korzystać
Wyniki testów własnych są bardziej wiarygodne niż dokumentacja rozszerzenia. Dopiero gdy rzeczywiste wyjście, lokalizacja rozwiązywania DNS i ekspozycja WebRTC się zgadzają, zdecyduj, czy dalej korzystać z rozszerzenia, czy przenieść wyjście na niższy poziom. W scenariuszach z wieloma równoległymi środowiskami każdemu środowisku najlepiej przypisać własne, stałe wyjście, zamiast współdzielić jedno wyjście między kilkoma maszynami.
