Vaadi kirjautuminen molemmissa 3proxyn HTTP- ja SOCKS-palveluissa

Käyttäjän määrittäminen ei ole koko 3proxyn kirjautumismääritys. Palvelu tarvitsee myös todennusmenetelmän ja käyttöoikeussäännön, joka käyttää sitä. Järjestys on tärkeä, koska palvelun asetukset otetaan käyttöön määrityksen käsittelyn aikana.

Vain paikallisen käytön esimerkki kahdelle palvelulle:

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

Määritysviite selittää users, auth strong ja palvelukomennot. CL tallentaa tämän esimerkkisalasanan selkokielisenä. Suojaa tiedosto ja valitse tuettu tunnistetietojen tallennusmuoto, joka sopii käyttöönottoon.

Asiakas tarvitsee oikean kirjautumisvaihdon

HTTP-palvelu odottaa HTTP-välityspalvelimen todennusta. SOCKS-palvelu tarvitsee asiakkaan, joka tukee SOCKS5-käyttäjätunnus- ja salasanatodennusta. SOCKS4-asiakas ei voi tarjota tätä vaihtoa pelkästään siksi, että se tavoittaa saman kuunteluportin.

Sana strong on todennusmuodon nimi, ei salatun siirron tae. Suojaa asiakkaan ja välityspalvelimen välinen osuus tarvittaessa. HTTPS kohteeseen ja salaus välityspalvelimeen ovat edelleen erillisiä päätöksiä.

Loopback-sidonnat rajaavat tämän esimerkin paikalliseen käyttöön. Valitse etäasiakkaille nimenomaisesti aiottu kuuntelija ja verkkokäytäntö. Julkinen jokerimerkkikuuntelija ei korvaa kirjautumiskäyttäytymisen tarkistamista.

Jos yksi palvelu pyytää tunnistetietoja ja toinen ei, tarkista asetukset ennen jokaista palvelukomentoa, säännöt minkä tahansa flush-komennon jälkeen ja todennuksen välimuisti. Salasanan vaihtaminen ei korjaa palvelua, joka käynnistettiin väärällä käytännöllä. Samoin daemonin käyttöjärjestelmätilin vaihtaminen ei luo välityspalvelinkäyttäjää.