🥇 မှ ကူးပြောင်းခြင်း OpenVPN အပေါ် WireGuard ကွန်ရက်များကို L2 ကွန်ရက်တစ်ခုတည်းအဖြစ် ပေါင်းစပ်ရန်

OpenWRT routers များကို gateway အဖြစ်အသုံးပြုသည့် ပထဝီဝင်အစွန်အဖျားတိုက်ခန်းသုံးခုတွင် ကွန်ရက်များပေါင်းစပ်ခြင်းအတွေ့အကြုံကို မျှဝေလိုပါသည်။ L3 နှင့် subnet routing နှင့် L2 အကြား ချိတ်ဆက်မှုဖြင့် ကွန်ရက်များကို ပေါင်းစည်းရန် နည်းလမ်းကို ရွေးချယ်သောအခါ၊ network node များအားလုံးကို တူညီသော subnet တွင်ရှိမည်ဆိုပါက configure လုပ်ရန် ပိုခက်ခဲသော်လည်း ပိုမိုကောင်းမွန်သော အခွင့်အလမ်းများကို ပေးဆောင်သည့် ဒုတိယနည်းလမ်းကို ဦးစားပေးရွေးချယ်ခဲ့ပါသည်။ Wake-on-Lan နှင့် DLNA ဖန်တီးထားသည့် ကွန်ရက်တွင် နည်းပညာများကို ပွင့်လင်းမြင်သာစွာ အသုံးပြုရန် စီစဉ်ထားပါသည်။

အပိုင်း 1- နောက်ခံ

ဤတာဝန်ကို အကောင်အထည်ဖော်ရန် ရွေးချယ်ထားသော ပရိုတိုကောသည် ကနဦးတွင် OpenVPNအကြောင်းမှာ ပထမဦးစွာ၊ ၎င်းသည် ပြဿနာမရှိဘဲ တံတားထဲသို့ ထည့်သွင်းနိုင်သော ရေပိုက်ကိရိယာတစ်ခုကို ဖန်တီးနိုင်သောကြောင့်ဖြစ်ပြီး၊ ဒုတိယအနေဖြင့် OpenVPN ၎င်းသည် TCP ကို ပံ့ပိုးပေးပြီး ၎င်းသည်လည်း အရေးကြီးပါသည်၊ အဘယ်ကြောင့်ဆိုသော် တိုက်ခန်းများတွင် မည်သည့်နေရာတွင်မျှ သီးသန့် IP address မပါရှိသောကြောင့်ဖြစ်သည်။ ကျွန်ုပ်၏ ISP သည် တစ်စုံတစ်ရာကြောင့် ၎င်း၏ကွန်ရက်များမှ ဝင်ရောက်လာသော UDP ချိတ်ဆက်မှုများကို ပိတ်ဆို့ထားသောကြောင့် STUN ကို ကျွန်ုပ်အသုံးမပြုနိုင်ခဲ့ပါ။ TCP သည် VPN server port ကို SSH ကိုအသုံးပြု၍ ငှားရမ်းထားသော VPS သို့ forward လုပ်ရန် ခွင့်ပြုခဲ့သည်။ ဤနည်းလမ်းသည် များပြားသော overhead ကို ဖန်တီးပေးသော်လည်း data များကို double-encrypted လုပ်ထားသောကြောင့် ကျွန်ုပ်၏ private network ထဲသို့ VPS ကို ပေါင်းစပ်လိုခြင်းမရှိပါ၊ အဘယ်ကြောင့်ဆိုသော် third party များက ၎င်းကို ထိန်းချုပ်နိုင်ဖွယ်ရှိသောကြောင့်ဖြစ်သည်။ ထို့ကြောင့် ကျွန်ုပ်၏ home network တွင် ထိုကဲ့သို့သော device တစ်ခုရှိခြင်းသည် အလွန်မလိုလားအပ်သောကြောင့် လုံခြုံရေးအတွက် များပြားသော overhead ကို ပေးဆောင်ရန် ဆုံးဖြတ်ခဲ့သည်။

server ကို ဖြန့်ကျက်ဖို့ စီစဉ်ထားတဲ့ router ရဲ့ port ကို forward လုပ်ဖို့အတွက် sshtunnel program ကို ကျွန်တော်သုံးခဲ့ပါတယ်။ သူ့ရဲ့ configuration အသေးစိတ်ကို ကျွန်တော် မပြောတော့ပါဘူး - တော်တော်လွယ်ပါတယ်။ သူ့ရဲ့ ရည်ရွယ်ချက်က router ကနေ VPS ကို TCP port 1194 ကို forward လုပ်ဖို့ပဲဆိုတာပဲ မှတ်သားထားပါမယ်။ ပြီးတော့ server ကို configure လုပ်လိုက်ပါတယ်။ OpenVPN br-lan bridge နဲ့ ချိတ်ဆက်ထားတဲ့ tap0 device မှာ။ ကျွန်တော့်ရဲ့ laptop ကနေ အသစ်ဖန်တီးထားတဲ့ server ကို ချိတ်ဆက်မှုကို စမ်းသပ်ပြီးတဲ့နောက် port forwarding အိုင်ဒီယာ အလုပ်ဖြစ်တယ်ဆိုတာ ရှင်းရှင်းလင်းလင်း သိလာရပြီး ကျွန်တော့်ရဲ့ laptop ဟာ router ရဲ့ network ရဲ့ ရုပ်ပိုင်းဆိုင်ရာ အစိတ်အပိုင်း မဟုတ်ပေမယ့်လည်း router ရဲ့ member ဖြစ်လာပါတယ်။

