Kräv inloggning på både 3proxys HTTP- och SOCKS-tjänster

Konfigurera 3proxy-användare, stark autentisering och åtkomstregler för tjänster för HTTP- och SOCKS5-klienter.

Att definiera en användare är inte hela inloggningskonfigurationen för 3proxy. Tjänsten behöver också en autentiseringsmetod och en åtkomstregel som använder den. Ordningen spelar roll eftersom tjänstens inställningar gäller medan konfigurationen bearbetas.

Ett endast lokalt exempel för två tjänster:

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

Konfigurationsreferensen förklarar users, auth strong och tjänstekommandona. CL lagrar detta exempellösenord som klartext. Skydda filen och välj en stödd form för lagring av autentiseringsuppgifter som passar driftsättningen.

Klienten behöver rätt inloggningsutbyte

HTTP-tjänsten förväntar sig HTTP-proxyautentisering. SOCKS-tjänsten behöver en klient som stöder SOCKS5-autentisering med användarnamn och lösenord. En SOCKS4-klient kan inte erbjuda det utbytet bara för att den når samma lyssnarport.

Ordet strong är namnet på ett autentiseringsläge, inte en garanti för krypterad transport. Skydda sträckan från klient till proxy när det behövs. HTTPS till målet och kryptering till proxyn är fortfarande separata beslut.

Loopback-bindningar begränsar detta exempel till lokal åtkomst. För fjärrklienter väljer du uttryckligen en avsedd lyssnare och nätverkspolicy. En offentlig jokertecken-lyssnare ersätter inte kontrollen av inloggningsbeteende.

Om en tjänst begär autentiseringsuppgifter och en annan inte, undersök inställningarna före varje tjänstekommando, reglerna efter varje flush och autentiseringscachen. Att byta lösenord kan inte reparera en tjänst som startats under fel policy. På samma sätt skapar inte ett byte av demonens operativsystemkonto någon proxyanvändare.

Relaterade artiklar