Nöqtədən sayta VPN vasitəsilə şəxsi Container Apps tətbiqinə çatın

Bu sənəd daxili virtual şəbəkə girişi olan, iş yükü profilləri üzrə Container Apps mühitini əhatə edir; ona noutbukdan təsdiqlənmiş nöqtədən sayta VPN vasitəsilə çatılır və tətbiqin birbaşa FQDN-i istifadə olunur, mühit səviyyəsində HTTP marşrutu yoxdur. mühit girişinə müştəridən çatmaq mümkündür, tətbiqin giriş sahəsi çağıranı qəbul edir və host adı şəxsi girişə həll olunur. Aşağıdakı hər addım yoxlanıla bilən nəticə və dəyişmədiyiniz heç nəyə toxunmayan geri qaytarma buraxır. Onları verilən ardıcıllıqla yerinə yetirin, çünki sonrakı heç bir addım 1-ci addımda səhv verilmiş sahə qərarını kompensasiya edə bilməz.

DNS-ə toxunmazdan əvvəl daxili sözünü dəqiqləşdirin. Bu məhsulda o, iki fərqli sahə üçün işlədilir və onları qarışdırmaq işlək adın hələ də faydalı heç nə qaytarmamasının ən çox rast gəlinən səbəbidir.

Addım 1: mühitin və tətbiqin sahəsini dəqiqləşdirin

Hər hansı qeydi dəyişməzdən əvvəl tətbiqin giriş konfiqurasiyasını oxuyun:

Daxili giriş mühitin VNet-i daxilində mühitin daxili yük balanslaşdırıcısında açılır, yəni sual noutbukun başqa bir konteyner tətbiqi olub-olmaması deyil, o VNet-ə çata bilməsidir. VNet-ə marşrutu olan və mühitin standart domeni şəxsi zona vasitəsilə həll olunan VPN müştərisi uyğun çağırandır və qalan addımlar məhz bunu qurur. Publik girişi olmayan daxili mühit daxili girişli tətbiqdən fərqli bir faktdır və tətbiq səviyyəsində xarici giriş mühitə publik qapı vermir. Sahəni portalla yanaşı biletdə də yazın, çünki növbəti mühəndis əvvəlcə bileti oxuyur.

Davam etməzdən əvvəl bu sahəni konfiqurasiya sahibi ilə təsdiqləyin və darvazanı dar saxlayın: mühitin VNet-inə marşrut yoxdursa və ya mühitin standart domeni şəxsi zona vasitəsilə həll olunmursa, dayanın və əvvəlcə o yolu düzəldin. Sonrakı heç bir addım VNet-ə çata bilməyən və ya adı həll edə bilməyən çağıranı əvəz edə bilməz.

Addım 2: real host adını və giriş ünvanını toplayın

Mühitin standart domenini, onun statik şəxsi giriş ünvanını və tətbiqin konfiqurasiya edilmiş FQDN-ni qeyd edin; bunları köhnə ekran şəklindən və ya wiki səhifəsindən deyil, resursun özündən götürün:

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 üçün şəxsi giriş təlimatı tətbiqin host adlarını toxunulmaz saxlayaraq mühitin domenini onun daxili ünvanına uyğunlaşdırmağı təsvir edir. Bu, burada əl ilə qurduğunuz formanın tam eynisidir, ona görə zona məzmununu yeni adlandırma sxemi uydurmaq əvəzinə ona uyğunlaşdırın.

Oxuduğunuz domen tətbiqin bildirdiyi FQDN ilə uyğun gəlmirsə, dayanın və indi onları uzlaşdırın. Səhv sonluq üzərində zona qurmaq mükəmməl həll olunan, amma yenə də səhv virtual hosta düşən host adı yaradır.

Addım 3: şəxsi zonanı VPN-in həlledici yoluna qoyun

Mühitin faktiki standart domeni üçün dəstəklənən şəxsi DNS zonasını yaradın və ya təkrar istifadə edin; sənədləşdirilmiş vəhşi kart və ünvan qeydləri statik girişə yönəlsin. Həmin zonanı uyğun virtual şəbəkəyə bağlayın və şəxsi səlahiyyəti linkin kifayət etdiyini fərz etmək əvəzinə VPN-in təsdiqlənmiş həlledici yolu vasitəsilə əlçatan edin.