ကျန်တာဆိုလို့ IP address တွေ ပဋိပက္ခမဖြစ်အောင် တိုက်ခန်းအမျိုးမျိုးမှာ ဖြန့်ဝေပြီး router တွေကို configure လုပ်ဖို့ပဲရှိတယ်။ OpenVPN-ဖောက်သည်များ။
အောက်ပါ router IP လိပ်စာများနှင့် DHCP ဆာဗာ အပိုင်းအခြားများကို ရွေးချယ်ထားသည်-

192.168.10.1 အကွာအဝေးနှင့်အတူ 192.168.10.2 - 192.168.10.80 ဆာဗာအတွက်
192.168.10.100 အကွာအဝေးနှင့်အတူ 192.168.10.101 - 192.168.10.149 တိုက်ခန်းအမှတ် 2 ရှိ router အတွက်
192.168.10.150 အကွာအဝေးနှင့်အတူ 192.168.10.151 - 192.168.10.199 တိုက်ခန်းအမှတ် 3 ရှိ router အတွက်

ဤလိပ်စာများကို client router များသို့ သတ်မှတ်ပေးရန်လည်း လိုအပ်ခဲ့သည်။ OpenVPN-server ကို ၎င်း၏ configuration တွင် အောက်ပါလိုင်းကိုထည့်ခြင်းဖြင့် ပြုလုပ်ပါ-

ifconfig-pool-persist /etc/openvpn/ipp.txt 0

နှင့် /etc/openvpn/ipp.txt ဖိုင်သို့ အောက်ပါစာကြောင်းများကို ပေါင်းထည့်ပါ။

flat1_id 192.168.10.100
flat2_id 192.168.10.150

flat1_id နှင့် flat2_id တို့သည် ချိတ်ဆက်ရန် လက်မှတ်များ ဖန်တီးသည့်အခါ သတ်မှတ်ထားသော စက်ပစ္စည်းအမည်များဖြစ်သည်- OpenVPN

ထို့နောက် router များကို configure လုပ်ခဲ့သည် OpenVPN- client များ၊ နှစ်ခုလုံးရှိ tap0 devices များကို br-lan bridge တွင် ထည့်သွင်းထားသည်။ ဤအချိန်တွင် network သုံးခုစလုံးသည် တစ်ခုနှင့်တစ်ခု မြင်နိုင်ပြီး တစ်ခုတည်းသော unit အဖြစ် လုပ်ဆောင်နိုင်သောကြောင့် အရာအားလုံး အဆင်ပြေပုံရသည်။ သို့သော်၊ မနှစ်မြို့ဖွယ် အသေးစိတ်အချက်အလက်တစ်ခု ပေါ်ပေါက်လာသည်- တစ်ခါတစ်ရံတွင် devices များသည် မှားယွင်းသော router မှ IP address ကို လက်ခံရရှိမည်ဖြစ်ပြီး နောက်ဆက်တွဲ အကျိုးဆက်များအားလုံးကို ကြုံတွေ့ရလိမ့်မည်။ တစ်စုံတစ်ရာကြောင့်၊ တိုက်ခန်းတစ်ခုရှိ router သည် DHCPDISCOVER ကို အချိန်မီ မတုံ့ပြန်နိုင်ခဲ့ဘဲ device သည် မှားယွင်းသော address ကို လက်ခံရရှိခဲ့သည်။ router တစ်ခုစီရှိ tap0 တွင် ထိုကဲ့သို့သော request များကို filter လုပ်ရန် လိုအပ်ကြောင်း ကျွန်တော် သဘောပေါက်ခဲ့သော်လည်း၊ bridge ၏ အစိတ်အပိုင်းတစ်ခုဖြစ်ပါက iptables များသည် device တစ်ခုနှင့် အလုပ်လုပ်နိုင်မည် မဟုတ်ကြောင်း ထွက်ပေါ်လာခဲ့ပြီး၊ ebtables ကို အသုံးပြုရန် လိုအပ်ခဲ့သည်။ ကံမကောင်းစွာပဲ၊ ကျွန်တော့်ရဲ့ firmware မှာ ၎င်း မပါဝင်တာကြောင့် device တစ်ခုစီအတွက် image များကို ပြန်လည်တည်ဆောက်ခဲ့ရပါတယ်။ ဒီလိုလုပ်ပြီး router တစ်ခုစီရှိ /etc/rc.local တွင် အောက်ပါလိုင်းများကို ထည့်သွင်းပြီးနောက်၊ ပြဿနာကို ဖြေရှင်းပြီးပါပြီ-

