NSX-V ရှိ VXLAN - ပြဿနာဖြေရှင်းခြင်း အောက်ခံ

မင်္ဂလာပါ ၊ ပထမဆုံး စာသားလေးတွေပါ ။ အဝေးကနေ အလုပ်လုပ်တဲ့ လုပ်ဖော်ကိုင်ဖက်တွေကို တစ်ခါတစ်လေ ငြူစူမိတယ် - အင်တာနက်ချိတ်ဆက်တဲ့ကမ္ဘာရဲ့ ဘယ်အချိန်မဆို အလုပ်ပိတ်ရက်တွေ၊ ပရောဂျက်တွေနဲ့ သတ်မှတ်ရက်တွေမှာ တာဝန်ယူမှု၊ ရုံးမတက်ဘဲ ၈ နာရီကနေ ၁၇ နာရီအထိ အလုပ်လုပ်ခွင့်ရတာ အရမ်းကောင်းပါတယ်။ ရာထူးနှင့် လုပ်ငန်းတာဝန်များသည် ဒေတာစင်တာမှ ကြာရှည်စွာ ပျက်ကွက်ခြင်း ဖြစ်နိုင်ခြေကို လက်တွေ့အားဖြင့် ဖယ်ထုတ်ထားသည်။ သို့သော်၊ အောက်တွင်ဖော်ပြထားသည့်အရာကဲ့သို့ စိတ်ဝင်စားစရာကောင်းသည့်ကိစ္စများသည် ရံဖန်ရံခါဖြစ်ပေါ်နေပြီး အတွင်းပြဿနာဖြေရှင်းသူ၏ဖန်တီးမှုဆိုင်ရာဖော်ပြမှုအတွက် ထိုကဲ့သို့သောနယ်ပယ်တွင် ရာထူးအနည်းငယ်သာရှိသည်ကို ကျွန်ုပ်နားလည်ပါသည်။

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

ပထမအချက်၊ နိဒါန်းမှတ်စု- VMWare သီးသန့် cloud တွင် client solutions များကို လက်ခံဆောင်ရွက်ပေးသည့် (ကျွန်တော် network engineer အဖြစ် အလုပ်လုပ်သည့်) ကုမ္ပဏီတစ်ခုရှိပါသည်။ ဖြေရှင်းချက်အသစ်အများစုသည် NSX-V မှ စီမံခန့်ခွဲသည့် VXLAN အပိုင်းများနှင့် ချိတ်ဆက်သည် - ဤဖြေရှင်းချက်သည် ကျွန်ုပ်အား အချိန်မည်မျှပေးသည်ကို အတိုချုပ်အားဖြင့် ခန့်မှန်းမည်မဟုတ်ပါ။ NSX ESG ကိုတည်ဆောက်ရာတွင် ကျွန်ုပ်၏လုပ်ဖော်ကိုင်ဖက်များကိုပင် လေ့ကျင့်သင်ကြားနိုင်ခဲ့ပြီး ကျွန်ုပ်၏ပါဝင်မှုမရှိဘဲ ဖောက်သည်ဖြေရှင်းချက်ငယ်များကို လက်တွေ့အသုံးချခဲ့သည်။ အရေးကြီးသောမှတ်ချက်- ကျွန်ုပ်တို့တွင် unicast ပုံတူကူးယူထားသော ထိန်းချုပ်မှုလေယာဉ်တစ်ခုရှိသည်။ hypervisors များကို မတူညီသော ရုပ်ပိုင်းဆိုင်ရာ Juniper QFX5100 ခလုတ်များ ( Virtual Chassis တွင် စုစည်းထားသည်) နှင့် virtual port timing policy ကို စတင်သည့် လမ်းကြောင်းပေါ်အခြေခံ၍ လမ်းကြောင်းနှစ်ခုဖြင့် မလိုအပ်ဘဲ ချိတ်ဆက်ထားသည် - ၎င်းသည် ပြီးပြည့်စုံမှုအတွက်ဖြစ်သည်။

