د پوائنټ-تر-سایټ VPN له لارې شخصي Container Apps اپلیکیشن ته رسیدل
یو داخلي Container Apps چاپیریال شخصي ننوت، سم هوسټ نوم او داسې حل کوونکي ته اړتیا لري چې VPN ورته ورسیږي۔ هر ګام پرمخ وړئ، بیا انکار تایید کړئ۔
دا لارښود د کاري بار پروفایلونو سره یو Container Apps چاپیریال او د هغې داخلي مجازي شبکې ننوت پوښي؛ هغه ته د لپ ټاپ څخه د تصویب شوي پوائنټ-تر-سایټ VPN له لارې رسیږي، د اپلیکیشن مستقیم FQDN په کارولو سره او د چاپیریال په کچه د HTTP لارو پرته۔ د چاپیریال ننوت د کلاینټ څخه د رسیدو وړ دی، د اپلیکیشن د ننوتلو حد غوښتونکی مني، او هوسټ نوم شخصي ننوت ته حل کیږي۔ لاندې هر ګام د تایید وړ پایله او داسې بیرته اخیستنه پریږدي چې هغه څه ته چې تاسو نه دي بدل کړي لاس نه وهي۔ دوی په ورکړل شوي ترتیب سره بشپړ کړئ، ځکه چې په 1 ګام کې په غلط ډول اخیستل شوې حد پریکړې ته کوم وروستی ګام نشي جبران کولی۔
لیکنې مخکې چې DNS ته لاس ووهئ، د داخلي کلمه روښانه کړئ۔ په دې محصول کې دا د دوو مختلفو حدونو لپاره کارول کیږي، او د هغوی تبادله هغه تر ټولو عام دلیل دی چې یو کار کوونکی نوم لا هم هیڅ ګټور نه بېرته راګرځوي۔
1 ګام: د چاپیریال او اپلیکیشن حد وټاکئ
د هر ریکارډ بدلولو دمخه د اپلیکیشن د ننوتلو ترتیبات ولولئ:
| Setting | Boundary |
|---|---|
| Internal environment | The environment entry is reached through its private network arrangement |
| App with internal ingress | Callers from the environment VNet only; a VPN laptop qualifies once it has a route into that VNet and the domain resolves privately |
| App with external ingress in an internal environment | The app accepts outside traffic through the environment's private entry |
داخلي ننوت د چاپیریال د VNet دننه د چاپیریال په داخلي بار متوازن کوونکي کې ښکاره کیږي، نو پوښتنه دا نه ده چې لپ ټاپ بل کانټینر اپلیکیشن دی که نه، بلکې دا ده چې آیا هغه دې VNet ته رسیږي که نه۔ هغه VPN کلاینټ چې VNet ته لاره لري او د چاپیریال اصلي ډومین د شخصي زون له لارې حل کیږي، وړ غوښتونکی دی، او پاتې ګامونه دقیقاً همدا جوړوي۔ پرته له عامه ننوتلو داخلي چاپیریال له داخلي ننوت سره د اپلیکیشن څخه جلا واقعیت دی، او د اپلیکیشن په کچه بهرنی ننوت چاپیریال ته عامه دروازه نه ورکوي۔ حد په ټیکټ او پورټال دواړو کې ولیکئ، ځکه چې بل انجینر لومړی ټیکټ لولي۔
د دوام دمخه دا حد د ترتیباتو له مالک سره تایید کړئ، او دروازه نرۍ وساتئ: که چاپیریال VNet ته لاره نه وي، یا د چاپیریال اصلي ډومین د شخصي زون له لارې حل نه شي، ودریږئ او لومړی هغه لاره سمه کړئ۔ هغه غوښتونکی چې VNet ته نشي رسیدلی یا نوم نشي حل کولی، کوم وروستی ګام نشي بدلولی۔
2 ګام: ریښتینی هوسټ نوم او د ننوتلو پته راټوله کړئ
د چاپیریال اصلي ډومین، د هغې ثابته شخصي د ننوتلو پته او د اپلیکیشن ترتیب شوې FQDN ولیکئ؛ هغه له سرچینې څخه واخلئ، نه له زاړه سکرین شاټ یا ویکي پاڼې:
az containerapp env show -n ENV -g RG \
--query "{domain:properties.defaultDomain, ip:properties.staticIp}"
az containerapp show -n APP -g RG \
--query "properties.configuration.ingress.fqdn"د Container Apps د شخصي ننوتلو لارښوونې د اپلیکیشن د هوسټ نومونو ساتلو سره د چاپیریال ډومین د هغې داخلي پتې سره سمون بیانوي۔ تاسو دلته په لاس دقیقاً همدا بڼه جوړوئ، نو د نوي نومونې سکیم په جوړولو کې د زون منځپانګه ورسره سمه کړئ۔
که هغه ډومین چې تاسو لوستلی د اپلیکیشن راپور ورکړي FQDN سره سمون نه لري، ودریږئ او اوس یې سره سم کړئ۔ په غلط پسوند باندې زون جوړول داسې هوسټ نوم رامنځته کوي چې په بشپړ ډول حل کیږي او بیا هم په غلط مجازي هوسټ کې کښیني۔
3 ګام: شخصي زون د VPN د حل کوونکي لارې ته کیښئ
د چاپیریال د ریښتیني اصلي ډومین لپاره ملاتړ شوی شخصي DNS زون جوړ یا بیا وکاروئ، چې مستند شوي وائلډکارډ او پته ریکارډونه ثابت ننوت ته اشاره کوي۔ هغه زون مناسبې مجازي شبکې سره ونښلئ، او شخصي واک د VPN د تصویب شوې حل کوونکي لارې له لارې د رسیدو وړ کړئ، نه دا چې نښلون کافي دی۔
پوائنټ-تر-سایټ کلاینټ معمولاً د هغه زون ته د رسیدو لپاره د شخصي حل کوونکي داخلي پای ټکي یا ملاتړ شوي DNS لېږدونکي ته اړتیا لري۔ د زون نښلول بدلوي چې Azure د نښلول شوو شبکو لپاره څه حل کوي؛ دا د هر بهرني لپ ټاپ عامه حل کوونکی نه بدلوي۔ له بل Container Apps شبکې ماډل څخه پور اخیستل شوي شخصي پای ټکي DNS زون سره یې مه بدلوئ، ځکه چې د ریکارډ نومونه او د زون پسوند به سمون نه لري۔
د دې ګام بیرته اخیستنه د زون نښلون یا هغه ریکارډ لرې کول دي چې تاسو اضافه کړی۔ ولیکئ چې کوم یو و، ځکه چې یو نښلون باطلولو لپاره شریک زون حذف کول دوهم چاپیریال ماتولو یوه پیژندل شوې لاره ده۔
4 ګام: نوم وآزموئ، بیا انکار شوې لیدونکي
هوسټ نوم او TLS هویت یوځای وآزموئ، نه یوازې پته۔ د کنټرول شوي نوم نقشه کولو تشخیص لپاره تاسو کولی شئ پته ټینګه کړئ او هوسټ نوم وساتئ:
curl --resolve app.ENVIRONMENT_DOMAIN:443:10.40.0.10 \
https://app.ENVIRONMENT_DOMAIN/هوسټ نوم د اپلیکیشن ریښتیني FQDN سره او پته د ریښتیني داخلي ننوت سره بدل کړئ۔ دا یوازې هغه یوه غوښتنه اغیزه کوي او د DNS چمتو کول نه دي۔ د هویت ناکامي په ښکاره تیریدو بدلولو لپاره -k مه اضافه کوئ، ځکه چې د سند ناسمون د دې نښه ده چې تاسو غلط اوریدونکي ته لګیږئ۔
د عددي پتې مستقیمه غوښتنه ممکن غلط مجازي هوسټ وټاکي یا اعتبار ناکام کړي حتی کله چې TCP 443 ځواب وایي، نو بریالۍ IP ازموینه د شبکې په اړه شواهد وګڼئ او نه ډیر۔ له هدف لپ ټاپ څخه نورماله حل کوونکې لاره د کلاینټ DNS لېږدونکی یا د زون کوربه شخصي حل کوونکي داخلي پای ټکی دی، او هلته ناکامي د ریکارډ نشتوالی نه، بلکې د حل کوونکي ته د رسیدو ستونزه ده۔ تایید کړئ چې هماغه غوښتنه په دې لار کې بریالۍ کیږي، بیا تایید کړئ چې انکار شوې لیدونکي لا هم انکار شوې دي۔
څه ولیکئ او څه بیرته واخلئ
د کانټینر هدف پورټ او د کلاینټ HTTPS پورټ جلا تنظیمات دي۔ د کانټینر هدف پورټ د VPN له لارې مه خپروئ ځکه چې کانټینر هلته اوریدل کوي، او د پورټ ازموینې تیریدو لپاره شبکه ییز قانون مه پراخوئ۔ دواړه بدلونونه له پیښې وروسته ژوندي پاتې کیږي او وروسته یې نسبت کول ستونزمن دي۔
له هدف لپ ټاپ څخه د هغه مجاز هویت او نورمال DNS په کارولو سره نوي اپلیکیشن عملیات سره پای ته ورسئ، بیا وګورئ چې غیر مجاز غوښتونکی لا هم ناکام کیږي۔ کله چې په اپلیکیشن ترتیباتو کې یاست، دا هم تایید کړئ چې د چاپیریال په کچه HTTP لاره دا اپلیکیشن د هدف په توګه ښکاره کوي که نه، ځکه چې هغه لاره دوهمه دروازه ده چې د ننوتلو حد یې نه بیانوي۔
پنځه ارزښتونه یوځای ولیکئ: د چاپیریال حد، د اپلیکیشن د ننوتلو حد، FQDN، شخصي د ننوتلو پته او د حل کوونکي مالک۔ هغه پنځه ټول د لاسرسي تړون بیانوي، او بل څوک چې دا ډیبګ کړي به دقیقاً هماغه وغواړي۔