ebtables -A INPUT --in-interface tap0 --protocol ipv4 --ip-protocol udp --ip-destination-port 67:68 -j DROP
ebtables -A INPUT --in-interface tap0 --protocol ipv4 --ip-protocol udp --ip-source-port 67:68 -j DROP
ebtables -A FORWARD --out-interface tap0 --protocol ipv4 --ip-protocol udp --ip-destination-port 67:68 -j DROP
ebtables -A FORWARD --out-interface tap0 --protocol ipv4 --ip-protocol udp --ip-source-port 67:68 -j DROP

ဤဖွဲ့စည်းပုံသည် သုံးနှစ်ကြာသည်။

အပိုင်း ၂: သိရှိနားလည်ခြင်း WireGuard

အခုနောက်ပိုင်း အင်တာနက်ပေါ်မှာ ဒီအကြောင်းတွေ ပိုများလာတယ်လို့ ပြောနေကြတာ WireGuard၎င်း၏ configuration ပြုလုပ်ရလွယ်ကူမှု၊ transfer speed မြင့်မားမှု၊ ping နည်းပါးမှုနှင့် နှိုင်းယှဉ်နိုင်သော လုံခြုံရေးတို့ကို ချီးကျူးဂုဏ်ပြုပါသည်။ ၎င်းနှင့်ပတ်သက်သည့် နောက်ထပ်အချက်အလက်များကို ရှာဖွေကြည့်ရာတွင် bridge member သို့မဟုတ် TCP protocol support နှစ်ခုလုံးကို မပံ့ပိုးကြောင်း တွေ့ရှိခဲ့ရပြီး အခြားရွေးချယ်စရာ မရှိကြောင်း ကျွန်ုပ်ယုံကြည်မိခဲ့သည်။ OpenVPN ကျွန်တော့်အတွက် အဲဒါ မရှိသေးပါဘူး။ ဒါကြောင့် သိကျွမ်းဖို့ ရွှေ့ဆိုင်းလိုက်တယ် WireGuard.

ရက်အနည်းငယ်က IT နဲ့ ဆက်စပ်တဲ့ သတင်းတွေဟာ တစ်နည်းနည်းနဲ့ ပျံ့နှံ့သွားခဲ့ပါတယ်။ WireGuard kernel ထဲမှာ နောက်ဆုံးတော့ ထည့်သွင်းသွားပါလိမ့်မယ် Linuxဗားရှင်း ၅.၆ မှစတင်၍ သတင်းဆောင်းပါးများကို အမြဲချီးကျူးခဲ့သည်။ WireGuardကောင်းမွန်တဲ့ အဟောင်းကို အစားထိုးဖို့ နည်းလမ်းတွေကို ရှာဖွေဖို့ ကျွန်တော် နောက်တစ်ကြိမ် နစ်မြုပ်သွားပြန်ပြီ OpenVPNဒီတစ်ခါတော့ ကျွန်တော် ကြုံလိုက်ရတာက ဒီဆောင်းပါး. ၎င်းသည် GRE ကို အသုံးပြု၍ L3 ကျော် Ethernet ဥမင်လိုဏ်ခေါင်းတစ်ခု ဖန်တီးခြင်းအကြောင်း ပြောဆိုထားသည်။ ဒီဆောင်းပါးက ကျွန်တော့်ကို မျှော်လင့်ချက်ပေးတယ်။ UDP ပရိုတိုကောနှင့် မည်သို့လုပ်ဆောင်ရမည်ကို ရှင်းရှင်းလင်းလင်း မသိရသေးပါ။ ရှာဖွေမှုသည် UDP port တစ်ခုသို့ပေးပို့ရန် SSH tunnel နှင့်တွဲဖက်၍ socat ကိုအသုံးပြုခြင်းအကြောင်း ဆောင်းပါးများဆီသို့ ဦးတည်စေခဲ့သည်၊ သို့သော်၊ ဤချဉ်းကပ်မှုသည် တစ်ခုတည်းသောချိတ်ဆက်မှုမုဒ်တွင်သာအလုပ်လုပ်သည်၊ ဆိုလိုသည်မှာ၊ VPN သုံးစွဲသူများစွာ၏အလုပ်မဖြစ်နိုင်သည်ကို သတိပြုမိပါသည်။ VPS တွင် VPN ဆာဗာတစ်ခုတပ်ဆင်ရန်နှင့် client များအတွက် GRE ကိုထည့်သွင်းရန်စိတ်ကူးပေါ်လာသော်လည်း၊ GRE သည် encryption ကိုမပံ့ပိုးပါ၊ ၎င်းသည်တတိယပါတီဆာဗာသို့ဝင်ရောက်ခွင့်ရပါကအချက်ကိုဖြစ်ပေါ်စေလိမ့်မည်။ ကျွန်ုပ်၏ကွန်ရက်များကြားရှိ အသွားအလာအားလုံးသည် ကျွန်ုပ်နှင့် လုံးဝ မလိုက်ဖက်ပါ။