ဖောက်သည်ဖြေရှင်းချက်များသည် အလွန်ကွဲပြားသည်- မှ Windows IIS မှာဆိုရင် web server component အားလုံးကို စက်တစ်ခုတည်းမှာ install လုပ်ထားပြီး အတော်လေးကြီးမားတဲ့ component တွေအထိ ရှိပါတယ်—ဥပမာ load-balanced Apache web frontends + Galera မှာ LB MariaDB + GlusterFS ကိုသုံးပြီး synchronize လုပ်ထားတဲ့ shared server တွေပေါ့။ server အားလုံးနီးပါးကို သီးခြားစောင့်ကြည့်ဖို့ လိုအပ်ပြီး component အားလုံးမှာ public address တွေ မရှိပါဘူး။ ဒီပြဿနာကို ကြုံတွေ့ဖူးပြီး ပိုကောင်းမွန်တဲ့ ဖြေရှင်းချက်ရှိရင် အကြံဉာဏ်ပေးပါဦး။
ကျွန်ုပ်၏စောင့်ကြည့်စစ်ဆေးခြင်းဖြေရှင်းချက်တွင် firewall (Fortigate) တစ်ခုစီကို အတွင်းပိုင်းဖောက်သည်ကွန်ရက်တစ်ခုစီသို့ "ချိတ်ဆက်ခြင်း" ပါဝင်ပါသည် (+SNAT နှင့် ခွင့်ပြုထားသောလမ်းကြောင်းအမျိုးအစားအပေါ် တင်းကျပ်သောကန့်သတ်ချက်များ) နှင့် အတွင်းပိုင်းလိပ်စာများကို စောင့်ကြည့်ခြင်းပါဝင်သည် - ဤနည်းဖြင့် စောင့်ကြည့်လေ့လာခြင်း၏ ပေါင်းစပ်မှုနှင့် ရိုးရှင်းမှုတစ်ခုဖြစ်သည်။ အောင်မြင်သည်။ စောင့်ကြည့်စစ်ဆေးခြင်းကို PRTG ဆာဗာ အစုအဝေးမှ ပြုလုပ်သည်။ စောင့်ကြည့်ရေးအစီအစဥ်သည် ဤအရာဖြစ်သည်-

ကျွန်ုပ်တို့သည် VLAN ဖြင့်သာ လုပ်ဆောင်နေချိန်တွင်၊ အရာအားလုံးသည် ပုံမှန်ဖြစ်ပြီး နာရီအလုပ်ကဲ့သို့ပင် ကြိုတင်မှန်းဆနိုင်သည်။ NSX-V နှင့် VXLAN တို့ကို မိတ်ဆက်ပြီးနောက်၊ ကျွန်ုပ်တို့သည် မေးခွန်းနှင့် ရင်ဆိုင်ခဲ့ရသည်- ရှေးနည်းအတိုင်း ဆက်လက်စောင့်ကြည့်ရန် ဖြစ်နိုင်ပါသလား။ ဤမေးခွန်း၏အချိန်တွင်၊ "အမြန်ဆုံး" ဖြေရှင်းချက်မှာ NSX ESG ကိုအသုံးပြုပြီး VXLAN ပင်စည် interface ကို VTEP ကွန်ရက်သို့ချိတ်ဆက်ရန်ဖြစ်သည်။ ကိုးကားချက်များတွင် မြန်ဆန်သည် - client networks များကို configure လုပ်ရန် GUI ကိုအသုံးပြုခြင်းကြောင့်၊ SNAT နှင့် firewall စည်းမျဉ်းများသည် vSphere interface တစ်ခုတည်းတွင် စီမံခန့်ခွဲမှုကို ပေါင်းစည်းနိုင်မည်ဖြစ်ပြီး၊ ကျွန်ုပ်၏အမြင်အရ ၎င်းသည် အလွန်ခက်ခဲပြီး ပြဿနာဖြေရှင်းခြင်းအတွက် ကိရိယာအစုံကို ကန့်သတ်ထားသည်။ "အစစ်အမှန်" firewall ကိုအစားထိုးအဖြစ် NSX ESG ကိုအသုံးပြုသူများသည်သဘောတူလိမ့်မည်ထင်သည်။ ထိုသို့သောဖြေရှင်းချက်သည် ပို၍တည်ငြိမ်လိမ့်မည်ဖြစ်ကောင်းဖြစ်နိုင်သော်လည်း၊ အရာအားလုံးသည် ရောင်းချသူတစ်ဉီး၏ မူဘောင်အတွင်းတွင် ဖြစ်ပေသည်။

