MPLS VPN အစားထိုး DMVPN (Dynamic Multipoint VPN)

DMVPN ဟာ NHRP ကိုအခြေခံထားတဲ့ Multipoint GRE၊ IPSec VPN နဲ့Dynamic routing protocols တို့ပေါင်းစပ်ဖွဲ့စည်းထားတဲ့ VPN လို့ဆိုရမှာဖြစ်ပါတယ်။ များသောအားဖြင့် MPLS VPN ရဲ့ Backup အနေနဲ့အသုံးပြုလေ့ရှိပါတယ်။ MPLS မရတဲ့ တစ်ချို့နေရာတွေမှာတော့ DMVPN ကိုပဲ အဓိကအနေနဲ့အသုံးပြုပီး Internet ပေါ်ကနေကိုယ်ပိုင် Private Network များကို တည်ဆောက် ထားလေ့ရှိပါတယ်။ ဒါဆို GRE Tunnel တွေနဲ့ ဘာကွာလဲလို့မေးကြမှာ ဖြစ်ပါတယ် ဒီတော့ သူ့ရဲ့ အလုပ်လုပ်ပုံ ကိုလေ့လာခြင်းအားဖြင့် ဘာကြောင့် အသုံးပြုကြတယ်ဆိုတာ သိလာမှာပါ။

GRE အစွမ်းထက်ပုံကိုသိထားပီဆိုရင် GRE ကိုအသုံးပြူပီး အထက်ကပြောခဲ့တဲ့ လိုအပ်ချက်ကို ရအောင်လုပ်ယူလို့ရပါတယ်၊ ဒါပေမယ့် GRE Tunnel ဟာ Point to point ဖြစ်တဲ့အတွက် ကိုယ့် မှာ ရုံးခွဲ ၁၀ ခုလောက်သာရှိခဲ့မယ်၊ အဲဒီ ရုံးခွဲတွေအားလုံဟာ HQ ရုံးချုပ်ကို ချိတ်ဆက်ဖို့လိုခဲ့မယ်ဆိုရင် HQ မှာ Tunnel ၁၀ ခုဆောက်ရပါမယ်၊ Branch ရုံးခွဲတွေဘက်ကလဲ HQ ကို Tunnel တစ်ခုစီ ဆောက်ရပါမယ်၊ အဲဒီ Tunnel တစ်ခုစီအတွက် IP address အတွဲ ၁၀ ခုလဲလိုမှာပေါ့၊ ဒီအထိ ပြဿနာ မရှိသေးပါဘူး၊ ဒါပေမယ့် နောက်ထပ် ရုံးခွဲ ၁ဝခုထပ်တိုးလာမယ်ဆိုရင်ဖြင့် လိုအပ်လာမည့် Tunnel နဲ့IP address အရေအတွက်တွေ၊ အဲဒါတွေကို Configuration လုပ်ပေးဖို့အတွက်ကို တွေးကြည့်ရင်တော့ သိပ်မလွယ်တော့တာ တွေ့ရမှာပါ၊ ဒါလဲရပါသေးတယ်၊ သေချာစနစ်တကျ စီမံခဲ့မယ်ဆိုရင် အဆင်ပြေနိုင်ပါသေးတယ်။ ပြဿနာက Branch/Spoke အချင်းချင်းဆက်သွယ်ဖို့လိုလာပီ၊ HQ/Hub ကနေအမြဲမသွားပဲ သီးသန့် Spoke to Spoke Tunnel တွေကနေသွားချင်တယ်ဆိုရင်တော့ နာပီပေါ့၊ Branch အခု ၂၀ ကို Full Mesh Tunnel ဆောက်ဖို့အတွက် လိုအပ်မည့် Tunnel နဲ့IP address အရေအတွက်ကို ကြည့်တာနဲ့တင် အတော်ခေါင်းခဲနိုင်တယ်ဆိုတာ သိသာပါတယ်။

