Dodajte provjeru korisničkim imenom u Dante

Prebacite SOCKS pravila u Dante 1.4.4 s pristupa samo prema izvoru na izričitu provjeru računa, uz zadržavanje ograničenja izvora i odredišta.

U Dante 1.4.4 klijentska pravila prihvaćaju vezu prije SOCKS pregovaranja, a SOCKS pravila određuju koji autentificirani zahtjevi smiju nastaviti. Veza s dopuštenog izvora i dalje može zahtijevati korisničko ime u drugoj fazi.

Za autentifikaciju korisničkim imenom operacijskog sustava pregledajte identitete usluge i metodu. Čitanje baze računa može zahtijevati povlašteni identitet:

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

Upotrijebite stvarni račun usluge s malim ovlastima instaliran za Dante. Stvorite ili odaberite ovlašteni klijentski račun kompatibilan s pozadinskim sustavom za korisnička imena; identitet usluge i klijentska prijava imaju različite uloge.

Zadržite granice zahtjeva

Nakon postojećeg uskog klijentskog pravila zahtijevajte račun na dopuštenoj SOCKS ruti:

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
}

Adrese i naziv računa su primjeri. Time se dopuštaju jedan izvor, jedno odredište, jedna naredba i navedeni autentificirani korisnik. Ne zamjenjujte tu granicu neograničenim izvorima samo zato što je dodana lozinka.

Globalne postavke metode i postavke pojedinačnog pravila moraju se podudarati. Provjerite postoji li staro pravilo samo s none zaostalo iz postavke pristupa isključivo prema izvoru. Zadržite i predviđena ograničenja slušača i vatrozida.

Pregovaranje i pristup testirajte odvojeno

Prije pokretanja provjerite datoteku načinom provjere konfiguracije instaliranog poslužitelja. Zatim upotrijebite ovlašteni klijent koji doista podržava SOCKS5 pregovaranje korisničkim imenom i lozinkom. Provjerite nedostajuće i pogrešne vjerodajnice te dopušteni račun koji traži zabranjeni cilj.

Potpregovaranje korisničkim imenom i lozinkom definirano u RFC 1929 ne šifrira lozinku. Kasnija HTTPS sesija s odredištem ne štiti tu raniju razmjenu s proxyjem. Upotrijebite primjereno zaštićen put između klijenta i poslužitelja.

Uspješna provjera konfiguracije potvrđuje sintaksu i identitete, a ne bazu računa ili mrežni put. U zapisnicima poslužitelja pronađite fazu koja je odbila stvarni test.

Povezani članci