နောက်ထပ်ဖြေရှင်းချက်မှာ VLAN နှင့် VXLAN ကြားတံတားမုဒ်တွင် NSX DLR ကိုအသုံးပြုရန်ဖြစ်သည်။ ဤတွင်အရာအားလုံးကိုရှင်းရှင်းလင်းလင်းထင်ပါတယ် - VXLAN ကိုအသုံးပြုခြင်း၏အကျိုးကျေးဇူးသည်ရိုးရှင်းစွာဆုံးရှုံးသည် - ဤကိစ္စတွင်သင် VLAN ကိုစောင့်ကြည့်တပ်ဆင်ခြင်းနှင့်ချိတ်ဆက်ရန်ကျန်ရှိနေသောကြောင့်ဖြစ်သည်။ စကားမစပ်၊ ဤဖြေရှင်းချက်ကို လုပ်ဆောင်နေစဉ်တွင်၊ DLR တံတားသည် တစ်ခုတည်းသော host ပေါ်တွင်ရှိသော virtual machine သို့ packets များမပို့သောအခါ ပြဿနာတစ်ခုကြုံတွေ့ခဲ့ရသည်။ ငါသိတယ်၊ ငါသိတယ် - NSX-V ဆိုင်ရာစာအုပ်များနှင့်လမ်းညွှန်များတွင် NSX Edge အတွက်သီးခြားအစုအဝေးတစ်ခုကိုခွဲဝေပေးသင့်ကြောင်းတိုက်ရိုက်ဖော်ပြထားသည်၊ သို့သော်၎င်းသည်စာအုပ်များတွင်ဖြစ်သည်... တစ်နည်းမဟုတ်တစ်နည်းအားဖြင့်လအနည်းငယ်ကြာပြီးနောက်၊ ပံ့ပိုးကူညီမှု၊ ပြဿနာကို ကျွန်ုပ်တို့ မဖြေရှင်းနိုင်ခဲ့ပါ။ မူအရ၊ လုပ်ဆောင်ချက်၏ ယုတ္တိကို ကျွန်တော်နားလည်ပါသည် - VXLAN encapsulation အတွက် တာဝန်ရှိသော hypervisor kernel module ကို DLR နှင့် monitored server သည် တူညီသော host တွင်ရှိနေပါက၊ traffic သည် host မှထွက်ခွာမသွားဘဲ၊ ယုတ္တိနည်းအရ ချိတ်ဆက်သင့်သည် VXLAN အပိုင်းသို့ - encapsulation မလိုအပ်ပါ။ ပံ့ပိုးမှုဖြင့်၊ ကျွန်ုပ်တို့သည် uplinks များကို ယုတ္တိရှိရှိ ချိတ်ဆက်ပြီး bridging/encapsulation ကို လုပ်ဆောင်ပေးသော virtual interface vdrPort တွင် အခြေချနေထိုင်ခဲ့သည် - ဤနေရာသည် အဝင်အသွားအလာတွင် ကွဲလွဲမှုကို သတိပြုမိသည်၊၊ လက်ရှိကိစ္စတွင် ကျွန်တော်လုပ်ဆောင်ခဲ့သော၊ ဒါပေမယ့် ကျွန်တော်ပြောခဲ့သလိုပဲ၊ တခြားပရောဂျက်တစ်ခုဆီ ပြောင်းရွှေ့ခံခဲ့ရပြီး ဌာနခွဲဟာ အစပိုင်းမှာ အဆုံးစွန်ဆုံးဖြစ်ခဲ့ပြီး ဖွံ့ဖြိုးတိုးတက်ဖို့ အထူးဆန္ဒမရှိတာကြောင့် ဒီကိစ္စကို မပြီးမြောက်ခဲ့ပါဘူး။ ကျွန်တော် မမှားပါက ပြဿနာကို ဗားရှင်း NSX နှင့် 6.1.4 နှင့် 6.2 တို့တွင် တွေ့ရပါသည်။

