Доступ да прыватнай праграмы Container Apps праз VPN пункт-сайт

Гэтая працэдура апісвае асяроддзе Container Apps з профілямі рабочых нагрузак і ўнутраным уваходам у віртуальную сетку, да якога з ноўтбука дабіраюцца праз зацверджаны VPN пункт-сайт, выкарыстоўваючы прамы FQDN праграмы і без HTTP-маршрутаў на ўзроўні асяроддзя. уваход у асяроддзе дасягальны з кліента, вобласць уваходу праграмы дапускае выклікаючага, а імя хоста развязваецца ў прыватны ўваход. Кожны крок ніжэй пакідае правераны вынік і адкат, які не закранае нічога, чаго вы не змянялі. Праходзьце іх у зададзеным парадку, бо ні адзін наступны крок не кампенсуе рашэнне аб вобласці, прынятае памылкова на кроку 1.

Перш чым кранаць DNS, вызначцеся са словам унутраны. Яно ўжываецца для дзвюх розных абласцей у гэтым прадукце, і іх блытаніна — самая частая прычына, чаму працоўнае імя ўсё яшчэ вяртае нічога карыснага.

Крок 1: зафіксаваць вобласць асяроддзя і праграмы

Прачытайце канфігурацыю ўваходу праграмы, перш чым змяняць любы запіс:

Унутраны ўваход адкрыты на ўнутраным балансіроўшчыку нагрузак асяроддзя ўнутры 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 развязвае для звязаных сетак; яно не перанакіроўвае публічны рэзалвер кожнага знешняга ноўтбука. Не падмяняйце зону DNS прыватнай канчатковай кропкі, пазычаную з іншай мадэлі сетак Container Apps, бо імёны запісаў і суфікс зоны не супадуць.

Адкат для гэтага кроку — выдаленне сувязі зоны або дададзенага вамі запісу. Запішыце, што менавіта гэта было, бо выдаленне агульнай зоны, каб адмяніць адну сувязь, — вядомы спосаб зламаць другое асяроддзе.

Крок 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, прыватны адрас уваходу і ўладальніка рэзалвера. Гэтыя пяць апісваюць увесь кантракт доступу, і наступны чалавек, які будзе яго адладжваць, спытае менавіта іх.