Dante ၏ UDP ပြန်ကြားချက် စည်းမျဉ်းများသည် from/to ဦးတည်ချက်ကို ပြောင်းပြန်လုပ်သည်
အပြင်သို့ထွက်နေသော client ၏ လိပ်စာယူဆချက်များကို ကူးယူမည့်အစား Dante ၏ ပြန်ကြားချက်စည်းမျဉ်းများကို အပြင်→အတွင်း ဦးတည်ချက်ဖြင့် အသုံးပြုပါ။
Client သည် အတည်ပြုပြီးဖြစ်ပြီး UDP ချိတ်ဆက်မှုကို ခွင့်ပြုထားသည်။ ပြန်ကြားချက်များ မအောင်မြင်သေးပါ။ Dante တွင် ပြန်လာသော traffic ကို ကိုင်တွယ်သော စည်းမျဉ်း၏ ဦးတည်ချက်ကို စစ်ဆေးပါ။
Dante သည် စတင်သော command များကို ပြန်ကြားချက် ကိုင်တွယ်မှုနှင့် ခွဲခြားထားသည်:
| စည်းမျဉ်း command များ | from | to |
|---|---|---|
connect, bind, udpassociate | အတွင်း client | အပြင် ဦးတည်ရာ |
bindreply, udpreply | အပြင် host | အတွင်း client |
Client ၏ subnet ကန့်သတ်ချက်ကို ဦးတည်ချက်နှစ်ခုလုံးသို့ မပြောင်းလဲဘဲ ကူးယူခြင်းသည် ပြန်ကြားချက်စည်းမျဉ်းတွင် မှားသောဘက်နှင့် ကိုက်ညီနိုင်သည်။ pass စည်းမျဉ်းတွင် UDP ဟူသော စကားလုံး ပါဝင်ခြင်း ရှိ/မရှိသာမက ရည်ရွယ်ထားသော အပြင် ပေးပို့သူများနှင့် အတွင်း လက်ခံသူများကို စစ်ဆေးပါ။
အတည်ပြုခြင်းတွင် ဆက်စပ်သော နယ်နိမိတ်တစ်ခု ရှိသည်။ UDP datagram ကို ပြန်ကြားသော အပြင်ဝန်ဆောင်မှုသည် သင့် username/password ဖလှယ်မှုကို အပြီးသတ်နိုင်သော SOCKS client မဟုတ်ပါ။ ပြန်ကြားချက်လုပ်ငန်းများသည် client ၏ ယခင် BIND သို့မဟုတ် UDP ချိတ်ဆက်မှုမှ ဖြစ်ပေါ်လာသည်ဟု Dante ၏ စာရွက်စာတမ်းက ရှင်းပြသည်။ ထို စတင်သော လုပ်ငန်းကို အတည်ပြုပြီး သင့်လျော်သော ဆက်စပ် ပြန်ကြားချက်မူဝါဒကို ကျင့်သုံးပါ။
ဤအရာသည် ကန့်သတ်မရှိသော၊ တောင်းဆိုမထားသော အဝင် traffic ကို တရားမဝင်စေပါ။ UDP ချိတ်ဆက်မှု၊ ဦးတည်ရာမူဝါဒ၊ relay လိပ်စာနှင့် firewall လမ်းကြောင်းတို့သည် အရေးကြီးဆဲဖြစ်သည်။ bindreply ကို ဖွင့်ခြင်းသည် UDP ချိတ်ဆက်မှုကို အထွေထွေ အများသူငှာ port ပို့ဆောင်မှုဝန်ဆောင်မှုအဖြစ် မပြောင်းလဲစေပါ။
Client ဘက်မှ SOCKS ဖလှယ်မှုနှင့် အမှန်တကယ် UDP ပြန်လာသော လမ်းကြောင်းကို သီးခြားမြင်နိုင်အောင် ထားပါ။ အောင်မြင်သော TCP login သည် ပြန်ကြားချက် ACL ၏ လိပ်စာဦးတည်ချက်ကိုလည်းကောင်း၊ UDP relay endpoint ၏ ရောက်ရှိနိုင်မှုကိုလည်းကောင်း အတည်မပြုပါ။