ပြီးတော့ - ဘင်ဂို။ Fortinet ၏ဇာတိကိုကြေငြာသည်။ VXLAN ပံ့ပိုးမှု. point-to-point သို့မဟုတ် VXLAN-over-IPSec ဆော့ဖ်ဝဲလ် VLAN-VXLAN ပေါင်းကူးခြင်းမဟုတ်ဘဲ၊ ဤအရာအားလုံးကို ဗားရှင်း 5.4 တွင် စတင်အကောင်အထည်ဖော်ခဲ့သည် (အခြားဘာသာဖြင့် ဖော်ပြထားပါသည်။ ရောင်းချသူများ) ဒါပေမယ့် စစ်မှန်တဲ့ unicast ထိန်းချုပ်မှု လေယာဉ် ပံ့ပိုးမှု။ ဖြေရှင်းချက်ကို အကောင်အထည်ဖော်သည့်အခါတွင်၊ ကျွန်ုပ်သည် အခြားပြဿနာတစ်ခုနှင့် ရင်ဆိုင်ခဲ့ရသည် - virtual machine ကိုယ်တိုင် အသက်ရှင်နေသော်လည်း အချိန်အခါအလိုက် "ပျောက်ကွယ်သွားသော ဆာဗာများကို စစ်ဆေးခြင်း" ထို့နောက် စောင့်ကြည့်ခြင်းတွင် ပေါ်လာသည်။ အကြောင်းရင်းကတော့ VXLAN interface မှာ Ping ကို ဖွင့်ဖို့ မေ့သွားလို့ပါပဲ။ အစုအဝေးများကို ပြန်လည်ချိန်ညှိခြင်းလုပ်ငန်းစဉ်အတွင်း၊ စက်များကို ရွှေ့ပြီး စက်ပြောင်းသွားသည့် ESXI host အသစ်ကို ညွှန်ပြရန်အတွက် vMotion ကို Ping ဖြင့် အပြီးသတ်ခဲ့သည်။ ကျွန်ုပ်၏ မိုက်မဲမှုသည်၊ သို့သော် ဤပြဿနာသည် ထုတ်လုပ်သူမှ ပံ့ပိုးပေးသော ပံ့ပိုးမှုအပေါ် ယုံကြည်မှုကို ပျက်ပြားစေသည် - ဤကိစ္စတွင်၊ Fortinet။ VXLAN နှင့်သက်ဆိုင်သည့်ကိစ္စတိုင်းသည် "မင်းရဲ့ဆက်တင်မှာ VLAN-VXLAN softswitch ဘယ်မှာလဲ" ဆိုတဲ့မေးခွန်းနဲ့ အစပြုတယ်လို့ မပြောပါဘူး။ ဒီတစ်ခါတော့ MTU ကိုပြောင်းဖို့ အကြံပေးခဲ့ပါတယ် - ဒါက 32 bytes ဖြစ်တဲ့ Ping အတွက်ပါ။ ထို့နောက် UDP တွင် ထုပ်ပိုးထားသည့် VXLAN အတွက် မူဝါဒတွင် tcp-send-mss နှင့် tcp-receive-mss တို့ဖြင့် "ပတ်ကစားပါ" ။ တောင်းပန်ပါတယ် - ပွက်ပွက်ဆူနေတယ်။ ယေဘူယျအားဖြင့်တော့ ဒီပြဿနာကို ကျွန်တော်ကိုယ်တိုင် ဖြေရှင်းခဲ့ပါတယ်။

စမ်းသပ်အသွားအလာကို အောင်မြင်စွာ လွှင့်တင်ပြီးနောက်၊ ၎င်းသည် ဤဖြေရှင်းချက်ကို အကောင်အထည်ဖော်ရန် ဆုံးဖြတ်ခဲ့သည်။ ထုတ်လုပ်ရေးတွင် တစ်ရက် သို့မဟုတ် နှစ်ရက်ကြာပြီးနောက် VXLAN မှတစ်ဆင့် စောင့်ကြည့်သည့်အရာအားလုံး တဖြည်းဖြည်း ကျဆင်းသွားကြောင်း တွေ့ရှိရသည်။ အင်တာဖေ့စ်ကို ပိတ်ခြင်း/အသက်သွင်းခြင်းသည် အထောက်အကူဖြစ်သော်လည်း ယာယီသာဖြစ်သည်။ ပံ့ပိုးမှုထုတ်လုပ်ခြင်း၏နှေးကွေးမှုကို သတိပြုမိပြီး ပြဿနာဖြေရှင်းခြင်းစတင်ခဲ့သည် - ပြီးနောက်၊ ကျွန်ုပ်၏ကုမ္ပဏီ၊ ကျွန်ုပ်၏ကွန်ရက်သည် ကျွန်ုပ်၏တာဝန်ဖြစ်သည်။

