UDR په Azure کې تر VPN ګیټ وی: یوه منزل، نه ټول وتل

تاسو د یو بهرني پری فکس لپاره د کاروونکي لخوا ټاکل شوې لار اضافه کوئ، هغه VPN ګیټ وی ته اشاره کوئ، او ترافیک لا هم د Azure د انټرنیټ لارې له لارې وځي. یا هغه په سمه توګه وځي او ځواب هیڅکله نه راګرځي. دواړه پایلې له یوې هماغه تېروتنې څخه راځي: د Azure بل ګام د ټول ډیزاین ګڼل. د لارو جدول یوازې دا فیصله کوي چې کڅوړه د Azure په داخل کې کوم وتل غوره کوي. له تونل وروسته ورسره څه پیښیږي او ځواب څنګه بیرته راځي، هغه دویمه نیمایي ده چې تاسو یې باید جوړه کړئ.

بل ګام یوه ګیټ وی ده، نه د وسیلې IP

UDR سمونپال پری فکس بل-ګام ډول ته لیږي، او VirtualNetworkGateway یو ډول دی، نه پته. خلک د ګیټ وی شخصي IP په VirtualAppliance لار کې نښلوي او بیا حیران دي چې ولې هیڅ شی نه سمونپالي، ځکه چې هغه ډول پرځای یې NIC یا داخلي بار برابرونکی تمه کوي. د Microsoft د لارښودنې اسناد هم د ګیټ وی بل ګام یوازې د هغې مجازي شبکې پورې محدودوي چې ګیټ وی یې VPN ګیټ وی وي. ExpressRoute، Route Server او Virtual WAN هب د دې انتخاب له مخې نه پته لري.

مخکې له دې چې لار ولیکئ، وګورئ چې مجازي شبکه واقعاً څه لري. که ډیزاین د هب له لارې تګ کوي، لار د هب د لارښودنې مالک ده، نه د هغې څانګې چې تاسو یې سمول کوئ.

مخکې له هر بدلون، اغیزمنه لار ولولئ

Azure سیسټم لارې، د BGP له لارې زده شوي پری فکسونه او UDR په هر NIC لپاره یوې اغیزمنې لارې جدول کې یوځای کوي، او ترټولو اوږد سمونپال پری فکس ګټي، که هر چیرې څخه راغلی وي. د یوه پری فکس لپاره، UDR د BGP لارې څخه ګټي. همدا ترتیب لامل دی چې د پخواني ازموینې زوړ UDR کولای شي په خاموشۍ هغه پری فکس له پامه وغورځوي چې تاسو همدا اوس د تونل له لارې زده کړ.

لومړی اغیزمن جدول وګورئ، بیا پرېکړه وکړئ چې لار زیاتوئ که یوه بدلوئ:

az network nic show-effective-route-table \
  --resource-group rg-net --name vm-web-nic -o table

د پری فکس ترڅنګ د سرچینې ستون هم ولولئ. د سم پری فکس او ناسمې سرچینې لرونکې لار تاسو ته وایي چې کوم شی سم کړئ، او له لومړۍ سره بایلونکې دویمه لار له زیاتولو ژغوري.

لار د ریښتیني پری فکس او فرعي شبکې له مخې ولیکئ

د فورمې پوسټ څخه کاپي شوې عامه لړۍ پرځای هغه منزل ریښتینې پری فکس وکاروئ چې تاسو واقعاً ورته رسئ. مخکې له دې چې ټول وتل لرې کوونکې تلواله لار په پام کې ونیسئ، له یوې تصویب شوې خدمت سره پیل وکړئ. بیا د کار بار فرعي شبکې سره لارې جدول ونښلوئ. د ګیټ وی فرعي شبکه خپلې اړتیاوې لري، او هلته ستاسو جدول نښلول د کار بار د لارښودنې پرځای ګیټ وی ماتوي.

لار جوړه کړئ، بیا جدول هغې فرعي شبکې سره وتړئ چې کار بار کوربه کوي:

az network route-table route create --resource-group rg-net --route-table-name rt-egress \
  --name to-partner --address-prefix 203.0.113.0/24 --next-hop-type VirtualNetworkGateway
az network vnet subnet update --resource-group rg-net --vnet-name vnet-app \
  --name snet-web --route-table rt-egress

خپریدل هم مهم دي. پر هغه جدول د BGP خپریدل فعال وي، زده شوي پری فکسونه ستاسو د لیکل شوو ترڅنګ ښکاري، او یو ډیر ځانګړی زده شوی پری فکس کولای شي پراخه UDR ته ماتې ورکړي. خپریدل یوازې هغه وخت بند کړئ چې غواړئ د UDR ټولګه هغې فرعي شبکې لپاره واکمنه وي.

په ځای کې نیمایي بشپړه کړئ، که نه نو بهیر هماغله مري

په ځای کې ګیټ وی باید Azure سرچینه ومني، هغه منزل ته ولیږدوي او غوښتنلیک ته اجازه ورکړي. د هغې بل مسیر کولای شي د انټرنیټ وتل یا بله شخصي ګام وي، خو هغه پرېکړه په پلان کې ده، نه په Azure د لارو جدول کې. عادي ناکامي د بیرته راستنیدو لار ده. د انټرنیټ منزل به شخصي Azure سرچینه ستاسو لوري ته بیرته لارښودنه نه کوي، نو ځواب خپل تلواله ګیټ وی ته ځي او مري، یا اصلاً نه وځي.

دوه ډیزاینونه دا حلوي او دوی یو بل ته د بدلون وړ نه دي. سرچینه په وتل کې ژباړه کړئ، ترڅو منزل هغې عامه پتې ته ځواب ووایي چې په ځای کې شبکه یې مالک ده. یا سرچینه وساتئ او یوه لارښودل شوې بیرته راستنیدو اړیکه جوړه کړئ ترڅو ځوابونه د تونل له لارې بیرته راشي. یو غوره کړئ او ولیکئ چې غوښتنلیک به کومه پته وګوري.

ټاکونکي او اجازه لړلیکونه له دې ټولو څخه جلا دي. د Azure بل ګام غوره کول د VPN ترافیک ټاکونکي پراخوي نه، او د یوې بهرنۍ خدمت د سرچینې اجازه لړلیک نه بدلوي.

د هغې سرچینې سره تایید کړئ چې منزل یې ویني

غوښتنه له ریښتیني کار بار څخه ولیږئ، نه د بلې فرعي شبکې د ټوپ هوسټ څخه، بیا هغه سرچینه پته ولولئ چې منزل لیدلې ده. هماغه یوه ارزښت وایي چې د دوو بیرته راستنیدو ډیزاینونو څخه کوم پلي دی. بیا د ځواب لار وګورئ، او تایید کړئ چې VM ته عادي مدیریت ترافیک لا هم کار کوي، ځکه چې په ناڅاپي توګه زیات شوې تلواله لار پخپله د ویجاړ شوي SSH غونډې په توګه لیدل کیږي ډیر مخکې له دې چې د ویجاړ شوي غوښتنلیک په توګه ښکاره شي.

د غوره شوي پری فکس له لارې تیریدل له زورواکي تونل کولو څخه ډیر تنګ بدلون دی. هغه تنګ وساتئ او بیرته اخیستل یوه لار ړنګول دي.