ولې Azure Point-to-Site VPN ستاسو عامه IP نه بدلوي
د point-to-site تونل یوازې د مجازي شبکې لارې لېږدوي، نو ستاسو عامه IP محلي پاتې کېږي تر څو چې اجباري تونلېنګ او د فایر وال SNAT وتنه Azure ته انتقال کړي۔
زه په Windows لپ ټاپ کې د Azure VPN کلاینټ نښلوم، د پت-غږ پاڼه پرانیزم او هماغه عامه پته وینم چې زما د کور روټر ورکړې وه۔ په همدې حال کې په 10.20.0.4 کې جمپ بکس ځواب ورکوي او د یوه شخصي پای ټکي نوم حل کېږي، نو تونل نه دی مات شوی۔ د point-to-site دروازه په سمه توګه هماغه کار کوي چې د هغې اصلي ترتیب وایي: شخصي پری فکسونه لېږدوي او نور هر څه په محلي اړیکه کې پرېږدي۔ د Azure ملکیت وتنې پتې ترلاسه کول د روټېنګ ډیزاین بدلون دی، ترمیم نه۔
دروازه په اصلي توګه څه اعلانوي
دروازه د مجازي شبکې د پتې فضا لپاره لارې ټېل وهي، سربېره پردې هغه همکارې شبکې چې هلته د دروازې تګ راتګ اجازه لري او هغه محلي پری فکسونه چې د site-to-site اړیکې یا BGP له لارې زده شوي۔ په دې ټولګه کې 0.0.0.0/0 نشته۔ ستاسو عملیاتي سیستم خپله اصلي لار په Wi-Fi یا Ethernet باندې ساتي، نو عامه API ته تلونکی پیکټ هېڅکله تونل ته نه ننوځي۔
هغه پته چې کلاینټ د تونل په دننه کې ترلاسه کوي د point-to-site حوض څخه شخصي کرایه ده۔ دا کلاینټ VNet کې سرچینو ته پېژني؛ دا د انټرنېټ لخوا لیدل کېدونکې پته نه ده، او هېڅکله به د SaaS API ته تلونکې وتنې غوښتنې سرچینه نه ښکاري۔ د هغې کرایې شاوخوا جوړ شوی allowlist ننوتنه کار نه شي کولی، هر څومره چې د عرضه کوونکي لاګونو کې د هغې د ښکارېدو انتظار وکړئ۔
وېشل شوی تونل او اجباري تونلېنګ څنګ په څنګ
| Split tunnel, the default | Forced tunneling | |
|---|---|---|
| Internet traffic exits through | local ISP or office router | firewall or appliance inside Azure |
| Source address the API sees | your home or office IP | the firewall public IP |
| Inspection and logging in Azure | none | policy rules plus flow logs |
| Ongoing cost | gateway only | gateway, firewall hours, data processing |
| What usually breaks | nothing on the egress path | DNS, on-premises routes, overlapping local ranges |
یوازې دوهمه کرښه هغه پته بدلوي چې لرې خدمت یې ویني۔ په هغې جدول کې نور هر څه لګښت او عملیاتي سطح ده چې تاسو یې منئ کله چې وتنه د Azure په دننه کې تفتیش یا ژباړل کېدل غواړي۔ که څوک له تاسو وغواړي چې عامه IP بدله شي، هغه ټوله ښي کالم غواړي، نه په کلاینټ کې کوچنی سمون۔
د یو څه بیا جوړولو دمخه د نومولو وړ یو منځنی انتخاب شته۔ په VNet کې دننه پروکسي یا د دروازې VM تاسو ته د هغو اپلیکیشنونو لپاره کنټرول شوې سرچینه پته درکوي چې هغې ته اشاره کېدای شي، پرته له دې چې د کلاینټ اصلي لاره ځای په ځای شي۔ دا عادي لټون محلي ساتي او بیا هم هغه شریک قناعت کوي چې یوازې یوه API زنګ غواړي چې له Azure څخه راشي۔ کله چې اړتیا واقعاً د ټول ټرافیک په اړه وي نو دا ناکامېږي، ځکه چې هر هغه څه چې د پروکسي ترتیب ته پام نه کوي بیا هم محلي وتنه کوي۔
تونل دې اصلي لاره ولېږدوي
په مجازي شبکې دروازه کې، د کلاینټ ټول انټرنېټ ټرافیک تونل ته اړولو ملاتړ شوې لاره دا ده چې د point-to-site ترتیب ته ځانګړې لارې اضافه کړئ۔ دوه نیمایي ټوله IPv4 فضا پوښي، او هر یو له محلي اصلي لارې څخه ډېر مشخص دی، نو کلاینټ پرته له دې چې څه حذف کړي هغوی ته لومړیتوب ورکوي:
Set-AzVirtualNetworkGateway -VirtualNetworkGateway GWOBJ -CustomRoute 0.0.0.0/1,128.0.0.0/1هغه کرښه مثال دی، د کاپي-پیسټ لپاره بشپړه نه ده: لومړی د Get-AzVirtualNetworkGateway سره د دروازې آبجیکټ ترلاسه کړئ او د GWOBJ په ځای یې کېږدئ، او د چلولو دمخه تایید کړئ چې SKU او د ځای پرځای کولو ماډل ځانګړې لارې مني۔ هماغه پری فکسونه په پورټل کې د point-to-site ترتیب پاڼې باندې ښکاري، او که تاسو لا دمخه دروازه سکریپټ نه کوئ نو هغوی ته د ترتیب ورکولو خوندي ځای هماغه دی۔
د هغو پری فکسونو بدلون کلاینټ پیکېټ باطلوي۔ VPN کلاینټ پیکېټ بیا ډاونلوډ او بیا نصب کړئ، ځکه چې لارې د پروفایل په دننه کې سفر کوي۔ هغه کلاینټ چې خپل زوړ پروفایل سره بیا نښلېږي زوړ د لارو ټولګه ساتي، او تاسو ممکن یوه ساعت په هغه بدلون دېباګ کولو کې له لاسه ورکړئ چې هېڅکله ورته نه دی رسېدلی۔
په خوندي مجازي WAN هب کې معادل د point-to-site دروازې سره تړلي هب د لارو جدول کې اصلي لاره ده، او ټرافیک په هب کې Azure Firewall اخلي۔ فایر وال د انټرنېټ په لور اړیکې خپلو عامه IP پتو ته ژباړي، او نوی وتنې پته هماغه ژباړې څخه راځي۔ کله چې یو فایر وال څو عامه IP ولري، له هغوی څخه هر یو کېدای شي د سرچینې په توګه ښکاره شي، نو allowlist باید ټول ولري۔
پورته دواړه ډیزاینونه IPv4 دي۔ دوه /1 پری فکسونه د IPv6 لپاره هېڅ نه کوي، او د point-to-site د IPv6 ملاتړ دومره تنګ دی چې د برابرۍ ژمنې دمخه باید ترکیب وازموئ۔
لومړی لاره وګورئ، بیا وتنه
د پیکېټ بیا نصب او بیا نښلولو وروسته تایید کړئ چې کلاینټ واقعاً دواړه نیمایي نصب کړي۔ په Windows کې Get-NetRoute -DestinationPrefix 0.0.0.0/1 او د 128.0.0.0/1 لپاره هماغه پوښتنه باید د تونل انټرفېس نوم واخلي، او route print دواړه ستاسو د اصلي اصلي لارې ترڅنګ ښیي۔ په Linux کې ip route show باید دواړه پری فکسونه لیست کړي؛ که ونه کړي، پروفایل هغوی هېڅکله نه دي لېږدولي۔
بیا له کلاینټ څخه عامه پته بیا وګورئ او د هماغې اړیکې لپاره د فایر وال لاګ ولولئ۔ سرچینه باید د ژباړل شوې پورټ سره د فایر وال عامه IP وي۔ هغه کلاینټ چې دواړه لارې موجودې وي او بیا هم محلي وتنه کوي مانا دا ده چې پیکټونه Azure ته رسېدلي او بل لارې وتلي: په دروازې سبنیټ کې د کاروونکي ټاکل شوې لاره، هغه فایر وال چې پخپله محلي شبکې ته اجباري تونل شوی، یا هغه پالیسي چې جریان د ژباړې دمخه غورځوي۔
په هماغه ناسته کې یو شخصي هدف بیا وآزموئ۔ هغه جمپ هوسټ چې د بدلون وروسته ځواب ورکول بندوي د دې عادي نښه ده چې نوي پری فکسونو یو څه څنګ ته کړي دي، یا هغه تنګه محلي لاره چې مخکې اعلان شوې وه یا هغه نوم حل چې اوس ستاسو شخصي زونونو لپاره پرته له فوروارډر ریزولور ته ځي۔
کله دې وېشل شوی تونل یوازې پرېږدئ
که هدف یوازې شخصي API، شخصي پای ټکي یا داخلي اډمین پاڼې ته رسېدل وي، اصلي چلند ارزانه او غلی دی۔ اجباري تونلېنګ د فایر وال ساعتونه او د معلوماتو پروسس لګښتونه، اوږده لاره، او یو بل ځای اضافه کوي چې هر کلاینټ جریان پکې ناکامېدای شي۔ دا له هغې یوې هدف څخه چې تاسو یې فکر کاوه ډېر زیات ټرافیک هم نیسي۔
هغې ته هله ورګرځئ چې اړتیا د وتنې له مخې بیان شي: شریک باید ثابته Azure پته وویني، امنیت غواړي چې اړیکې لاګ او تفتیش شي، یا معلومات باید له یو کنټرول شوي ټکي څخه ووځي۔ حتی هله هم ډیزاین هر کاروونکي ته ګډه وتنه ورکوي، نو د هر کاروونکي مسؤلیت باید د سرچینې پتې نه بلکې په اپلیکیشن کې د هویت څخه راشي۔
د بدلون له بندولو دمخه څلور شیان تایید کړئ: نصب شوې کلاینټ پیکېټ نوې ده، دواړه /1 لارې د تونل انټرفېس باندې دي، یو شخصي هدف لا هم ځواب ورکوي، او د لرې خدمت لاګ د فایر وال پته ښیي۔