Odbiornik TPROXY w Squidzie może z powodzeniem przyjmować ruch klientów, podczas gdy połączenie z jego nadrzędnym proxy kończy się niepowodzeniem. Zachowywanie adresu źródłowego na tym połączeniu wychodzącym może być nieodpowiednie dla ścieżki sieciowej nadrzędnego.

W wydaniach Squida obsługujących tę opcję dodaj no-tproxy do odpowiedniej istniejącej definicji cache_peer. Na przykład:

cache_peer parent.example.net parent 8118 0 no-query no-tproxy

no-tproxy wyłącza fałszowanie adresu źródłowego klienta dla połączeń z tym peenem. Nie usuwa przezroczystej konfiguracji odbiornika ani sam nie wybiera peera. Zachowaj pozostałe opcje i reguły wyboru nadrzędnego w danym wdrożeniu. Jeśli te reguły pozwalają na publiczne cele przez nieuwierzytelnionego nadrzędnego, lista proxy HTTP oferuje adresy-kandydatów; nie zachowuj istniejących poświadczeń nadrzędnego i sprawdź uprawnienia dla każdego rzeczywistego celu CONNECT.

Nadrzędny otrzymuje teraz normalne połączenie z własnego adresu wychodzącego Squida, z uwzględnieniem wszelkiego NAT. Jego polityka dostępu i uwierzytelnianie muszą pozwalać temu podrzędnemu proxy. Sprawdź adres źródłowy widziany przez nadrzędny, gdy stosuje ograniczenie IP.

Ta opcja jest udokumentowana dla Squida 7 i wcześniejszych obsługiwanych wydań; dokumentacja konfiguracji oznacza ją jako niedostępną w Squidzie 8. Trzymaj przepis powiązany z używaną wersją.

Powiązane artykuły