ဒီတော့ GRE ကသူ့မှာ နောက်ထပ် Mode တစ်ခုရှိသေးတယ် mGRE (Multipoint mode) ဆိုပီးတော့ ဒီကိစ္စကိုပြေလည်အောင် စီစဉ်ထားပါတယ်၊ အဲဒီမှာလည်း ပုံစံအမျိုးမျိုးနဲ့Hub မှာပဲ mGRE သုံး၊ Spoke တွေမှာတော့ ပုံမှန် GRE ပဲသုံးပေါ့၊ ဒါပေမယ့် Spoke to Spoke Tunnel အတွက်ကတော့ ၂ ဖက်စလုံးမှာ mGRE သုံးမှသာ အဆင်ပြေမှာဖြစ်ပါတယ်၊ mGRE မှာ configuration ပိုင်းအရ ကွာခြားချက်ကတော့ Tunnel Source address ပဲပါတယ်၊ Tunnel Destination ကိုတော့ NHRP(Next Hop Resolution Protocol) သုံးပီး အလိုအလျှောက် ရှာဖွေသွားနိုင်ပါတယ်။ ဒီနေရာမှာ Hub က NHS server အနေနဲ့ရှိပီး ကျန်တဲ့ Spoke တွေက Client တွေအဖြစ် Register လုပ်ရပါတယ်၊ အဲဒီ စာရင်းကို Hub ကမှတ်ထားပီး Spoke တွေကမေးလာရင် ဘယ် Spoke ကိုချိတ်ချင်ရင် ဘယ် IP ကို သုံးပါဆိုပီးတော့ ပြန်ပြောနိုင်တာပေါ့၊ Hub အနေနဲ့လည်း Spoke တစ်ခုချင်းကို Configuration လိုက်လုပ်မနေတော့ပဲ ငါက NHS ဖြစ်တယ်၊ ချိတ်ချင်ရင် ဒီကိုလာ Register လုပ်ဆိုပီး နေယုံပဲ၊ Spoke တွေကတော့ Tunnel Configuration မှာ NHS ဘယ်သူဖြစ်တယ်ဆိုတာ အတိအကျထည့်ပေးရပါတယ်၊ Hub ကပေးထားတဲ့ Network ID နဲ့ Authentication ပိုင်းကိုထည့်ပီးရင်တော့ Client တစ်ခုအနေနဲ့Hub ကို register လုပ်လို့ရပါပီ။ ဒါကြောင့် Show ip nhrp brief ဆိုပီးခေါ် ကြည့်ရင် Hub ဘက်မှာ Spoke အားလုံးကို Dynamic လို့ပြပီး Spoke ဘက်မှာတော့ Hub ကိုချိတ်ထားတဲ့ Tunnel ကို Static လို့ပြထားတာတွေ့ရ ပါလိမ့်မယ်။ ပီးရင်တော့ Dynamic Routing protocol ကို Hub နဲ့ Spoke ကြားမှာ Configure လုပ်ပေးရမှာဖြစ်ပါတယ်၊ ဒီအတွက်တော့ Protocol တစ်ခုချင်းစီအတွက် လိုအပ်ချက်လေးတွေဖြစ်တဲ့ Split-Horizon EIGRP တို့ OSPF Network Type တို့ စတာတွေကို အနည်းငယ် ထပ်ထည့်ပေးရပါလိမ့်မယ်။ (DMVPN အတွက် Routing protocol/ GRE/IPsec စတာတွေကို သိထားပီးသားဖြစ်ရပါမယ်)။ IPsec ကတော့ Tunnel Protection အတွက်သုံးတာဖြစ်ပီး Configuration ကလဲအတူတူပါပဲ၊ တကယ်တော့ IPsec မပါလဲ အလုပ်ဖြစ်ပါတယ်။

