Legg til brukarnamnautentisering i Dante

Endra SOCKS-policyen i Dante 1.4.4 frå tilgang berre etter kjelde til ein uttrykkeleg kontosjekk, samstundes som kjelde- og målgrensene vert haldne ved lag.

I Dante 1.4.4 slepper klientreglane til sambandet før SOCKS-forhandlinga, medan SOCKS-reglane avgjer kva autentiserte førespurnader som får halda fram. Eit samband frå ei tillaten kjelde kan framleis krevja brukarnamn i andre steg.

Ved autentisering med brukarnamna i operativsystemet må du sjå over tenesteidentitetane i tillegg til metoden. Lesing av kontodatabasen kan krevja ein privilegert identitet:

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

Bruk den faktiske tenestekontoen med låge rettar som er installert for Dante. Opprett eller vel ein autorisert klientkonto som passar til brukarnamnsbakenden; tenesteidentiteten og klientinnlogginga har ulike roller.

Hald grensene for førespurnader ved lag

Etter den eksisterande, snevre klientregelen krev du kontoen på den tillatne SOCKS-ruta:

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
}

Adressene og kontonamnet er dømeverdiar. Dette tillèt éi kjelde, eitt mål, éin kommando og den oppgjevne autentiserte brukaren. Ikkje byt ut denne grensa med uavgrensa kjelder berre fordi eit passord er lagt til.

Dei globale og regelspesifikke metodeinnstillingane må stemma overeins. Sjå etter ein gammal regel som berre tillèt none og står att frå eit oppsett basert berre på kjelde. Hald òg dei planlagde lyttar- og brannmurgrensene ved lag.

Test forhandling og tilgang kvar for seg

Kontroller fila med konfigurasjonssjekken til den installerte tenaren før du startar han. Bruk deretter ein autorisert klient som faktisk støttar SOCKS5-forhandling med brukarnamn og passord. Test manglande og feil innloggingsopplysningar og ein tillaten konto som ber om eit forbode mål.

Underforhandlinga med brukarnamn og passord i RFC 1929 krypterer ikkje passordet. Ei seinare HTTPS-økt til målet vernar ikkje den tidlegare proxyutvekslinga. Bruk ein høveleg verna veg frå klient til tenar.

Ein vellukka konfigurasjonssjekk stadfestar syntaks og identitetar, ikkje kontodatabasen eller nettverksvegen. Sjå i tenarloggane kva steg som avviste ein reell test.

Relaterte artiklar