OpenVPN په GCE کې: د روټونو push کولو دمخه alias IP ورزیات کړئ

push شوی روټ VM د next hop په توګه نه جوړوي. alias IP سلسله ورزیات کړئ، هغه د سرور pool سره برابره کړئ او د کلاینټونو له ازموینې دمخه د VPC د بېرته راستنېدو روټ جوړ کړئ.

کلاینټ په Compute Engine VM کې OpenVPN سرور ته زنګ وهي، د حالت کړکۍ وايي نښلول شوی، او په VPC کې دننه یوه کوربه ته ping لا هم هېڅ چېرته نه رسېږي. instinct وايي چې یو بل push کرښه ورزیات کړئ، او دا هېڅکله ستونزه نه حل کوي. Compute Engine پرېکړه کوي چې packetونه چېرته ځي، د خپلې روټ جدول او هغو پتوو له مخې چې د VM interface واقعاً لري، نو هغه tunnel pool چې VM یې مالک نه دی، هغه pool دی چې هلته هېڅوک نه رسول کوي.

د config فایل پرځای د هغه packet تعقیب کړئ چې ناکامېږي، او ورکې برخې به په ترتیب سره ښکاره شي.

له هغه packet پیل کړئ چې مري

SYN له کلاینټ څخه وځي، tunnel ته ننوځي او VM ته د VPC دننه د یوې منزل لپاره د encapsulated packet په توګه رسېږي. OpenVPN هغه decapsulate کوي او هڅه کوي چې له eth0 څخه یې ولېږي، چېرته چې fabric له هر څه دمخه یوه پوښتنه کوي: ایا دا instance د منزل پتې مالک دی. د بل چا له subnet څخه پرې شوی tunnel pool په دې پوښتنه کې ناکامېږي، او packet د هر روټ یا firewall قاعدې له کتلو دمخه غورځول کېږي.

نو له کلاینټ څخه VPC ته لوري دوه جلا غوښتنې لري، او هېڅ یوه یې push لارښوونه نه ده. VM ته alias سلسله غواړي چې tunnel pool پوښي، او همدا هغه د دې پتوو قانوني مالک جوړوي. VPC ته روټ غواړي چې هر خوندي prefix لپاره VM د next hop په توګه ونومي. یو که ورک شي، packet بل ځای مري، په داسې حال کې چې کلاینټ هماغه چوپتیا ویني.

نیمګړتیا په همدې ترتیب ولولئ، ځکه د کلاینټ له اړخه دواړه شرطونه یو ډول ښکاري. هغه tunnel چې نښلول شوی ښیي خو هېڅ ځواب نه ورکوي، د topology د ستونزې نښه ده، د بد cipher نښه نه ده.

ایا instance د tunnel pool مالک دی

VM ته د هغه په خپل subnet کې دویمه سلسله ورکړئ، بیا OpenVPN ته اجازه ورکړئ چې پتې په سمه توګه له همدې سلسلې ووېشي. په داسې instance چې لومړنی پته یې 10.156.0.10/20 دی، /28 alias pool له هغو پتوو جلا ساتي چې نور instanceونه یې مخکې لري:

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

بیا server لارښوونه باید هماغه بلاک بیان کړي. لومړنی پته یې د tunnel gateway کېږي، او پاتې پتې کلاینټونو ته ورکول کېږي. دلته دوه عددونه یو بلاک بیانوي، یو شبکه او یو netmask، او دا هغه pool نحو دی چې OpenVPN لا هم ورته انتظار لري.

server 10.156.1.0 255.255.255.240

تایید کړئ چې پته واقعاً interface ته رسېدلې ده او نه یوازې د OpenVPN په config کې. fabric هغه څه لېږدوي چې NIC یې راپور ورکوي، نه هغه څه چې daemon یې مني. یو حکم دا فیصله کوي:

ip -4 addr show dev eth0