Hub နဲ့ Spoke ကြားမှာ Dynamic Routing ရပီဆို Spoke to Spoke စမ်းကြည့်လို့ရပါပီ။ ဥပမာ Spoke A ဟာ Spoke B ရဲ့ Route တစ်ခုကို Hub ကနေတဆင့် သိထားပါတယ်၊ Spoke A နေ အဲဒီ Route ကို PING ကြည့်လိုက်ရင် Hub က Spoke B ရဲ့ IP address ကိုပေးလိုက်ပါတယ်၊ ဒီမှာ Spoke A ကနေ Spoke B ကို Dynamic Tunnel ဆောက်သွားပီး သူတို့အချင်းချင်းတိုက်ရိုက် ချိတ်ဆက်ပီးပြောပါတော့တယ်၊ Hub ကနေဖြတ်သွားစရာ မလိုတော့ဘူးပေါ့၊ အဲဒီအချိန်မှာ Spoke ကနေ Show ip nhrp brief ဆိုပီးခေါ် ကြည့်လိုက်ရင် Hub ကိုချိတ်ထားတဲ့ Tunnel အပြင် Spoke B ကိုချိတ်ထားတဲ့ Tunnel နောက်ထပ်တစ်ခုကိုပါ တွေ့ရမှာ ဖြစ်ပါတယ်။ Tunnel mode ဟာ Dynamic လို့ပြနေတာသတိထားမိပါလိမ့်မယ်။ Traffic မရှိတော့ရင်လည်း သတ်မှတ်တဲ့ အချိန်ကျော်သွားရင် သူ့အ လိုလို Tunnel ကိုပြန်ပီးဖြုတ်ချပေးပါတယ်။ ဒီတော့မလိုအပ်ပဲ Router ပေါ်မှာ resource တစ်ခုအနေနဲ့ရှိမနေတော့ဘူးပေါ့၊ Lab အတွက်စမ်းသပ်ရုံသပ်သပ်ဆို တခြားအသေးစိတ်တွေမလိုပါဘူး ဒါပေမယ့် လုပ်ငန်းခွင်မှာသုံးရင် Tunnel Interface မှာ NHRP holdtime တို့၊ NHRP registration timeout တို့ကို Cisco recommendation အရ အနည်းငယ်ပြောင်းပေးရပါလိမ့်မယ်။ အကယ်၍ Spoke အသစ်တခုတိုးလာရင်လဲ Hub မှာဘာမှလုပ်စရာမလိုပဲ Spoke ဖက်ကနေ အတိအကျ Configure လုပ်ပေးလိုက်တာနဲ့ Client တစ်ခုအနေနဲ့ ပါဝင်ပက်သက်လို့ရသွားပါပီ၊ ဒီတော့ Admin ရဲ့အားစိုက်ထုတ်မှုဟာလဲသိသာစွာနည်းသွားတာကို တွေ့ရမှာပါ။

အထက်ကပြောခဲ့တာတွေပိုပီးမြင်သာသွားအောင် ဒီ ရလဒ်အချို့ကနေကြည့်ကြရအောင်၊ သေချာပိုပီးနားလည်ချင်ရင် Lab လုပ်တဲ့အခါမှာ Debug ကိုအသုံးပြုပီး ကြည့်ကြရင်တော့အကောင်းဆုံးပေါ့။

Hub ကနေမြင်ရတဲ့ NHRP အခြေအနေ၊ NBMA IP က Router တွေရဲ့ ISP ကိုချိတ်ထားတဲ့ IP ပါ၊ Mode ကို Dynamic ဆိုပီးတွေ့မှပါ

Hub#sh ip nhrp brief
Target             Via                  NBMA              Mode Intfc Claimed
192.168.1.3/32 192.168.1.3 100.100.111.2 dynamic Tu0 < >
192.168.1.4/32 192.168.1.4 200.100.111.2 dynamic Tu0 < >
192.168.1.5/32 192.168.1.5 200.100.100.2 dynamic Tu0 < >
SpokeA ကနေ တခြား Spoke တွေကို Dynamic Tunnel ဆောက်ပီး တွေ့ရတဲ့အချိန်၊ Hub ကိုချိတ်ထားတဲ့ Tunnel Mode ကို Static ဆိုပီးတော့ သတိထားမိပါလိမ့်မယ်၊