တစ်ဖန်၊ အောက်ပါအစီအစဥ်ကိုအသုံးပြု၍ VPN မှတဆင့် VPN ကိုအသုံးပြုခြင်းဖြင့် မလိုအပ်သော ကုဒ်ဝှက်ခြင်းအတွက် ဆုံးဖြတ်ချက်ကို ချမှတ်ခဲ့ပါသည်။

အဆင့် XNUMX VPN-
VPS ဒါဟာဖြစ်ပါသည် ဆာဗာ အတွင်းလိပ်စာ 192.168.30.1 နှင့်အတူ
MS ဒါဟာဖြစ်ပါသည် ဖောက်သည် အတွင်းလိပ်စာ 192.168.30.2 ပါသော VPS
MK2 ဒါဟာဖြစ်ပါသည် ဖောက်သည် အတွင်းလိပ်စာ 192.168.30.3 ပါသော VPS
MK3 ဒါဟာဖြစ်ပါသည် ဖောက်သည် အတွင်းလိပ်စာ 192.168.30.4 ပါသော VPS

ဒုတိယအဆင့် VPN-
MS ဒါဟာဖြစ်ပါသည် ဆာဗာ ပြင်ပလိပ်စာ 192.168.30.2 နှင့် အတွင်းပိုင်း 192.168.31.1 တို့နှင့်အတူ
MK2 ဒါဟာဖြစ်ပါသည် ဖောက်သည် MS လိပ်စာ 192.168.30.2 နှင့် အတွင်းပိုင်း IP 192.168.31.2 ပါရှိသည်။
MK3 ဒါဟာဖြစ်ပါသည် ဖောက်သည် MS လိပ်စာ 192.168.30.2 နှင့် အတွင်းပိုင်း IP 192.168.31.3 ပါရှိသည်။

* MS — တိုက်ခန်း 1 ရှိ router-ဆာဗာ၊ MK2 - router တိုက်ခန်း ၂ ၊ MK3 - တိုက်ခန်း ၃
* စက်၏ဖွဲ့စည်းပုံများကို ဆောင်းပါး၏အဆုံးတွင် spoiler တွင် ထုတ်ပြန်ထားသည်။

ထို့ကြောင့်၊ pings များသည် network node 192.168.31.0/24 အကြားတွင် လုပ်ဆောင်နေပါသည်၊ GRE ဥမင်လိုဏ်ခေါင်းတစ်ခု သတ်မှတ်ခြင်းသို့ ဆက်သွားရန် အချိန်တန်ပါပြီ။ ၎င်းမတိုင်မီတွင်၊ routers များသို့ဝင်ရောက်ခွင့်ဆုံးရှုံးခြင်းမဖြစ်စေရန်၊ port 22 ကို VPS သို့ပေးပို့ရန် SSH tunnels ကိုတည်ဆောက်ရကျိုးနပ်သည်၊ ထို့ကြောင့် ဥပမာ၊ apartment 10022 မှ router သည် VPS ၏ port 2 တွင်ဝင်ရောက်အသုံးပြုနိုင်မည်ဖြစ်ပြီး၊ တိုက်ခန်း 11122 မှ router သည် တိုက်ခန်း 3 မှ port XNUMX router တွင် ဝင်ရောက်ကြည့်ရှုနိုင်မည်ဖြစ်သည်။ အဆင်မပြေပါက tunnel တစ်ခုတည်းကို အသုံးပြု၍ forwarding ကို configure လုပ်ခြင်းသည် အကောင်းဆုံးဖြစ်သည်။

ဥမင်လိုဏ်ခေါင်းကို စီစဉ်သတ်မှတ်ထားပြီး၊ သင်သည် ထပ်ဆင့်ပို့သည့် ပေါက်မှတစ်ဆင့် SSH သို့ ချိတ်ဆက်နိုင်သည်-

ssh root@МОЙ_VPS -p 10022

နောက်တစ်ခုက disable လုပ်သင့်ပါတယ် OpenVPN:

/etc/init.d/openvpn stop

ယခုတိုက်ခန်း 2 မှ router တွင် GRE ဥမင်လိုဏ်ခေါင်းတစ်ခုကို တည်ဆောက်ကြပါစို့။

ip link add grelan0 type gretap remote 192.168.31.1 local 192.168.31.2
ip link set grelan0 up

တံတားတွင် ဖန်တီးထားသော အင်တာဖေ့စ်ကို ပေါင်းထည့်ပါ။

brctl addif br-lan grelan0

ဆာဗာရောက်တာတွင် အလားတူလုပ်ထုံးလုပ်နည်းတစ်ခုကို လုပ်ဆောင်ကြပါစို့။

ip link add grelan0 type gretap remote 192.168.31.2 local 192.168.31.1
ip link set grelan0 up

