Definovat uživatele neznamená celou konfiguraci přihlašování v 3proxy. Služba také potřebuje metodu autentizace a přístupové pravidlo, které ji používá. Na pořadí záleží, protože nastavení služby se uplatňují během zpracování konfigurace.

Příklad pouze pro místní přístup se dvěma službami:

users alex:CL:replace_with_a_private_password
auth strong
allow alex
proxy -i127.0.0.1 -p3128
flush
allow alex
socks -i127.0.0.1 -p1080

Referenční příručka konfigurace vysvětluje users, auth strong a příkazy služeb. CL ukládá toto ukázkové heslo jako prostý text. Chraňte soubor a zvolte podporovanou formu ukládání přihlašovacích údajů vhodnou pro nasazení.

Klient potřebuje správnou výměnu přihlášení

Služba HTTP očekává autentizaci HTTP proxy. Služba SOCKS potřebuje klienta, který podporuje autentizaci SOCKS5 uživatelským jménem a heslem. Klient SOCKS4 nemůže tuto výměnu poskytnout jen proto, že dosáhne stejného portu pro naslouchání.

Slovo strong je název režimu autentizace, nikoli záruka šifrovaného přenosu. V případě potřeby chraňte úsek od klienta k proxy. HTTPS k cíli a šifrování k proxy zůstávají samostatnými rozhodnutími.

Vazby na loopback omezují tento příklad na místní přístup. Pro vzdálené klienty výslovně zvolte zamýšlený naslouchač a síťovou politiku. Veřejný naslouchač s divokou kartou nenahrazuje kontrolu chování přihlášení.

Pokud jedna služba vyžaduje údaje a druhá ne, prozkoumejte nastavení před každým příkazem služby, pravidla po každém flush a mezipaměť autentizace. Změna hesla nemůže opravit službu spuštěnou s nesprávnou politikou. Stejně tak změna systémového účtu démona nevytvoří uživatele proxy.

Související články