Nöqtədən sayta müştəri adətən o zonaya çatmaq üçün şəxsi həlledici üçün giriş son nöqtəsinə və ya dəstəklənən DNS yönləndiricisinə ehtiyac duyur. Zonanın bağlanması Azure-un bağlı şəbəkələr üçün nəyi həll etdiyini dəyişir; o, hər xarici noutbukun publik həlledicisini yönləndirmir. Fərqli Container Apps şəbəkə modelindən götürülmüş şəxsi son nöqtə DNS zonasını əvəz etməyin, çünki qeyd adları və zona sonluğu uyğun gəlməyəcək.

Bu addım üçün geri qaytarma zona linkini və ya əlavə etdiyiniz qeydi silməkdir. Hansının olduğunu qeyd edin, çünki tək bir linki ləğv etmək üçün ortaq zonanı silmək ikinci mühiti pozmağın tanınmış yoludur.

Addım 4: adı, sonra imtina olunan auditoriyanı sınaqdan keçirin

Host adını və TLS kimliyini birlikdə sınayın, təkcə ünvanı yox. Nəzarətli ad xəritələmə diaqnostikası üçün host adını saxlayaraq ünvanı sabitləyə bilərsiniz:

curl --resolve app.ENVIRONMENT_DOMAIN:443:10.40.0.10 \
    https://app.ENVIRONMENT_DOMAIN/

Host adını real tətbiq FQDN-i ilə, ünvanı isə real daxili girişlə əvəz edin. Bu yalnız həmin bir sorğuya aiddir və DNS təminatı deyil. Kimlik uğursuzluğunu görünən uğura çevirmək üçün -k əlavə etməyin, çünki sertifikat uyğunsuzluğu səhv dinləyiciyə dəydiyinizin siqnalıdır.

Rəqəmsal ünvana birbaşa sorğu göndərmək səhv virtual hostu seçə və ya TCP 443 cavab verərkən belə validasiyanı uğursuz edə bilər, ona görə uğurlu IP testini yalnız şəbəkə haqqında sübut kimi qəbul edin. Nəzərdə tutulan noutbukdan normal həlledici yolu müştərinin DNS yönləndiricisi və ya zonanı yerləşdirən şəxsi həlledicinin giriş son nöqtəsidir və oradakı uğursuzluq çatışmayan qeyd deyil, həllediciyə çatma problemi deməkdir. Eyni sorğunun həmin yolda uğurlu olduğunu təsdiqləyin, sonra imtina olunan auditoriyanın hələ də imtina edildiyini təsdiqləyin.

Nəyi qeyd etmək və nəyi geri qaytarmaq lazımdır

Konteynerin hədəf portu və müştərinin HTTPS portu ayrı parametrlərdir. Konteyner orada dinlədiyi üçün onun hədəf portunu VPN üzərindən yayımlamayın və port testini keçirmək üçün şəbəkə qaydasını genişləndirməyin. Hər iki dəyişiklik hadisədən sonra da qalır və sonradan onları kimin etdiyini müəyyən etmək çətindir.

Nəzərdə tutulan noutbukdan onun icazəli kimliyi və normal DNS-i ilə təzə bir tətbiq əməliyyatı ilə bitirin, sonra icazəsiz çağıranın hələ də uğursuz olduğunu yoxlayın. Tətbiq konfiqurasiyasında olarkən mühit səviyyəsində HTTP marşrutunun bu tətbiqi hədəf kimi açıb-açmadığını da təsdiqləyin, çünki həmin marşrut giriş sahəsinin təsvir etmədiyi ikinci qapıdır.

Beş dəyəri birlikdə qeyd edin: mühit sahəsi, tətbiqin giriş sahəsi, FQDN, şəxsi giriş ünvanı və həlledici sahibi. Bu beşi bütün giriş müqaviləsini təsvir edir və onu sazlayacaq növbəti şəxs məhz bunları soruşacaq.