SpokeA#sh ip nhrp brief
Target                Via               NBMA            Mode Intfc Claimed
192.168.1.1/32 192.168.1.1 100.100.100.2 static Tu0 < >
192.168.1.4/32 192.168.1.4 200.100.111.2 dynamic Tu0 < >
192.168.1.5/32 192.168.1.5 200.100.100.2 dynamic Tu0 < >
Hub ကနေမြင်ရတဲ့ NHRP registration တစ်ခုပါ၊

NHRP: Receive Registration Request via Tunnel0 vrf 0, packet size: 68
NHRP: Send Registration Reply via Tunnel0 vrf 0, packet size: 88

ဒါကတော့ Spoke တစ်ခုကနေနောက်တစ်ခုကိုသွားဖို့အတွက် NHS ကိုလှမ်းပို့တဲ့အချိန်ပေါ့၊ ပီးတော့ Dynamic Tunnel အတွက် IP မေး၊ Hub ကနေ Resolution ပြန်ရတဲ့အချိန်မှာ တခြားဖက်က Tunnel ကိုသိသွားတဲ့အချိန်

NHRP: Checking for delayed event 0.0.0.0/192.168.1.3 on list (Tunnel0).
NHRP: No node found.
NHRP: Sending packet to NHS 192.168.1.1 on Tunnel0
NHRP: Send Resolution Request via Tunnel0 vrf 0, packet size: 68
src: 192.168.1.5, dst: 192.168.1.3


NHRP: Receive Resolution Reply via Tunnel0 vrf 0, packet size: 96
NHRP: No need to delay processing of resolution event nbma src:200.100.100.2 nbma dst:100.100.111.2
အခုလောက်ဆို ဆက်ပီးလေ့လာဖို့အတွက်လုံလောက်ပီလို့ထင်ရတာပဲ၊ Cisco ရဲ့ DMVPN Design and implementation guide ကတော့အကောင်းဆုံးပဲ ဒါပေမယ့် ဒီလင့်ကပိုပီးရှင်းမယ်ထင်တယ်၊ Configuration အတွက်လဲ ပြည့်စုံပါတယ်။


http://www.cisco.com/c/en/us/support/docs/security-vpn/ipsec-negotiation-ike-protocols/29240-dcmvpn.html

ကိုဖြိုး

အရေးပေါ်လမ်းကြောင်း ဖောက်ပေးမဲ့ GRE (Generic Routing Encapsulation)

Enterprise အများစုဟာ သူတို့ရဲ့Private Network တွေကို Service Provider တွေကနေ MPLS/ VPLS/IPLC တွေကို ဈေးကြီးကြီးနဲ့ ငှားရမ်းပီး တစ်ရုံးနဲ့တစ်ရုံးချိတ်ဆက်ထားလေ့ရှိပါတယ်၊သူတို့ရဲ့ Internal application/ IntraNet ကို အဲဒီ Priviate Network ပေါ်ကနေအသုံးပြုကြပါတယ်၊

တစ်ချို့တွေဆို အရေးကြီးတဲ့နေရာတွေမှာ Circuit နှစ်ခုလောက်သုံးလေ့ရှိပါတယ်၊တစ်ချို့ကတော့ ပိုပီးသေချာအောင် Provider နှစ်ခုကနေ MPLS/VPLS Network/Ring နှစ်ခုဖန်တီးထားပီး Load Sharing/ Failover အနေနဲ့သုံးတာလဲရှိပါတယ်။ ပြဿနာက အဲဒီ Provider တွေရဲ့Core Network ဟာဘယ်လောက်ပဲကောင်းကောင်း နိုင်ငံတကာကိုချိတ်ဆက်ဖို့ရာအတွက် အဲဒီနိုင်ငံတွေရဲ့ Local Provider ကိုပြန်ပီး အသုံးပြုရတော့ သူတို့မကောင်းရင် Main Provider တွေကိုလဲထိခိုက်တာပါပဲ။ Customer network တစ်ခုမှာ ခုနကပြောသလို Provider နှစ်ခုကနေ VPLS Network တစ်ခုစီယူထားပီး Local provider ကိုလဲနှစ်ခုမတူအောင် Main proivder တွေကို သေချုာမှာထားပါတယ်၊ ဒီတော့ အတော်စိတ်ချရတယ်လို့ပြောလို့ရပါတယ်၊ ကိုယ်က Customer ဆိုရင်ဒါတွေဟာထည့်ပီးစဉ်းစား ထားရမယ့် အချက်တွေဖြစ်ပါတယ်၊

