Дефинирањето корисник не е целата конфигурација за најава на 3proxy. На услугата ѝ требаат и метод за автентикација и правило за пристап што го користи. Редоследот е важен затоа што поставките на услугата се применуваат додека конфигурацијата се обработува.

Пример само за локален пристап со две услуги:

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

Референцата за конфигурација објаснува users, auth strong и командите на услугите. CL ја чува оваа примерна лозинка како чист текст. Заштитете ја датотеката и изберете поддржан облик на чување на акредитиви соодветен за распоредувањето.

На клиентот му треба правилната размена при најава

Услугата HTTP очекува автентикација на HTTP прокси. На услугата SOCKS ѝ треба клиент што поддржува автентикација SOCKS5 со корисничко име и лозинка. Клиент SOCKS4 не може да ја обезбеди таа размена само затоа што стигнува до истиот порт за слушање.

Зборот strong е име на режим за автентикација, а не гаранција за шифриран пренос. Заштитете го делот од клиентот до проксито кога е потребно. HTTPS до целта и шифрирањето до проксито остануваат одделни одлуки.

Loopback поврзувањата го ограничуваат овој пример на локален пристап. За оддалечени клиенти изречно изберете предвиден слушач и мрежна политика. Јавен слушач со џокер не е замена за проверка на однесувањето при најава.

Ако една услуга бара акредитиви, а друга не, проверете ги поставките пред секоја команда на услуга, правилата по секое flush и кешот за автентикација. Менувањето лозинка не може да поправи услуга започната под погрешна политика. Исто така, менувањето на оперативниот системски сметка на демонот не создава корисник на проксито.

Поврзани статии