Squid ၏ SO_ORIGINAL_DST အမှားကို ဖတ်ခြင်း

NF getsockopt(SO_ORIGINAL_DST) သည် မူလဦးတည်ရာ ရှာဖွေမှုကို ညွှန်ပြသည်။ ကြားဖြတ်ဖမ်းယူမှု အပြင်အဆင်တွင် လမ်းကြောင်းပြောင်းထားသော ချိတ်ဆက်မှုသည် မူလက ဘယ်သို့သွားနေသည်ကို Squid က ပြန်လည်ရှာဖွေရမည်။

တိကျစွာ ပြင်ဆင်ထားသော ဘရောက်ဇာသည် ၎င်း၏ တောင်းဆိုချက်များကို ပရောက်စီသို့ ရည်ရွယ်ချက်ရှိရှိ ပို့သည်။ Squid listener ၏ port အနားတွင် intercept ရေးထားသည်ဟူသော အကြောင်းကြောင့်သာ ထိုချိတ်ဆက်မှုသည် NAT ကြားဖြတ်ဖမ်းယူမှု မှတ်တမ်း မရရှိပါ။

ထို့ကြောင့် ဤမကိုက်ညီမှုသည် ဦးတည်ရာ၏ လက်မှတ် သက်ဆိုင်လာခြင်းမပြုမီ ကျရှုံးနိုင်သည်။

ချိတ်ဆက်မှု မည်သို့ရောက်လာသည်မှ စတင်ပါ

• အပလီကေးရှင်းတွင် ပရောက်စီလိပ်စာ ပြင်ဆင်ထားပါက ၎င်းအသုံးပြုသင့်သော သာမန် ရှေ့သို့ပို့ ပရောက်စီ listener ကို ဖော်ထုတ်ပါ။
• တံခါးပေါက်တစ်ခုက မူလအားဖြင့် တိုက်ရိုက်ဖြစ်သော အသွားအလာကို လမ်းကြောင်းပြောင်းပါက ၎င်းသည် ရည်ရွယ်ထားသော ကြားဖြတ်ဖမ်းယူမှု listener သို့ ရောက်သည်နှင့် ပံ့ပိုးထားသော NAT ဒီဇိုင်းသည် လိုအပ်သော ဦးတည်ရာ အချက်အလက်ကို ထိန်းသိမ်းသည်ကို စစ်ဆေးပါ။
• မုဒ်နှစ်မျိုးလုံး ရှိပါက ကျရှုံးနေသော client သည် မည်သည့် လိပ်စာနှင့် port ကို အမှန်တကယ် ဆက်သွယ်ခဲ့သည်ကို စစ်ဆေးပါ။

Squid ၏ http_port စာရွက်စာတမ်းသည် ကွာခြားချက်ကို ရှင်းလင်းစွာ ဖော်ပြသည်- မုဒ်အလံကို ချန်လှပ်ခြင်းသည် ရှေ့သို့ပို့ ပရောက်စီမုဒ်ကို ရွေးချယ်သည်၊ intercept သည် IP အလွှာရှိ NAT ကြားဖြတ်ဖမ်းယူမှုကို မျှော်လင့်သည်။

ထို့နောက် သယ်ယူပို့ဆောင်ရေး လုံခြုံမှုကို သီးခြား ကိုင်တွယ်ပါ။ HTTP ပရောက်စီသည် CONNECT မှတစ်ဆင့် HTTPS ကို သယ်ဆောင်နိုင်သည်။ ပရောက်စီသို့ TLS ချိတ်ဆက်မှုအတွက် ကိုက်ညီသော listener နှင့် client ပြင်ဆင်မှု လိုအပ်သည်။ ဦးတည်ရာ အသွားအလာကို ဖော်ထုတ်ခြင်းသည် နောက်ထပ် ရွေးချယ်နိုင်သော စွမ်းရည်တစ်ခု ဖြစ်သည်။

ဦးတည်ရာ URL သည် HTTPS ဖြင့် စတင်သည်ဟူသော အကြောင်းကြောင့်သာ လက်မှတ်ထုတ်လုပ်ခြင်းကို ဖွင့်ပေးသော “HTTPS ပြင်ဆင်ချက်” ဟောင်းကို မကူးယူပါနှင့်။ ဦးစွာ client နှင့် listener ကြား သဘောတူညီမှုကို ပြုပြင်ပါ။ ထို့နောက် တကယ့် TLS အမှား ကျန်ရှိနေပါက ၎င်းသည် စစ်ဆေးရန် ပိုအသုံးဝင်သော အမှား ဖြစ်လာမည်။