افزودن احراز هویت با نام کاربری به 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 از پیکربندی صرفاً مبدأمحور باقی نمانده باشد. محدودیت‌های موردنظر شنونده و دیواره آتش را هم نگه دارید.

مذاکره و دسترسی را جداگانه آزمایش کنید

پیش از راه‌اندازی، فایل را با حالت بررسی پیکربندی سرور نصب‌شده بررسی کنید. سپس از کلاینت مجازی استفاده کنید که واقعاً مذاکره نام کاربری/گذرواژه SOCKS5 را پشتیبانی کند. نبود اطلاعات ورود، اطلاعات نادرست و درخواست مقصد ممنوع از حساب مجاز را امتحان کنید.

زیرمذاکره نام کاربری/گذرواژه تعریف‌شده در RFC 1929 گذرواژه را رمزگذاری نمی‌کند. نشست بعدی HTTPS با مقصد، آن تبادل قبلی پروکسی را محافظت نمی‌کند. مسیر بین کلاینت و سرور را به‌درستی محافظت کنید.

موفقیت بررسی پیکربندی، نحو و هویت‌ها را تأیید می‌کند، نه پایگاه داده حساب‌ها یا مسیر شبکه را. گزارش‌های سرور را ببینید تا مشخص شود آزمایش واقعی در کدام مرحله رد شده است.