เพิ่มการยืนยันตัวตนด้วยชื่อผู้ใช้ให้ Dante

ใน Dante 1.4.4 กฎไคลเอนต์รับการเชื่อมต่อก่อนการเจรจา SOCKS ส่วนกฎ SOCKS ตัดสินว่าคำขอที่ยืนยันตัวตนแล้วใดจะดำเนินต่อได้ การเชื่อมต่อจากต้นทางที่อนุญาตยังอาจต้องระบุชื่อผู้ใช้ในขั้นที่สอง

หากยืนยันตัวตนด้วยชื่อผู้ใช้ของระบบปฏิบัติการ ให้ตรวจตัวตนที่บริการใช้ควบคู่กับวิธีการด้วย การอ่านฐานข้อมูลบัญชีอาจต้องใช้ตัวตนที่มีสิทธิ์สูง:

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

ใช้บัญชีบริการสิทธิ์ต่ำที่ติดตั้งไว้จริงสำหรับ Dante สร้างหรือเลือกบัญชีไคลเอนต์ที่ได้รับอนุญาตและเข้ากันได้กับแบ็กเอนด์ชื่อผู้ใช้ ตัวตนของบริการกับการเข้าสู่ระบบของไคลเอนต์มีหน้าที่ต่างกัน

คงขอบเขตของคำขอไว้

หลัง กฎไคลเอนต์แบบจำกัดที่มีอยู่ ให้บังคับใช้บัญชีบนเส้นทาง SOCKS ที่อนุญาต:

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
}

ที่อยู่และชื่อบัญชีเป็นค่าตัวอย่าง การตั้งค่านี้อนุญาตต้นทางหนึ่ง ปลายทางหนึ่ง คำสั่งหนึ่ง และผู้ใช้ที่ยืนยันตัวตนตามที่ระบุ อย่าแทนที่ขอบเขตนี้ด้วยต้นทางที่ไม่จำกัดเพียงเพราะเพิ่มรหัสผ่านแล้ว

การตั้งค่าวิธีการส่วนกลางและเฉพาะกฎต้องสอดคล้องกัน ตรวจหากฎเก่าที่อนุญาตเฉพาะ none ซึ่งอาจเหลือจากการตั้งค่าแบบดูต้นทางอย่างเดียว คงข้อจำกัด listener และไฟร์วอลล์ที่ต้องการไว้ด้วย

ทดสอบการเจรจาและการเข้าถึงแยกกัน

ก่อนเริ่มทำงาน ให้ตรวจไฟล์ด้วยโหมดตรวจการตั้งค่าของเซิร์ฟเวอร์ที่ติดตั้ง จากนั้นใช้ไคลเอนต์ที่ได้รับอนุญาตและรองรับการเจรจาชื่อผู้ใช้/รหัสผ่าน SOCKS5 จริง ทดสอบ กรณีไม่มีข้อมูลรับรอง ข้อมูลผิด และบัญชีที่อนุญาตร้องขอเป้าหมายต้องห้าม

การเจรจาย่อยด้วยชื่อผู้ใช้/รหัสผ่านตาม RFC 1929 ไม่ได้เข้ารหัสรหัสผ่าน เซสชัน HTTPS กับปลายทางที่เกิดขึ้นภายหลังไม่ปกป้องการแลกเปลี่ยนกับพร็อกซีก่อนหน้านั้น ใช้เส้นทางจากไคลเอนต์ถึงเซิร์ฟเวอร์ที่ป้องกันอย่างเหมาะสม

การตรวจการตั้งค่าที่ผ่านยืนยันไวยากรณ์และตัวตน ไม่ใช่ฐานข้อมูลบัญชีหรือเส้นทางเครือข่าย ดูบันทึกเซิร์ฟเวอร์ว่าการทดสอบจริงถูกปฏิเสธในขั้นใด