Samostatné přihlašovací údaje pro nadřazenou proxy Squidu

Přihlášení uživatele k vašemu Squidu a přihlášení Squidu k nadřazené proxy používají jiné údaje. Nadřazená proxy může patřit jinému provozovateli nebo používat jinou databázi účtů. Přijetí hesla klienta neznamená, že se má předat výše.

Squid 6.13 může připojit statické přihlášení k definici nadřazené proxy:

cache_peer 192.0.2.20 parent 3128 0 no-query default name=upstream login=parentuser:ExampleOnly

Adresa i heslo výše jsou dokumentační příklady. Přidejte přihlášení ke stávající definici nadřazené proxy, abyste nechtěně nevytvořili druhý peer. Zachovejte samostatnou směrovací politiku určující, které požadavky musí tuto nadřazenou proxy používat.

Oddělujte rozsahy účtů

Nastavení auth_param směrem ke klientům ověřují klienty vaší instance Squidu. Volba login u peeru dodává údaje pro jiný skok. Změna jednoho automaticky neaktualizuje druhé.

Dodržujte dokumentované požadavky nadřazené proxy na ověřování. Tento řádek není úplnou konfigurací pro každé ověřovací schéma orientované na spojení. Očekává-li nadřazená proxy NTLM nebo Negotiate, ověřte podporované uspořádání peerů místo opakovaného měnění hesla v tomto poli.

Squid má také volby předávání údajů, například PASS a PASSTHRU. Jejich význam se liší od vyhrazeného účtu nadřazené proxy a mohou peeru odhalit ověřovací údaje klienta. Nevolte je jako zkratku, pokud návrh počítá s oddělenými účty.

Chraňte konfiguraci a testujte správný skok

Statické tajemství je uloženo v konfiguraci. Omezte přístup k souborům a zálohám a před sdílením odstraňte citlivé údaje z výstupu parseru či ladění. Volba má vlastní pravidla escapování: dokumentace povoluje URL escape sekvence a vyžaduje zdvojení doslovného znaku procenta.

Pokud se klienti úspěšně ověří, ale předané požadavky dál selhávají u nadřazené proxy, zkontrolujte tuto výměnu a účet. Oddělujte také ochranu přenosu klient–Squid a Squid–nadřazená proxy; šifrování prvního spojení automaticky nezabezpečuje druhé.