Przeglądarka wczytuje stronę HTTP przez Squid. Ten sam cel zawodzi pod proxychains. To niekoniecznie oznacza, że jeden z dwóch programów wybrał zły adres IP proxy.

Zwykły klient rozumiejący HTTP może wysłać żądanie sieciowe do proxy pośredniczącego w formie HTTP proxy. Natomiast ogólna otoczka gniazda potrzebuje tunelu bajtowego dla połączenia, które aplikacja chciała otworzyć. Dla HTTP proxy w swoim łańcuchu proxychains używa CONNECT.

Oznacza to, że zwykła strona tekstowa na porcie 80 może wygenerować żądanie CONNECT dla portu 80. Zasada Squida zezwalająca na CONNECT tylko do zatwierdzonej listy portów TLS może odrzucić taki tunel, mimo że zwykłe żądania HTTP do portu 80 są dozwolone.

Porównuj żądania, nie tylko nazwy hostów

Dokumentacja proxychains-ng opisuje obsługę HTTP CONNECT. Reguły dostępu Squida potrafią rozróżnić metodę i port docelowy. To różne ścieżki żądań do tej samej witryny.

Przeczytaj odrzucenie i zamierzoną zasadę, zanim ją zmienisz. Rozszerzenie dostępu CONNECT na każdy port to istotna zmiana; nie powinno być domyślną reakcją na niezgodność otoczki.

Jeśli aplikacja ma natywną obsługę HTTP proxy, jej użycie może uniknąć niepotrzebnego ogólnego tunelu dla zwykłego tekstowego HTTP. Jeśli naprawdę potrzebuje surowego tunelu TCP, wybierz zatwierdzony protokół proxy i zasadę portów, które go zapewniają.

Udane żądanie przeglądarki jest użytecznym dowodem na osiągalność proxy i na jeden obsługiwany tryb żądania. Nie dowodzi jednak, że każda metoda tunelowania, port docelowy czy protokół aplikacji są dozwolone przez to proxy.

Powiązane artykuły