တံတားတွင် ဖန်တီးထားသော အင်တာဖေ့စ်ကိုလည်း ထည့်ပါ-

brctl addif br-lan grelan0

ဒီအခိုက်အတန့်ကနေစပြီး pings ဟာ ကွန်ရက်အသစ်ကို အောင်မြင်စွာစတင်ခဲ့ပြီး ကျွန်တော်ကျေနပ်စွာနဲ့ ကော်ဖီသွားသောက်လိုက်ပါ။ ထို့နောက်၊ လိုင်း၏အခြားတစ်ဖက်တွင် ကွန်ရက်အလုပ်လုပ်ပုံကို အကဲဖြတ်ရန်၊ ကျွန်ုပ်သည် တိုက်ခန်း 2 ရှိ ကွန်ပျူတာများထဲမှ SSH သို့ SSH ကို ကြိုးစားသော်လည်း ssh client သည် စကားဝှက်ကိုမတောင်းဆိုဘဲ ရပ်တန့်သွားပါသည်။ port 22 ရှိ telnet မှတဆင့် ဤကွန်ပြူတာသို့ ချိတ်ဆက်ရန် ကြိုးစားနေပါသည်၊ ချိတ်ဆက်မှုကို ထူထောင်ထားကြောင်း နားလည်နိုင်သည့် လိုင်းတစ်ခုကို SSH server မှ တုံ့ပြန်နေသော်လည်း အကြောင်းတစ်ခုခုကြောင့် ၎င်းသည် ကျွန်ုပ်အား လော့ဂ်လုပ်ရန် မတောင်းဆိုပါ။ ၌။

$ telnet 192.168.10.110 22
SSH-2.0-OpenSSH_8.1

VNC မှတစ်ဆင့် ၎င်းနှင့်ချိတ်ဆက်ရန် ကြိုးစားနေပြီး အနက်ရောင်စခရင်ကို မြင်တွေ့ရသည်။ အတွင်းလိပ်စာကို အသုံးပြု၍ ဤတိုက်ခန်းမှ router သို့ အလွယ်တကူ ချိတ်ဆက်နိုင်သောကြောင့် အဝေးထိန်းကွန်ပြူတာတွင် ပြဿနာရှိနေကြောင်း ကိုယ့်ကိုယ်ကိုယ် ယုံကြည့်မိသည်။ သို့သော်လည်း၊ ကျွန်ုပ်သည် router မှတဆင့် ဤကွန်ပြူတာ၏ SSH သို့ ချိတ်ဆက်ရန် ဆုံးဖြတ်လိုက်ပြီး ချိတ်ဆက်မှု အောင်မြင်ကြောင်း တွေ့ရှိရခြင်းမှာ အံ့အားသင့်မိပြီး အဝေးထိန်းကွန်ပြူတာသည် ပုံမှန်အတိုင်း အလုပ်လုပ်သော်လည်း ၎င်းသည် ကျွန်ုပ်၏ကွန်ပျူတာနှင့်လည်း ချိတ်ဆက်၍မရပါ။

ကျွန်တော် grelan0 device ကို bridge ကနေထုတ်ပြီး run လိုက်တယ် OpenVPN အခန်း ၂ မှာရှိတဲ့ router မှာ network က ပြန်ကောင်းလာပြီး connection တွေလည်း ပြတ်တောက်မသွားဘူးဆိုတာ အတည်ပြုခဲ့ပါတယ်။ ရှာကြည့်တော့ လူတွေက အလားတူပြဿနာတွေအကြောင်း ညည်းညူနေကြတဲ့ forum တွေကို တွေ့ခဲ့ရပြီး MTU ကို မြှင့်ဖို့ အကြံပေးထားတဲ့နေရာတွေလည်း တွေ့ခဲ့ပါတယ်။ ပြောပြီးတာနဲ့ လုပ်လိုက်ရပါတယ်။ ဒါပေမယ့် MTU ကို gretap devices တွေအတွက် 7000 အထိ မြင့်အောင် မသတ်မှတ်မချင်း TCP connection တွေ ပြတ်တောက်သွားတာ ဒါမှမဟုတ် transfer speed နိမ့်သွားတာကို ကြုံခဲ့ရပါတယ်။ gretap အတွက် MTU မြင့်တာကြောင့် connection တွေအတွက် MTU မြင့်သွားပါတယ်။ WireGuard ပထမနှင့် ဒုတိယအဆင့်များကို အသီးသီး ၈၀၀၀ နှင့် ၇၅၀၀ သတ်မှတ်ထားသည်။

Apartment 3 မှ router တွင် အလားတူ setup တစ်ခုကို လုပ်ဆောင်ခဲ့ပြီး တစ်ခုတည်းသော ကွာခြားချက်မှာ grelan1 ဟု အမည်ပေးထားသော ဒုတိယ gretap interface ကို server router သို့ ပေါင်းထည့်ခဲ့ခြင်းဖြစ်ပြီး br-lan bridge တွင်လည်း ထည့်သွင်းထားသည်။

