Kërkoni hyrje në të dy shërbimet HTTP dhe SOCKS të 3proxy

Konfiguroni përdoruesit e 3proxy, vërtetim të fortë dhe rregulla aksesi për shërbimet për klientët HTTP dhe SOCKS5.

Përcaktimi i një përdoruesi nuk është e gjithë konfigurimi i hyrjes në 3proxy. Shërbimi ka nevojë edhe për një metodë vërtetimi dhe një rregull aksesi që e përdor atë. Radha ka rëndësi, sepse cilësimet e shërbimit zbatohen ndërsa konfigurimi përpunohet.

Një shembull vetëm lokal për dy shërbime:

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

Referenca e konfigurimit shpjegon users, auth strong dhe komandat e shërbimit. CL e ruan këtë fjalëkalim shembull si tekst të thjeshtë. Mbrojeni skedarin dhe zgjidhni një formë të mbështetur të ruajtjes së kredencialeve të përshtatshme për vendosjen.

Klienti ka nevojë për shkëmbimin e duhur të hyrjes

Shërbimi HTTP pret vërtetim proxy HTTP. Shërbimi SOCKS ka nevojë për një klient që mbështet vërtetimin SOCKS5 me emër përdoruesi dhe fjalëkalim. Një klient SOCKS4 nuk mund ta ofrojë atë shkëmbim vetëm sepse arrin të njëjtën portë dëgjimi.

Fjala strong është emri i një mënyre vërtetimi, jo garanci e transportit të kriptuar. Mbrojeni segmentin nga klienti te proxy kur është e nevojshme. HTTPS drejt destinacionit dhe kriptimi drejt proxy-t mbeten vendime të veçanta.

Lidhjet loopback e kufizojnë këtë shembull në akses lokal. Për klientët në distancë, zgjidhni në mënyrë të qartë një dëgjues dhe politikë rrjeti të synuar. Një dëgjues publik me wildcard nuk e zëvendëson kontrollin e sjelljes së hyrjes.

Nëse një shërbim kërkon kredenciale dhe tjetri jo, shqyrtoni cilësimet para çdo komande shërbimi, rregullat pas çdo flush dhe memorien e vërtetimit. Ndryshimi i fjalëkalimit nuk mund të riparojë një shërbim të nisur nën politikë të gabuar. Po ashtu, ndryshimi i llogarisë së sistemit operativ të demonit nuk krijon përdorues proxy.

Artikuj të ngjashëm