ပြဿနာဖြေရှင်းခြင်း၏တိုးတက်မှုသည် spoiler အောက်တွင်ရှိသည်။ စာလုံးတွေနဲ့ ကြွားလုံးထုတ်ရတာကို ငြီးငွေ့နေသူတွေအတွက်တော့ အဲဒါကို ကျော်ပြီး ခွဲခြမ်းစိတ်ဖြာမှုနောက်ကို ဆက်သွားလိုက်ပါ။

ပြဿနာဖြေရှင်းခြင်းတိုးတက်မှုဆက်လက်ဖတ်ရှုပေးတဲ့အတွက် ကျေးဇူးပါ - ဆက်ကြရအောင်။

ဒီတော့ စောင့်ကြည့်မှုဟာ အချိန်အတိုင်းအတာတစ်ခုအထိ အလုပ်လုပ်ပြီးတော့ သူ့အလိုလို ပျက်သွားတယ်။ ဆိုလိုသည်မှာ firewall မူဝါဒများနှင့် ပတ်သက်၍ ပြဿနာများ ဖြစ်နိုင်ချေများပါသည်။ သို့သော်လည်း Fortigate ဗားရှင်း 5.6+ တွင် တွဲလောင်းစနစ် လုပ်ငန်းစဉ်များ ပြဿနာကို ကျွန်ုပ်ကြုံတွေ့ရသောကြောင့် ပထမဦးစွာ ကျွန်ုပ်တို့သည် မျှော်လင့်ထားသည့်အတိုင်း "diagnose debug flow" ကိုကြည့်ပါ - မျှော်လင့်ထားသည့်အတိုင်း၊ အသွားအလာကို ခွင့်ပြုပြီး အင်တာဖေ့စ်မှ ထွက်သွားပြီး မျှော်လင့်ထားသည့်အတိုင်း တုံ့ပြန်မှုတစ်စုံတစ်ရာ မရရှိပါ။ အဲဒီတော့ အစုအဝေးကို တူးတယ်။ ကံမကောင်းစွာဖြင့်၊ ၎င်းတို့သည် RFC1918 ဖြစ်သည်ဆိုပါက ကျွန်ုပ်တို့သည် လိပ်စာများကို ဖျောက်ထားရမည်ဖြစ်ပြီး၊ သို့သော် နားလည်မှုအတွက် လုံလောက်သောဖော်ပြချက်ဖြင့် လုပ်ငန်းစဉ်ကို ပေးဆောင်ရန် မျှော်လင့်ပါသည်။ VXLAN အတွင်းရှိဆာဗာတွင် လိပ်စာ x.x.x.15၊ Fortigate အင်တာဖေ့စ် x.x.x.254၊ အခြားလိပ်စာများအားလုံးသည် VTEP ကွန်ရက်နှင့် သက်ဆိုင်ပါသည်။

VXLAN-encapsulated packets များကို အောင်မြင်စွာ ထုတ်လွှင့်ခြင်းသည် ဇယားများစွာရှိ မှန်ကန်သော အချက်အလက် လိုအပ်ပါသည်။ ထပ်ဆင့်များအတွက် ၎င်းတို့မှာ ARP နှင့် OVSDB ဖြစ်ပြီး အောက်ခံအတွက် ၎င်းတို့မှာ ARP နှင့် CAM ဖြစ်သည်။ Fortigate VXLAN FDB တွင် OVSDB ဖြစ်သည်။ အဲဒီမှာ စလိုက်ရအောင်။

 fortigate (root) #diag sys vxlan fdb list vxlan-LS
mac=00:50:56:8f:3f:5a state=0x0002 flags=0x00 remote_ip=у.у.у.47 port=4789 vni=5008 ifindex=7