အရာအားလုံးက အလုပ်လုပ်နေတယ်။ ယခုတွင် သင်သည် gretap assembly ကို startup တွင်ထည့်နိုင်သည်။ ဒီအတွက်:

ကျွန်ုပ်သည် ဤလိုင်းများကို တိုက်ခန်း 2 ရှိ router တွင် /etc/rc.local တွင် ထားခဲ့ပါသည်။

ip link add grelan0 type gretap remote 192.168.31.1 local 192.168.31.2
ip link set dev grelan0 mtu 7000
ip link set grelan0 up
brctl addif br-lan grelan0

၎င်းကို တိုက်ခန်း 3 ရှိ router ပေါ်ရှိ /etc/rc.local သို့ ထည့်ခဲ့သည်-

ip link add grelan0 type gretap remote 192.168.31.1 local 192.168.31.3
ip link set dev grelan0 mtu 7000
ip link set grelan0 up
brctl addif br-lan grelan0

ဆာဗာ router တွင်-

ip link add grelan0 type gretap remote 192.168.31.2 local 192.168.31.1
ip link set dev grelan0 mtu 7000
ip link set grelan0 up
brctl addif br-lan grelan0

ip link add grelan1 type gretap remote 192.168.31.3 local 192.168.31.1
ip link set dev grelan1 mtu 7000
ip link set grelan1 up
brctl addif br-lan grelan1

client router တွေကို reboot လုပ်ပြီးတဲ့နောက်မှာ ဘာကြောင့်မှန်းမသိတဲ့ server နဲ့ ချိတ်ဆက်မထားတာ တွေ့လိုက်ရတယ်။ သူတို့ရဲ့ SSH နဲ့ ချိတ်ဆက်ပြီးတဲ့နောက် (ကံကောင်းထောက်မစွာပဲ၊ sshtunnel ကို ဒီအတွက် ကျွန်တော် အရင်က configure လုပ်ပြီးသားပါ) ဒါကို တွေ့လိုက်ရတယ်။ WireGuard ဘာကြောင့်မှန်းမသိပေမယ့် endpoint အတွက် route တစ်ခုဖန်တီးပေးပေမယ့် မှားယွင်းနေပါတယ်။ ဥပမာ 192.168.30.2 အတွက် route table က pppoe-wan interface ကနေတစ်ဆင့် route တစ်ခုကို သတ်မှတ်ထားပါတယ်၊ ဆိုလိုတာက အင်တာနက်ကနေတစ်ဆင့်ပါ၊ ဒါပေမယ့် အဲဒီကိုသွားတဲ့ route ကို wg0 interface ကနေတစ်ဆင့် ညွှန်ကြားသင့်ပါတယ်။ ဒီ route ကို ဖျက်ပြီးနောက် connection ကို ပြန်လည်ရရှိပါပြီ။ ဘယ်လို force လုပ်ရမလဲဆိုတဲ့ ညွှန်ကြားချက်တွေကို ဘယ်နေရာမှာမဆို ရှာတွေ့နိုင်ပါသလား။ WireGuard ဒီလမ်းကြောင်းတွေကို ဖန်တီးတာကို ကျွန်တော် ရှောင်လွှဲလို့ မရပါဘူး။ ဒါ့အပြင် ဒါက OpenWRT ရဲ့ အင်္ဂါရပ်တစ်ခုလား ဒါမှမဟုတ် OpenWRT ရဲ့ အင်္ဂါရပ်တစ်ခုလားဆိုတာတောင် ကျွန်တော် နားမလည်ခဲ့ပါဘူး။ WireGuardပြဿနာကို ရှာဖွေဖို့ အချိန်အများကြီး မပေးဘဲ၊ router နှစ်ခုလုံးရဲ့ timer-loop script မှာ ဒီ route ကို ဖျက်ပစ်ဖို့ စာကြောင်းတစ်ကြောင်း ထည့်လိုက်ရုံပါပဲ။

route del 192.168.30.2

တက်ကဉျြးခြုပျ

လုံးဝငြင်းပယ်ခြင်း OpenVPN ကျွန်တော်ကတော့ ဒီလိုမလုပ်ရသေးပါဘူး။ တစ်ခါတလေ လက်တော့ပ် ဒါမှမဟုတ် ဖုန်းကနေ ကွန်ရက်အသစ်တစ်ခုနဲ့ ချိတ်ဆက်ရတာကြောင့်ပါ။ ပြီးတော့ သူတို့မှာ gretap device တစ်ခု တပ်ဆင်ဖို့က ယေဘုယျအားဖြင့် မဖြစ်နိုင်ပါဘူး။ ဒါပေမယ့် ဒီလိုဖြစ်နေပေမယ့်လည်း တိုက်ခန်းတွေကြား data transfer speed မှာ အားသာချက်တစ်ခု ရလာပါတယ်။ ဥပမာ VNC သုံးရတာလည်း အဆင်ပြေပါတယ်။ Ping နည်းနည်းလျော့သွားပေမယ့် ပိုတည်ငြိမ်လာပါတယ်။

