په 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 ناسته د پراکسي هغه مخکینی تبادله نه ساتي. د مراجع او سرور ترمنځ مناسب خوندي مسیر وکاروئ.

د تنظیم بریالۍ کتنه نحوه او هویتونه تاییدوي، نه د حسابونو ډیټابیس یا شبکيز مسیر. د سرور په لاګونو کې وګورئ چې اصلي ازموینه په کوم پړاو کې رد شوه.

اړوندې مقالې