ဤနေရာတွင် အရာအားလုံးသည် အလွန်ရိုးရှင်းပါသည် - virtual machine ၏ MAC လိပ်စာသည် u.u.u.47 လိပ်စာဖြင့် VTEP ပေါ်တွင် ရှိနေရပါမည်။ ESXI အစုအဝေး၏ အကြောင်းအရာများနှင့် ဆက်တင်များကို ကြည့်ရှုပြီးနောက်၊ virtual machine ၏ MAC သည် မှန်ကန်သည့်အပြင် VTEP လိပ်စာကိုလည်း တွေ့ရှိပါသည်။ fortik ပေါ်ရှိ CAM/ARP ဇယားကို စစ်ဆေးကြည့်ပါ- အရာအားလုံးသည် ESXI လက်ခံဆောင်ရွက်ပေးသည့် ဆက်တင်များနှင့် ကိုက်ညီသည်-

fortigate (root) #get sys arp | grep у.у.у.47
у.у.у.47 0 00:50:56:65:f6:2c dmz

ဇယားများ မှန်ကန်ပြီး ယာဉ်အသွားအလာ ထွက်သွားသည် - Fortigate နှင့် ပြဿနာဖြစ်နိုင်ပါသလား။ Juniper တွင် လမ်းကြောင်းပြောင်းခြင်း၏ ခွဲခြမ်းစိတ်ဖြာမှုကို တမင်တကာ ကျော်သွားသည် - ယုတ္တိနည်းအရ၊ ပြဿနာဖြေရှင်းခြင်း၏ နောက်အဆင့်ကို ၎င်းတွင် လုပ်ဆောင်သင့်သည်၊ သို့သော် ကျွန်ုပ်၏ကွန်ရက်သည် ရိုးရှင်းပါသည် - VTEP အတွက် VLAN တစ်ခုသာဖြစ်ပြီး အစိတ်အပိုင်းအားလုံးကို တိုက်ရိုက်ချိတ်ဆက်ထားသည်။ ထို့အပြင်၊ DLR တံတား၊ VDR နှင့် အသွားအလာ ပျောက်ဆုံးနေသော ဖြစ်ရပ်တစ်ခုကို ကျွန်ုပ် မှတ်မိသည် - ESXI လက်ခံသူအား ရှူရှိုက်မိတော့မည် ဖြစ်ပြီး တစ်ချိန်တည်းမှာပင် VMWare အတွက် အမှုတွဲကို ဖန်တီးနေပါသည်။ အောက်ဖော်ပြပါ MAC "97:6e" သည် fortik မှဖြစ်ပြီး vmnic1 သည် လိပ်စာ u.u.u.47 snifim လမ်းကြောင်းနှစ်ခုစလုံးတွင် "--dir 2" နှင့် VTEP ပါရှိသော မျက်နှာပြင်တစ်ခုဖြစ်သည်။

pktcap-uw --uplink vmnic1 --vni 5008  --mac 90:6c:ac:a9:97:6e --dir 2 -o /tmp/monitor.pcap

တိုးတက်မှု - sniff တွင် ARP တောင်းဆိုချက်တစ်ခုနှင့်ဝင်လာသောတုံ့ပြန်မှုကိုကျွန်ုပ်မြင်ရသည်။ ကျွန်ုပ်သည် ARP တုံ့ပြန်မှုကိုသာ ပေးဆောင်ပြီး အရာအားလုံးသည် ထိုနေရာတွင် မှန်ကန်ပါသည်။ ကျွန်တော် အဲဒါကို မဖော်ပြထားပေမယ့် စောင့်ကြည့်စစ်ဆေးတဲ့ဆာဗာက x.x.x.15 လိပ်စာကို pinging လုပ်နေတဲ့အချိန် - ICMP လမ်းကြောင်းက ဘယ်မှာလဲ။ ကျွန်တော့်မှာ uplink နှစ်ခုရှိတယ်ဆိုတာ မှတ်မိတယ်။ ဤနေရာတွင် သင်သည် အရင်းအမြစ် virtual port သည် အတူတူပင်ဖြစ်သည် (ကျွန်ုပ်၏ အဖွဲ့လိုက်မူဝါဒ)၊ ဆိုလိုသည်မှာ တူညီသော uplink ကို vNIC တစ်ခုတည်းအတွက် ရွေးချယ်သင့်သည်၊ သို့သော် ကျွန်ုပ်သည် host တွင်ရှိနေသောကြောင့်၊ မတူညီသော uplink ကိုစစ်ဆေးခြင်းသည် တစ်ခုမဟုတ်ပေ။ ပြဿနာ-