အသုံးပြုခြင်း OpenVPN:

[r0ck3r@desktop ~]$ ping -c 20 192.168.10.110
PING 192.168.10.110 (192.168.10.110) 56(84) bytes of data.
64 bytes from 192.168.10.110: icmp_seq=1 ttl=64 time=133 ms
...
64 bytes from 192.168.10.110: icmp_seq=20 ttl=64 time=125 ms

--- 192.168.10.110 ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 19006ms
rtt min/avg/max/mdev = 124.722/126.152/136.907/3.065 ms

အသုံးပြုခြင်း WireGuard:

[r0ck3r@desktop ~]$ ping -c 20 192.168.10.110
PING 192.168.10.110 (192.168.10.110) 56(84) bytes of data.
64 bytes from 192.168.10.110: icmp_seq=1 ttl=64 time=124 ms
...
64 bytes from 192.168.10.110: icmp_seq=20 ttl=64 time=124 ms
--- 192.168.10.110 ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 19003ms
rtt min/avg/max/mdev = 123.954/124.423/126.708/0.675 ms

ခန့်မှန်းခြေအားဖြင့် 61.5 ms ရှိသော VPS သို့ မြင့်မားသော ping ကြောင့် ၎င်းကို ပိုမိုအကျိုးသက်ရောက်သည်။

ဒါပေမယ့် မြန်နှုန်းက သိသိသာသာ မြင့်တက်လာပါတယ်။ ဒါကြောင့် router-server ပါတဲ့ တိုက်ခန်းမှာ ကျွန်တော်မှာ အင်တာနက်ချိတ်ဆက်မှု မြန်နှုန်း 30 Mbps ရှိပြီး တခြားတိုက်ခန်းတွေမှာ 5 Mbps ရှိပါတယ်။ ဒါ့အပြင် အသုံးပြုနေစဉ်အတွင်း OpenVPN iperf ဖတ်ရှုမှုအရ 3,8 Mbps ထက်ပိုသော ကွန်ရက်များအကြား ဒေတာလွှဲပြောင်းမှုအမြန်နှုန်းကို ကျွန်ုပ် မရရှိနိုင်ခဲ့ပါ၊ WireGuard ၎င်းကို 5 Mbit/sec နှုန်းအထိ "တိုးမြှင့်" လိုက်သည်။

configuration များ WireGuard VPS မှာ[Interface] Address = 192.168.30.1/24 ListenPort = 51820 PrivateKey = <ЗАКРЫТЫЙ_КЛЮЧ_ДЛЯ_VPS>

[ရွယ်တူချင်း]
PublicKey = <VPN_1_MS_PUBLIC_KEY>
AllowedIPs = 192.168.30.2/32

[ရွယ်တူချင်း]
PublicKey = <VPN_2_MK2_PUBLIC_KEY>
AllowedIPs = 192.168.30.3/32

[ရွယ်တူချင်း]
PublicKey = <VPN_2_MK3_PUBLIC_KEY>
AllowedIPs = 192.168.30.4/32

configuration များ WireGuard MS မှာ (/etc/config/network မှာ ထည့်ထားပါတယ်)

#VPN первого уровня - клиент
config interface 'wg0'
        option proto 'wireguard'
        list addresses '192.168.30.2/24'
        option private_key 'ЗАКРЫТЫЙ_КЛЮЧ_VPN_1_МС'
        option auto '1'
        option mtu '8000'

config wireguard_wg0
        option public_key 'ОТКРЫТЫЙ_КЛЮЧ_VPN_1_VPS'
        option endpoint_port '51820'
        option route_allowed_ips '1'
        option persistent_keepalive '25'
        list allowed_ips '192.168.30.0/24'
        option endpoint_host 'IP_АДРЕС_VPS'

#VPN второго уровня - сервер
config interface 'wg1'
        option proto 'wireguard'
        option private_key 'ЗАКРЫТЫЙ_КЛЮЧ_VPN_2_МС'
        option listen_port '51821'
        list addresses '192.168.31.1/24'
        option auto '1'
        option mtu '7500'

config wireguard_wg1
        option public_key 'ОТКРЫТЫЙ_КЛЮЧ_VPN_2_МК2'
        list allowed_ips '192.168.31.2'

config wireguard_wg1ip link add grelan0 type gretap remote 192.168.31.1 local 192.168.31.3

        option public_key 'ОТКРЫТЫЙ_КЛЮЧ_VPN_2_МК3'
        list allowed_ips '192.168.31.3'

configuration များ WireGuard MK2 မှာ (/etc/config/network မှာ ထည့်ထားပါတယ်)

#VPN первого уровня - клиент
config interface 'wg0'
        option proto 'wireguard'
        list addresses '192.168.30.3/24'
        option private_key 'ЗАКРЫТЫЙ_КЛЮЧ_VPN_1_МК2'
        option auto '1'
        option mtu '8000'

