Magdagdag ng pagpapatunay gamit ang username sa Dante

Ilipat ang SOCKS policy ng Dante 1.4.4 mula sa access batay lamang sa pinagmulan tungo sa tahasang pagsusuri ng account, habang pinananatili ang mga limitasyon sa pinagmulan at destinasyon.

Sa Dante 1.4.4, tinatanggap ng mga client rule ang koneksiyon bago ang SOCKS negotiation, samantalang ang SOCKS rules ang nagpapasya kung aling napatunayang kahilingan ang maaaring magpatuloy. Maaari pa ring humingi ng username sa ikalawang yugto ang isang koneksiyon mula sa pinahihintulutang pinagmulan.

Para sa pagpapatunay gamit ang username ng operating system, suriin ang mga identidad ng serbisyo pati ang paraan. Maaaring kailanganin ang isang identidad na may mataas na pribilehiyo upang mabasa ang database ng mga account:

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

Gamitin ang aktuwal na service account na may mababang pribilehiyo na naka-install para sa Dante. Gumawa o pumili ng awtorisadong client account na tugma sa username backend; magkaiba ang papel ng identidad ng serbisyo at ng login ng client.

Panatilihin ang hangganan ng mga kahilingan

Pagkatapos ng kasalukuyang mahigpit na client rule, hingin ang account sa pinahihintulutang SOCKS route:

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
}

Mga halimbawang halaga ang mga address at pangalan ng account. Pinapayagan nito ang isang pinagmulan, isang destinasyon, isang command, at ang tinukoy na napatunayang user. Huwag palitan ang hangganang ito ng walang limitasyong mga pinagmulan dahil lamang nagdagdag ng password.

Dapat magkatugma ang pangkalahatan at pang-rule na mga setting ng paraan. Tingnan kung may lumang rule na none lamang ang pinapayagan at naiwan mula sa setup na pinagmulan lamang ang batayan. Panatilihin din ang nilalayong limitasyon ng listener at firewall.

Subukan nang magkahiwalay ang negotiation at access

Bago ito simulan, suriin ang file gamit ang configuration-check mode ng naka-install na server. Pagkatapos, gumamit ng awtorisadong client na tunay na sumusuporta sa SOCKS5 username/password negotiation. Subukan ang walang kredensiyal, maling kredensiyal, at pinahihintulutang account na humihiling ng ipinagbabawal na target.

Hindi ini-encrypt ng username/password subnegotiation na tinukoy sa RFC 1929 ang password. Hindi pinoprotektahan ng mas huling HTTPS session sa destinasyon ang naunang palitan sa proxy. Gumamit ng maayos na protektadong daan mula client papuntang server.

Kinukumpirma ng matagumpay na configuration check ang syntax at mga identidad, hindi ang database ng account o ang network path. Tingnan sa server logs kung saang yugto tinanggihan ang isang aktuwal na pagsubok.

Kaugnay na mga artikulo