pktcap-uw --uplink vmnic4 --vni 5008  --mac 90:6c:ac:a9:97:6e --dir 2 -o /tmp/monitor.pcap

တောင်းဆိုမှုများသည် Fortigate မှလာသော်လည်း တုံ့ပြန်ခြင်းမရှိပါ။ ဆိုလိုသည်မှာ၊ ပြဿနာသည် Fortigate တွင်မဟုတ်ပါ။ ကောင်းပြီ၊ ဒါပါပဲ - ငါထင်တယ် - VDR ပေါ်ရှိအသွားအလာပျောက်ဆုံးခြင်းနှင့်တူညီသောပြဿနာတစ်ခုဖြစ်သည်၊ နောက်တဖန်ဖြစ်ရပ်ကိုလမ်းကြောင်းမှန်သို့ညွှန်ပြရန်လအနည်းငယ်ကြာလိမ့်မည်။ ရက်အနည်းငယ်ကြာပြီးနောက် စိတ်အေးသွားကာ ကြိုးဆွဲမချချင်တော့ဘဲ လုပ်ငန်းစဉ်ကို အရှိန်မြှင့်ရန်အတွက် အထောက်အပံ့အတွက် နောက်ထပ် အနံ့အသက်များကို တူးဖော်ရန် ဆုံးဖြတ်ခဲ့သည်။ ထို့နောက် "မတော်တဆ" ကျွန်ုပ်၏အကြည့်သည် Ethernet အောက်ခံဖုံးအုပ်ထားသော ကာဗာပေါ်တွင် ကျရောက်သွားသည်။ Tsar သည် အစစ်အမှန်မဟုတ်ပါ၊ VTEP ၏ MAC လိပ်စာသည် ၎င်း၏ IP နှင့် မကိုက်ညီပါ။ သုညသို့ ပြန်သတ်မှတ်လိုက်သည်၊ စုပ်လိုက်၊ တူးသည်- မှန်သည်၊ မမှန်ပါ။ နှိုင်းယှဉ်ရလွယ်ကူစေရန် ARP ဇယားကို တစ်ခုနှင့်တစ်ခု ဘေးတွင် ပေးပါမည်။ အပေါ်ကပုံမှာပါတဲ့ ပထမဆုံး Ethernet encapsulation ကို သတိပြုပါ။

fortigate (root) #get sys arp | grep у.у.у.47
у.у.у.47 0 00:50:56:65:f6:2c dmz
fortigate (root) #get sys arp | grep у.у.у.42
у.у.у.42 0 00:50:56:6a:78:86 dmz

ထို့ကြောင့်၊ ကျွန်ုပ်တို့နှင့်အဆုံးသတ်သည်မှာ virtual machine ကိုပြောင်းရွှေ့ပြီးနောက်၊ Fortigate (မှန်ကန်သော) VXLAN FDB မှ VTEP သို့အသွားအလာပို့ရန်ကြိုးစားသော်လည်း DST MAC ကိုမှားယွင်းစွာအသုံးပြုပြီး hypervisor interface ကိုလက်ခံရရှိခြင်းဖြင့် traffic ကိုကျဆင်းသွားဖွယ်ရှိသည်။ ထို့အပြင်၊ လေးခုအနက်မှတစ်ခုတွင်၊ ဤ MAC သည် စက်ရွှေ့ပြောင်းမှုစတင်ခဲ့သည့် မူလ hypervisor နှင့် သက်ဆိုင်ပါသည်။

မနေ့က Fortinet နည်းပညာဆိုင်ရာ ပံ့ပိုးကူညီမှုထံမှ စာတစ်စောင် လက်ခံရရှိခဲ့သည် - bug 615586 ကို ကျွန်ုပ်၏ ကိစ္စတွင် ရှာဖွေတွေ့ရှိခဲ့ပါသည်။ ပျော်ရွှင်ခြင်းလား ဝမ်းနည်းခြင်း ရှိမရှိ ငါတကယ်မသိပါ - တစ်ဖက်တွင်၊ ပြဿနာသည် ဆက်တင်များတွင်မဟုတ်ပါ၊ အခြားတစ်ဖက်တွင်၊ ပြုပြင်ရန်၊ Firmware အပ်ဒိတ်တစ်ခုနှင့်သာ လာလိမ့်မည် သို့မဟုတ် အကောင်းဆုံးနောက်တစ်ခု။ ChSV သည် HTML5 GUI vSphere တွင်ရှိသော်လည်း ပြီးခဲ့သည့်လတွင် ကျွန်ုပ်ရှာဖွေတွေ့ရှိခဲ့သော အခြား bug ကြောင့်လည်း ပါဝင်ပါသည်။ စျေးရောင်းသူများ၏ဒေသခံ QA ဌာနသာဖြစ်သည်..။