ဖြစ်ချင်တော့ မနှစ်က China က မြို့တမြို့မှာ Data Center တစ်ခုမီးလောင်ပါရော၊ Local provider နှစ်ခုရဲ့ Network Exchange နှစ်ခုလုံးဟာ အဲဒီ DataCenter မှာသွားဆုံပါတယ်၊ ဒီတော့ Network နှစ်ခုလုံး ထိတော့တာပေါ့၊ အဲဒီ Site ဟာလဲ သူတို့ရဲ့ Private Network ကိုဘယ်လိုမှချိတ်ဆက်လို့ မရတော့ပါဘူး၊ ကျွန်တော်တို့အဖွဲ့ကို Priority 1 Incident အနေနဲ့ရောက်လာပါတယ်၊ ကံကောင်းချင်တော့ အဲဒီ Site မှာ တစ်ခြား Provider တစ်ခုကနေယူထားတဲ့ Internet link တစ်ခုကတက်နေသေးတာတွေ့ရပါတယ်၊ ဒီတော့ အဲဒီအခွင့်အရေးကို အသုံးပြုပီး တစ်ခြား Site တစ်ခုနဲ့ Internet link ပေါ်ကနေ GRE Tunnel တစ်ခုဆောက်ပီး Routing run ပေးလိုက်ပါတယ်။ နာရီဝက်အတွင်းမှာ အဲဒီ Site ဟာ တစ်ခြား Site တွေနဲ့ပြန်ပီးချိတ်ဆက်လို့ရသွားပါတယ်။ Tunnel Configuration ဟာသိပ်မခက်ပေမယ့် ကျန်တဲ့ Site တွေအားလုံးကိုရောက်ဖို့ Routing ပိုင်းကတော့ အတော်လက်ဝင်တာပေါ့၊ ကြီးကြီးမားမား ကိစ္စတစ်ခုမဟုတ်ပေမယ့် သူတို့အရေးပေါ်အခ်ျိန်မှာ အချိန်တိုအတွင်း ပြန်လည်အသုံးပြုလို့ရသွားတဲ့အတွက် ကိုယ်လည်းနာမည်ကောင်းရသွားပါတယ်၊ ငွေကြေးအဖွဲ့အစည်းဖြစ်တဲ့ အတွက် သူတို့ အဆိုအရဒေါ်လာ ထောင်၊သောင်းချီတဲ့ ဆုံးရှုံးမှုမျိုးကို မကြုံလိုက်ရတော့ဘူးပေါ့၊ GRE ရဲ့အရေးပါ၊ အသုံးဝင်ပုံကိုလဲ အခုလိုအချိန်မှာပိုပီး ပေါ်လွင်သွားတာပေါ့။

