GCE හි OpenVPN: routes push කිරීමට පෙර alias IP එකක් එකතු කරන්න

push කළ route එකක් VM එක next hop බවට පත් නොකරයි. alias IP පරාසය එකතු කර, එය සේවාදායකයේ pool සමඟ ගලපා, සේවාදායකයන් පරීක්ෂා කිරීමට පෙර VPC හි ආපසු route එක සාදන්න.

සේවාදායකයෙක් Compute Engine VM එකක OpenVPN සේවාදායකයට ඇමතුම් ගනී, තත්ත්ව කවුළුව සම්බන්ධයි යැයි කියයි, නමුත් VPC තුළ ඇති host එකකට ping තවමත් කොහේවත් ලඟා නොවේ. සහජ ප්‍රවණතාවය තවත් push පේළියක් එකතු කිරීමයි, එයින් කිසිදා නිරාකරණය නොවේ. Compute Engine තමන්ගේම route වගුව සහ VM අතුරුමුහුණත සැබවින්ම රඳවා ගන්නා ලිපින මත පදනම්ව packet කොහේ යයිද තීරණය කරයි, එබැවින් VM සතු නොවන tunnel pool යනු කිසිවෙකු ලඟා නොවන pool එකකි.

වින්‍යාස ගොනුව වෙනුවට අසාර්ථක වන packet එක හඹා යන්න, නැති වූ කොටස් පිළිවෙළින් දිස්වේ.

මිය යන packet එකෙන් පටන් ගන්න

SYN සේවාදායකයාගෙන් පිටවී tunnel එකට ඇතුළු වී VPC තුළ ගමනාන්තයක් සඳහා encapsulated packet එකක් ලෙස VM වෙත ළඟා වේ. OpenVPN එය decapsulate කර eth0 හරහා යැවීමට උත්සාහ කරයි, එහිදී fabric සියල්ලට පෙර එක් ප්‍රශ්නයක් අසයි: මෙම instance එක ගමනාන්ත ලිපිනයට හිමිකම් කියයිද. වෙනත් අයෙකුගේ subnet එකකින් කැපූ tunnel pool එක එම ප්‍රශ්නයට අසමත් වන අතර, කිසිදු route එකක් හෝ firewall නියමයක් බැලීමට පෙර packet එක ඉවත දමනු ලැබේ.

එබැවින් සේවාදායකයාගේ සිට VPC දක්වා දිශාවට වෙන වෙනම අවශ්‍යතා දෙකක් ඇත, ඉන් එකක්වත් push උපදෙසක් නොවේ. VM එකට tunnel pool ආවරණය කරන alias පරාසයක් අවශ්‍ය වන අතර, එයම එය එම ලිපිනවල නීත්‍යානුකූල හිමිකරු බවට පත් කරයි. VPC එකට එක් එක් ආරක්ෂිත prefix සඳහා VM එක next hop ලෙස නම් කරන route එකක් අවශ්‍යය. එකක් හෝ නැති වුවහොත් packet එක වෙනත් තැනක මිය යයි, නමුත් සේවාදායකයා එම නිහඬතාවයම දකී.

අසාර්ථකත්වය එම අනුපිළිවෙළින් කියවන්න, මන්ද සේවාදායක පැත්තෙන් කොන්දේසි දෙකම එකම ලෙස පෙනේ. කිසිවක් පිළිතුරු නොදෙන විට සම්බන්ධයි යැයි වාර්තා කරන tunnel එක topology ගැටලුවක සලකුණකි, නරක cipher එකක සලකුණක් නොවේ.

instance එක tunnel pool එකට හිමිකම් කියයිද

VM එකට තමන්ගේම subnet තුළ ද්විතීයික පරාසයක් දෙන්න, පසුව OpenVPN ලිපින හරියටම එම පරාසයෙන් බෙදාහරින්න. ප්‍රාථමික ලිපිනය 10.156.0.10/20 වන instance එකක, /28 alias එක pool එක අනෙක් instance සතුව දැනටමත් ඇති ලිපිනවලින් වෙන් කරයි:

gcloud compute instances network-interfaces update openvpn-vm \
  --zone=europe-west1-b \
  --aliases=eth0:10.156.1.0/28

ඉන්පසු server උපදෙස එම block එකම විස්තර කළ යුතුය. එහි පළමු ලිපිනය tunnel gateway එක බවට පත් වන අතර ඉතිරි ලිපින සේවාදායකයන්ට දෙනු ලැබේ. මෙහි අංක දෙකක් එක් block එකක් විස්තර කරයි, ජාලයක් සහ netmask එකක්, එය OpenVPN තවමත් බලාපොරොත්තු වන pool වාක්‍ය ඛණ්ඩයයි.

server 10.156.1.0 255.255.255.240

ලිපිනය සැබවින්ම අතුරුමුහුණතට පැමිණ ඇත්දැයි තහවුරු කරන්න, OpenVPN වින්‍යාසයේ පමණක් නොව. fabric යැවෙන්නේ NIC වාර්තා කරන දේය, daemon විශ්වාස කරන දේ නොවේ. එක් විධානයක් එය තීරණය කරයි:

ip -4 addr show dev eth0

