Dante ته د کارننوم تصدیق ورزیات کړئ
د سرچینې او منزل محدودیتونه وساتئ او د Dante 1.4.4 د SOCKS تګلاره یوازې د سرچینې پر بنسټ لاسرسي څخه د حساب څرګندې کتنې ته واړوئ.
په 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 ناسته د پراکسي هغه مخکینی تبادله نه ساتي. د مراجع او سرور ترمنځ مناسب خوندي مسیر وکاروئ.
د تنظیم بریالۍ کتنه نحوه او هویتونه تاییدوي، نه د حسابونو ډیټابیس یا شبکيز مسیر. د سرور په لاګونو کې وګورئ چې اصلي ازموینه په کوم پړاو کې رد شوه.