မေးစရာတစ်ခုက IPSec VPN ဆိုရင်ကောမရဘူးလား။ အတိုင်းအတာတစ်ခုအထိတော့ရနိုင်ပါတယ်၊ ဒါပေမယ့် အခုလိုအနေအထားမျိုးမှာ Dynamic Routing သုံးဖို့အတွက် GRE ဟာအသင့်အတော်ဆုံးဖြစ်ပါတယ်၊ IPsec လို Interesting traffic တွေသတ်မှတ်၊ Static routes တွေရေးနေဖို့အချိန်မရပါဘူး၊ ဒါဟာ GRE ရဲ့ Multicast ကို support လုပ်တဲ့ အဓိကအားသာချက်လည်းဖြစ်ပါတယ်၊ အဲဒီ Site တွေရဲ့တစ်ဖက်စီမှာ IPv6 Network တွေသာ ရှိခဲ့မယ်ဆို GRE ရဲ့အသုံးတဲ့ပုံကို လာနှိုင်းဖို့ကိုလိုမယ်မထင်ပါ။ တစ်ဖက်ကလဲ GRE ဟာ Encapsulation သက်သက်ပဲ Security အပိုင်းအရ အားနည်းချက်ရှိတယ်လိုဆိုနိုင်ပါတယ်။ ဒီအတွက်တော့ GRE ဟာ IPsec နဲ့ပူးပေါင်းပီး လုပ်ဆောင်နိုင်တဲ့အတွက် ပြဿနာ မရှိပါဘူး၊ ဒါကိုတော့ GRE over IPSec လို့ခေါ်ပါတယ်။ Router တစ်လုံးထဲမှာ အတူသုံးသုံး၊ တစ်ခြား Router မှာ ခွဲပီးလို့ပဲသုံးသုံး၊ ဒါမှမဟုတ်ရင် Firewall IPsec အနောက်မှာပဲထားပီးသုံးချင်သုံး အကုန်အဆင်ပြေပါတယ်။ Internet ပေါ်က Tunnel တွေမှာ GRE over IPsec ကိုပဲသုံးလေ့ရှိပါတယ်။ အတွင်း Private Network/ WAN တွေမှာတော့ IPsec မသုံးလဲရပါတယ်။ နောက်ထပ်မေးစရာတစ်ခုထပ်ပေါ်လာမှာက ဘာကြောင့် Local LAN/WAN တွေမှာ GRE သုံးတာလဲ၊ လိုလို့လားဆိုရင် လိုပါတယ်၊ ဥပမာ Corporate Network ထဲမှာ အပြင်လူတွေအတွက် Guest Network ပေးချင်ရင် VLAN ခွဲသုံးတာထက် GRE ပါရောသုံးရင် Administration အရပိုပီးသက်သာတာပေါ့၊ နောက်တစ်ခုအနေနဲ့ဆိုရင် လက်ရှိ Network မှာသုံးနေတဲ့ Routing protocol ကိုမသုံးချင်လို့လိုအပ် ချက်အရ Site အချင်းချင်းရဲ့အတွင်းက Network Segment တွေကို GRE နဲ့ပိုပီးနီးစပ်တဲ့ Network တွေအဖြစ် မြင်စေချင်တာမျိုး၊ စတာတွေမှာအသုံးပြုနိုင်လိုသလို Admin ရဲ့ Design အမြင်အရလိုရင်လိုသလို အသုံးပြုနိုင်ပါတယ်။

Configuration ပိုင်းအရပြောရရင်တော့ အဓိက က Tunnel source/Destination IP တွေဟာ တစ်ဖက်နဲ့တစ်ဖက် Reachability ရှိရပါမယ်၊ အရေးကြီးတာက အဲဒီ IP တွေကို Tunnel ကရလာမယ့် Route ထဲမှာ မပါဖို့လိုပါတယ်၊ Tunnel destination IP ကို Tunnel Interface ကနေပြန်သွားရင် Tunnel flapping ဖြစ်ပီးပြဿနာတက်နိုင်ပါတယ်၊ ဒါကို GRE Tunnel Recursive Routing လို့ခေါ်ပါတယ်။ နောက်တစ်ခုက MTU ပြဿနာမဖြစ်အောင် MTU နဲ့MSS ပြောင်းပီးထည့်ပေးရပါတယ်၊ Tunnel Interface IP နှစ်ခု Reachability ရသွားပီ၊ Tunnel Interface up သွားပီဆိုရင်တော့ ကျန်တာက Routing ပိုင်းပဲရှိပါတယ်။

စိတ်ဝင်စားသူများအတွက်

http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/interface/configuration/15-mt/ir-15-mt-book/ir-impl-tun.html#GUID-BDADC8EF-90C1-4F2A-9899-33DE36D823CB

http://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/WAN_and_MAN/P2P_GRE_IPSec/P2P_GRE_IPSec/2_p2pGRE_Phase2.html

ကိုဖြိုး