කිසිදා eth0 වෙත නොළඟා වන ද්විතීයික ලිපිනයක්, නැතහොත් තවත් subnet එකක් සමඟ අතිච්ඡාදනය වන pool එකක්, පසුව ආරම්භක දෝෂයක් ලෙස නොව කඩින් කඩ packet නැතිවීමක් ලෙස දිස්වේ. daemon ආරම්භ වේ, සේවාදායකයන් සම්බන්ධ වේ, සහ සමහර ගමනාන්ත පමණක් වැරදි ලෙස හැසිරේ. route වගුවේ pool එක පහසුවෙන් හඳුනා ගැනීමට alias පරාසය කුඩාවට තබන්න. වෙනත් instance එකක් දැනටමත් භාවිතා කරන subnet එකකින් එය කිසිදා කපා නොගන්න.

ආපසු traffic එකට next hop එකක් දෙන්න

VPC හි host එකකින් එන පිළිතුරක් tunnel pool හි සේවාදායක ලිපිනයකට යවනු ලැබේ, එය VPC දන්නා කිසිදු subnet එකකට අයත් නොවේ. එම pool එකට route එකක් නොමැතිව පිළිතුර ගැළපීමක් නොමැති පළමු hop එකේ නතර වේ, ඉල්ලීම අනෙක් කෙළවරේ සාර්ථක වී තිබිය හැක.

gcloud compute routes create openvpn-return \
  --network=prod-vpc \
  --destination-range=192.168.127.0/24 \
  --next-hop-instance=openvpn-vm \
  --next-hop-instance-zone=europe-west1-b \
  --priority=800

එම route එකම VPC තුළ නොව සේවාදායකයා පිටුපස පිහිටන ඕනෑම prefix එකකට අවශ්‍යය. එම prefix සඳහා එම සේවාදායකයාගේ ccd ගොනුවේ iroute සටහනක්ද අවශ්‍යය. එම සටහන සේවාදායක පැත්තේ ගිණුම්කරණයකි: එය සේවාදායකයට කියන්නේ කුමන සේවාදායකයා prefix එකට හිමිකම් කියයිද යන්නය, එය සේවාදායකයා මතම කිසිවක් ස්ථාපනය නොකරයි.

push ලැයිස්තුව සංවාදයේ සේවාදායක පැත්ත සඳහා තබා ගන්න, මන්ද එය සම්බන්ධ වන යන්ත්‍රයට පමණක් route එකතු කරයි. VPC subnet එකක් සඳහා push පේළියක් සහ pool වෙත ආපසු VPC route එකක් එකම මාර්ගයේ අර්ධ දෙකකි, ඕනෑම අර්ධයක් තනිව ඉල්ලීම් ගෙන යන නමුත් පිළිතුරු නොගෙන යන tunnel එකක් නිපදවයි.

Firewall, forwarding සහ මැද ඇති hop

VPC හි firewall decapsulated packet එක ඇගයේ, එබැවින් ingress නියමයක් tunnel pool එකට සහ එම මාර්ගයෙන් VM වෙත ළඟා වන ඕනෑම site prefix එකකට අවසර දිය යුතුය. default-deny ආකලනය මෙහි නිහඬව අසමත් වේ: decapsulation ට පසු packet එක ඉවත දමනු ලැබේ, OpenVPN ලොගය සුවපත් session එකක් පෙන්වයි.

terminate නොකර forward කරන ඕනෑම Linux host එකක net.ipv4.ip_forward සක්‍රීයදැයි පරීක්ෂා කරන්න. හිමිකාරිත්ව නියමය එහිද අදාළ වේ: තමන් සතු නොවන subnet එකක් සඳහා forward කරන යන්ත්‍රය VM මෙන්ම packet එක ඉවත දමයි. tunnel එකට දොස් කීමට පෙර අගය කියවන්න.

හරියටම එක් prefix එකක් අසමත් වන විට

අර්ධ අසාර්ථකත්වය කියවීමට පහසුම අවස්ථාවය, මන්ද මාර්ගයේ අනෙක් සියල්ල දැනටමත් ඔප්පු වී ඇත. route ලැයිස්තුවෙන් පටන් ගෙන prefix එක ආවරණය කළ යුතු සටහනේ ගමනාන්ත පරාසය සහ next hop එක කියවන්න, පසුව instance විස්තරය කියවා එහි alias පරාසය සේවාදායකය බෙදාහරින pool එක සමඟ සසඳන්න.

gcloud compute routes list --filter=destination-range~10.164.0.0
 gcloud compute instances describe openvpn-vm --format=get(networkInterfaces[0].aliasIpRanges)

නැති route එක prefix එකට next hop නොමැති ලෙස පෙනේ, නමුත් නැති alias එක අතුරුමුහුණතේ ඉවත දැමූ packet එකක් ලෙස පෙනේ; සේවාදායකයාගෙන් එම දෙක සමාන ලෙස පෙනේ, එම ප්‍රතිදාන දෙකෙහි ඒවා සම්පූර්ණයෙන්ම වෙනස්ය. දෙකම තිබේ නම්, ඉතිරි සැකකරු prefix එකට හිමිකම් කියන සේවාදායකයාගේ ccd iroute එකයි.

අගයන් හතර tunnel එක අසල ලියන්න: alias පරාසය, සේවාදායකයේ pool, push කළ prefix, VPC route. පැරණි alias එක pool හි සෑම ලිපිනයක්ම බිඳ දමයි, පැරණි route එක එක් දිශාවක් බිඳ දමයි, නැති push එක prefix එක සේවාදායකයාගෙන් සඟවයි, වැරදි iroute එක prefix එක වැරදි peer එකට යවයි. ඊළඟට subnet එකක් එකතු කරන පුද්ගලයාට හතරම එක තැනක අවශ්‍යය, එම සටහන සවසට වඩා ලාභදායකය.

අදාළ ලිපි