config wireguard_wg0
        option public_key 'ОТКРЫТЫЙ_КЛЮЧ_VPN_1_VPS'
        option endpoint_port '51820'
        option persistent_keepalive '25'
        list allowed_ips '192.168.30.0/24'
        option endpoint_host 'IP_АДРЕС_VPS'

#VPN второго уровня - клиент
config interface 'wg1'
        option proto 'wireguard'
        option private_key 'ЗАКРЫТЫЙ_КЛЮЧ_VPN_2_МК2'
        list addresses '192.168.31.2/24'
        option auto '1'
        option listen_port '51821'
        option mtu '7500'

config wireguard_wg1
        option public_key 'ОТКРЫТЫЙ_КЛЮЧ_VPN_2_МС'
        option endpoint_host '192.168.30.2'
        option endpoint_port '51821'
        option persistent_keepalive '25'
        list allowed_ips '192.168.31.0/24'

configuration များ WireGuard MK3 မှာ (/etc/config/network မှာ ထည့်ထားပါတယ်)

#VPN первого уровня - клиент
config interface 'wg0'
        option proto 'wireguard'
        list addresses '192.168.30.4/24'
        option private_key 'ЗАКРЫТЫЙ_КЛЮЧ_VPN_1_МК3'
        option auto '1'
        option mtu '8000'

config wireguard_wg0
        option public_key 'ОТКРЫТЫЙ_КЛЮЧ_VPN_1_VPS'
        option endpoint_port '51820'
        option persistent_keepalive '25'
        list allowed_ips '192.168.30.0/24'
        option endpoint_host 'IP_АДРЕС_VPS'

#VPN второго уровня - клиент
config interface 'wg1'
        option proto 'wireguard'
        option private_key 'ЗАКРЫТЫЙ_КЛЮЧ_VPN_2_МК3'
        list addresses '192.168.31.3/24'
        option auto '1'
        option listen_port '51821'
        option mtu '7500'

config wireguard_wg1
        option public_key 'ОТКРЫТЫЙ_КЛЮЧ_VPN_2_МС'
        option endpoint_host '192.168.30.2'
        option endpoint_port '51821'
        option persistent_keepalive '25'
        list allowed_ips '192.168.31.0/24'

ဒုတိယအဆင့် VPN အတွက် ဖော်ပြထားတဲ့ configuration တွေမှာ client တွေကို ကျွန်တော် ညွှန်ပြပေးပါတယ် WireGuard Port 51821။ client က အခမဲ့၊ အခွင့်ထူးမခံထားတဲ့ port ကနေ ချိတ်ဆက်မှုတစ်ခု တည်ဆောက်မှာဖြစ်လို့ ဒါက မလိုအပ်ပါဘူး၊ ဒါပေမယ့် port 51821 ကို ဝင်လာတဲ့ UDP ချိတ်ဆက်မှုတွေကလွဲလို့ router အားလုံးရဲ့ wg0 interface တွေမှာရှိတဲ့ incoming connection အားလုံးကို deny နိုင်အောင် ဒီလိုလုပ်ခဲ့တာပါ။

ဒီဆောင်းပါးလေးက တစ်ယောက်ယောက်အတွက် အသုံးဝင်မယ်လို့ မျှော်လင့်ပါတယ်။

PS ထို့အပြင်၊ ကျွန်ုပ်၏ကွန်ရက်ပေါ်တွင်စက်ပစ္စည်းအသစ်တစ်ခုပေါ်လာသောအခါ WirePusher အပလီကေးရှင်းတွင်ကျွန်ုပ်၏ဖုန်းသို့ PUSH အကြောင်းကြားချက်တစ်ခုပေးပို့သည့်ကျွန်ုပ်၏ script ကိုမျှဝေလိုပါသည်။ ဤသည်မှာ ဇာတ်ညွှန်း၏လင့်ခ်ဖြစ်သည်- github.com/r0ck3r/device_discover.

UPDATE: configuration များ OpenVPN-server များနှင့် client များ

OpenVPN- ဆာဗာ

client-to-client

ca /etc/openvpn/server/ca.crt
cert /etc/openvpn/server/vpn-server.crt
dh /etc/openvpn/server/dh.pem
key /etc/openvpn/server/vpn-server.key

dev tap
ifconfig-pool-persist /etc/openvpn/ipp.txt 0
keepalive 10 60
proto tcp4
server-bridge 192.168.10.1 255.255.255.0 192.168.10.80 192.168.10.254
status /var/log/openvpn-status.log
verb 3
comp-lzo

OpenVPN-ဖောက်သည်

client
tls-client
dev tap
proto tcp
remote VPS_IP 1194 # Change to your router's External IP
resolv-retry infinite
nobind

ca client/ca.crt
cert client/client.crt
key client/client.key
dh client/dh.pem

comp-lzo
persist-tun
persist-key
verb 3

လက်မှတ်များထုတ်ပေးရန် easy-rsa ကိုအသုံးပြုခဲ့သည်။

source: www.habr.com