IPv4 ဖြင့် ဖောက်သည်ကို လက်ခံပြီး ၎င်းတောင်းခံသော ဝဘ်ဆိုက်ကို IPv6 ဖြင့် ရောက်ရှိနိုင်သည်။ ဤအရာများသည် သီးခြားချိတ်ဆက်မှုများဖြစ်သည်။ ဝဘ်ဆိုက်ဘက်ဆိုင်ရာ မူဝါဒသည် IPv4 ဖောက်သည်များကို အလိုအလျောက် ငြင်းပယ်သင့်မည်မဟုတ်ပါ။

ခရီးဆုံးမိသားစု ငြင်းပယ်မှုကို src ipv4 နှင့် ပေါင်းစပ်ထားသော ဥပမာများတွင် ဤအချက်သည် ထောင်ချောက်ဖြစ်သည်- ရင်းမြစ် ACL သည် မည်သူချိတ်ဆက်နိုင်သည်ကို ပြောင်းလဲသည်၊ မည်သည့်ဝဘ်ဆိုက်ချိတ်ဆက်မှုကို ခွင့်ပြုသည်သာ မဟုတ်ပါ။

ရည်ရွယ်သော ကန့်သတ်ချက်ကို သတ်မှတ်ပါ

သက်ဆိုင်ရာ IP ACL များကို ပံ့ပိုးသော Squid ထုတ်ဝေမှုများအတွက် ခရီးဆုံးမိသားစု စည်းမျဉ်းသည် IPv4 ခရီးဆုံးများကို ခွဲခြားရန် dst ipv4 ကို အသုံးပြုနိုင်သည်။ ထိုသို့သော စည်းမျဉ်းများကို လက်ရှိ စစ်ဆေးအတည်ပြုမှုနှင့် ခရီးဆုံးခွင့်ပြုချက်များနှင့် ပေါင်းစပ်ပါ။ ၎င်းတို့ကို ကျော်ဖြတ်သည့် ကျယ်ပြန့်သော IPv6 ခွင့်ပြုချက်ကို မထည့်ပါနှင့်။

ACL ရည်ညွှန်းချက်သည် ရင်းမြစ်နှင့် ခရီးဆုံး အမျိုးအစားများကို ခွဲခြားသည်။ ဤအရာသည် ကန့်သတ်ချက်ဖြစ်ပြီး အလိုအလျောက် ဘာသာပြန်ဝန်ဆောင်မှု မဟုတ်ပါ။ IPv4 သီးသန့် ဝဘ်ဆိုက်သည် စက်က IPv4 ဖြင့် ရောက်ရှိနိုင်သော်လည်း မရရှိနိုင်ဖြစ်သွားနိုင်သည်။

အပြင်ထွက် IPv6 လိပ်စာကို ချိတ်ဆွဲခြင်းသည်လည်း အပြည့်အစုံ အ enforcement မူဝါဒ မဟုတ်ပါ။ ရင်းမြစ်ရွေးချယ်မှု၊ ခွင့်ပြုထားသော ခရီးဆုံးမိသားစုများ၊ DNS အဖြေများနှင့် အမှန်တကယ် ကွန်ရက်ရောက်ရှိနိုင်မှု အားလုံး ပါဝင်သည်။ IPv4 သို့ ပြန်လည်ရောက်ရှိမှုကို လက်ခံနိုင်ခြင်း ရှိ/မရှိ ရှင်းလင်းစွာ ဆုံးဖြတ်ပါ။

forwarded_for ကို ပြောင်းလဲခြင်းသည် ဤပြဿနာကို မဖြေရှင်းပါ။ ၎င်းသည် HTTP ခေါင်းစီးကို သက်ရောက်သည်၊ ပရောက်စီ၏ TCP ချိတ်ဆက်မှု လိပ်စာမိသားစုကို မဟုတ်ပါ။ အလားတူပင် IPv6 DNS resolver သည် ၎င်းဖြေကြားသော အမည်တိုင်းတွင် IPv6 ခရီးဆုံး ရှိသည်ဟု အာမမခံပါ။

ကြီးမားသော ဟောင်းနွမ်းသည့် ဖွဲ့စည်းမှုကို မလက်ခံမီ ထုတ်ဝေမှုအလိုက် အပြုအမူကို စစ်ဆေးပါ။ အထူးသဖြင့်- Squid 5 မှ 7 အထိ dns_v4_first သည် ပံ့ပိုးထားသော မိသားစုဦးစားပေး ခလုတ် မဟုတ်ပါ။ တိကျစွာ ဖော်ပြနိုင်သော မူဝါဒသည် ဆက်စပ်မှုမရှိသော IPv6 ဆက်တင်များ အစုအဝေးထက် အတည်ပြုရ ပိုလွယ်သည်။

ဆက်စပ်ဆောင်းပါးများ