Gehitu erabiltzaile-izen bidezko autentifikazioa Danteri

Aldatu Dante 1.4.4ren SOCKS politika: jatorria soilik egiaztatu ordez, eskatu kontuaren egiaztapen esplizitua, jatorri- eta helmuga-mugak mantenduta.

Dante 1.4.4n, bezero-arauak konexioa onartzen du SOCKS negoziazioaren aurretik; SOCKS arauek erabakitzen dute autentifikatutako zein eskaerak jarrai dezaketen. Baimendutako jatorri bateko konexioak ere erabiltzaile-izena behar dezake bigarren fasean.

Sistema eragileko erabiltzaile-izenez autentifikatzeko, berrikusi zerbitzuaren identitateak eta metodoa. Kontuen datu-basea irakurtzeko identitate pribilegiatua behar izan daiteke:

clientmethod: none
socksmethod: username
user.privileged: root
user.unprivileged: danteproxy

Erabili Danterentzat instalatutako benetako zerbitzu-kontua, pribilegio gutxikoa. Sortu edo hautatu erabiltzaile-izenen backendarekin bateragarria den baimendutako bezero-kontua; zerbitzuaren identitateak eta bezeroaren saio-hasierak eginkizun desberdinak dituzte.

Mantendu eskaeren mugak

Lehendik dagoen bezero-arau murriztailearen ondoren, eskatu kontua baimendutako SOCKS bidean:

socks pass {
    from: 198.51.100.27/32 to: 203.0.113.20/32 port = 443
    command: connect
    socksmethod: username
    user: proxyuser
    log: connect error
}

Helbideak eta kontu-izena adibide-balioak dira. Honek jatorri bat, helmuga bat, komando bat eta adierazitako erabiltzaile autentifikatua baimentzen ditu. Ez ordezkatu muga hori mugarik gabeko jatorriekin pasahitza gehitu delako bakarrik.

Metodoaren ezarpen orokorrek eta arauaren ezarpenek bat etorri behar dute. Begiratu ea jatorrian soilik oinarritutako konfiguraziotik none bakarrik onartzen duen arau zaharrik geratu den. Mantendu aurreikusitako entzulearen eta suebakiaren mugak ere.

Probatu negoziazioa eta sarbidea bereizita

Abiarazi aurretik, egiaztatu fitxategia instalatutako zerbitzariaren konfigurazioa egiaztatzeko moduarekin. Ondoren, erabili SOCKS5 erabiltzaile-izen/pasahitz negoziazioa benetan onartzen duen bezero baimendua. Probatu kredentzialik eza, kredentzial okerrak eta debekatutako helmuga eskatzen duen kontu baimendua.

RFC 1929k definitutako erabiltzaile-izen/pasahitz azpinegoziazioak ez du pasahitza zifratzen. Helmugarekin geroagoko HTTPS saioak ez du aurreko proxy-truke hori babesten. Erabili bezeroaren eta zerbitzariaren arteko bide egoki babestua.

Konfigurazioaren egiaztapen arrakastatsuak sintaxia eta identitateak baieztatzen ditu, ez kontuen datu-basea edo sareko bidea. Begiratu zerbitzariaren erregistroetan benetako proba zein fasetan baztertu den.

Erlazionatutako artikuluak