အောက်ပါအချက်များကို ခန့်မှန်းရန် စွန့်စားလိုပါသည်။

1 - multicast ထိန်းချုပ်မှု လေယာဉ်သည် ဖော်ပြထားသော ပြဿနာကြောင့် ဖြစ်နိုင်ချေ ရှိသည် မဟုတ်ပါ - နောက်ဆုံးတွင်၊ အင်တာဖေ့စ်ကို စာရင်းသွင်းထားသည့် အုပ်စု၏ IP လိပ်စာများမှ VTEP MAC လိပ်စာများကို ရယူပါသည်။

2 - ကွန်ရက်ပရိုဆက်ဆာ (CEF နှင့် အကြမ်းဖျင်းအားဖြင့် ဆင်တူသော) ကွန်ရက်ပရိုဆက်ဆာပေါ်ရှိ ချိတ်ဆက်မှုများတွင် လွှင့်တင်ခြင်းများတွင် ခိုင်လုံသောပြဿနာဖြစ်နိုင်သည် - သင် CPU မှတဆင့် ပက်ကေ့ခ်ျတစ်ခုစီကို ဖြတ်သွားပါက၊ အနည်းဆုံး အမြင်အားဖြင့် မှန်ကန်သော အချက်အလက်ပါရှိသော ဇယားများကို အသုံးပြုပါမည်။ ၎င်းသည် အင်တာဖေ့စ်ကို ပိတ်ရန်/ဖွင့်ရန် သို့မဟုတ် အချိန်အနည်းငယ်စောင့်ဆိုင်းရန် ကူညီပေးသည့်အချက်ဖြင့် ဤယူဆချက်ကို ထောက်ခံပါသည်။

3 - တိကျပြတ်သားသောကျရှုံးမှုကိုဖြစ်စေရန် ဥပမာအားဖြင့် အသင်းအဖွဲ့မူဝါဒကိုပြောင်းလဲခြင်း သို့မဟုတ် LAG မိတ်ဆက်ခြင်းသည် ပြဿနာကိုဖြေရှင်းနိုင်မည်မဟုတ်ပါ၊ အဘယ်ကြောင့်ဆိုသော် အရင်းအမြစ် hypervisor ၏ MAC သည် encapsulated packets များတွင် "ပိတ်မိနေသည်" ကိုတွေ့ရှိရသောကြောင့်ဖြစ်သည်။

ဤအချက်ကြောင့် မကြာသေးမီက ရှာဖွေတွေ့ရှိခဲ့သော အကြောင်းအရာများကို မျှဝေနိုင်ပါသည်။ блогstetfull firewalls နှင့် cached data transfer method များသည် crutches များဖြစ်ကြောင်း ဆောင်းပါးများထဲမှ တစ်ခုက ဖော်ပြခဲ့သည်။ ကောင်းပြီ၊ ဒါကို ပြောဖို့ IT မှာ လုံလောက်တဲ့ အတွေ့အကြုံ မရှိသေးဘူး၊ နောက်ပြီး ဘလော့ဂ် ဆောင်းပါးတွေမှာ ဖော်ပြချက်အားလုံးကို ချက်ချင်း သဘောမတူဘူး။ သို့သော်၊ အိုင်ဗန်၏စကားများတွင် အမှန်တရားအချို့ရှိကြောင်း တစ်စုံတစ်ခုက ပြောပြသည်။

အာရုံစိုက်မှုအတွက် ကျေးဇူးတင်ပါသည်။ အပြုသဘောဆောင်တဲ့ ဝေဖန်မှုတွေကို ကြားရတာ ဝမ်းသာပါတယ်။

source: www.habr.com