دویمه پته چې هېڅکله eth0 ته نه رسېږي، یا pool چې له بل subnet سره نښتي، وروسته د وقفې وقفې ضایع په توګه ښکاري، نه د پیل د تېروتنې په توګه. daemon پیلېږي، کلاینټونه نښلېږي، او یوازې ځینې منزلونه بد چلند کوي. alias سلسله کوچنۍ وساتئ ترڅو pool په روټ جدول کې اسانه وپېژندل شي. هېڅکله یې له هغه subnet څخه مه پرې کړئ چې بل instance یې مخکې کاروي.

بېرته راستنېدونکي traffic ته next hop ورکړئ

په VPC کې د کوربه څخه ځواب د tunnel pool کې کلاینټ پتې ته لېږل کېږي، کوم چې د VPC د هېڅ پېژندل شوي subnet برخه نه ده. د دې pool لپاره د روټ پرته ځواب په لومړي هغه 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

هماغه روټ هر هغه prefix ته اړین دی چې د کلاینټ شاته وي، نه د VPC دننه. هغو prefixونو ته د هغه کلاینټ په ccd فایل کې iroute ننوتنه هم غواړي. هغه ننوتنه د سرور اړخ حساب دی: سرور ته وایي چې کوم کلاینټ prefix مالک دی، او په خپل کلاینټ کې هېڅ نه نصبوي.

push لیست د خبرو اترو د کلاینټ اړخ لپاره وساتئ، ځکه یوازې نښلېدونکې ماشین ته روټونه ورزیاتوي. د VPC subnet لپاره push کرښه او pool ته بېرته VPC روټ د یوې لارې دوه نیمایي دي، او هر نیمایي یوازې هغه tunnel جوړوي چې غوښتنې وړي خو ځوابونه نه.

Firewallونه، فارورډنګ او د منځ hops

د VPC firewall decapsulated packet ارزوي، نو ingress قاعده باید tunnel pool او هر هغه site prefix ته اجازه ورکړي چې په دې لار VM ته رسېږي. default-deny چلند دلته په چوپتیا ناکامېږي: packet د decapsulation وروسته غورځول کېږي، او OpenVPN log روغه session ښیي.

په هر هغه Linux کوربه چې فارورډ کوي، نه پای ته رسوي، وګورئ چې net.ipv4.ip_forward فعال دی. د مالکیت قاعده هلته هم تطبیقېږي: هغه ماشین چې د هغه subnet لپاره فارورډ کوي چې نه یې لري، packet هماغسې غورځوي لکه VM به یې غورځولی. د tunnel تورنولو دمخه ارزښت ولولئ.

کله چې په سمه توګه یو prefix ناکام شي

جزوي ناکامي تر ټولو اسانه لوستل کېدونکې قضیه ده، ځکه د لارې هر بل شی مخکې ثابت شوی. د روټ لیست څخه پیل کړئ او د هغې ننوتنې منزل سلسله او next hop ولولئ چې باید prefix پوښي، بیا د 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)

ورک روټ د prefix لپاره د next hop نشتوالی ښیي، خو ورک alias په interface کې غورځول شوی packet ښیي؛ له کلاینټ څخه دواړه یو ډول ښکاري او په دغو دوو outputs کې په بشپړه توګه توپیر لري. که دواړه موجود وي، پاتې شکمن د هغه کلاینټ ccd iroute دی چې prefix ادعا کوي.

څلور ارزښتونه د tunnel ترڅنګ ولیکئ: alias سلسله، سرور pool، push شوي prefixونه، VPC روټونه. زوړ alias د pool هر پته ماتوي، زوړ روټ یو لوری ماتوي، ورک push له کلاینټ څخه prefix پټوي، او غلط iroute prefix ناسم peer ته لېږي. راتلونکی کس چې subnet ورزیاتوي هغه ته څلور واړه په یو ځای کې اړین دي، او دا یادښت له ماښام څخه ارزانه دی.

اړوندې مقالې