Özel bir Container Apps uygulamasına noktadan siteye VPN ile erişin

Bu kılavuz, iş yükü profillerine sahip bir Container Apps ortamını ve iç sanal ağ girişini kapsar; bu ortama dizüstü bilgisayardan onaylanmış noktadan siteye VPN aracılığıyla erişilir, uygulamanın doğrudan FQDN'si kullanılır ve ortam düzeyinde HTTP rotası yoktur. ortamın girişine istemciden erişilebilir, uygulamanın giriş kapsamı çağıranı kabul eder ve ana bilgisayar adı özel girişe çözümlenir. Aşağıdaki her adım doğrulanabilir bir sonuç ve değiştirmediğiniz hiçbir şeye dokunmayan bir geri alma bırakır. Bunları verilen sırayla tamamlayın, çünkü hiçbir sonraki adım 1. adımda yanlış alınan bir kapsam kararını telafi edemez.

DNS'e dokunmadan önce iç sözcüğünü netleştirin. Bu üründe iki farklı kapsam için kullanılır ve bunları karıştırmak, çalışan bir adın hâlâ yararlı bir şey döndürmemesinin en yaygın nedenidir.

Adım 1: ortamın ve uygulamanın kapsamını belirleyin

Herhangi bir kaydı değiştirmeden önce uygulamanın giriş yapılandırmasını okuyun:

İç giriş, ortamın VNet'i içindeki ortamın iç yük dengeleyicisinde açığa çıkar, bu nedenle soru dizüstü bilgisayarın başka bir kapsayıcı uygulaması olup olmadığı değil, o VNet'e ulaşıp ulaşamadığıdır. VNet'e rotası olan ve ortamın varsayılan etki alanı özel bölge üzerinden çözümlenen bir VPN istemcisi uygun bir çağırandır ve kalan adımlar tam olarak bunu oluşturur. Genel girişi olmayan iç ortam, iç girişi olan uygulamadan farklı bir olgudur ve uygulama düzeyindeki dış giriş ortama genel bir kapı vermez. Kapsamı hem bilete hem de portala yazın, çünkü bir sonraki mühendis önce bileti okur.

Devam etmeden önce bu kapsamı yapılandırma sahibiyle doğrulayın ve kapıyı dar tutun: ortamın VNet'ine rota yoksa veya ortamın varsayılan etki alanı özel bölge üzerinden çözümlenmiyorsa durun ve önce o yolu düzeltin. VNet'e ulaşamayan veya adı çözemeyen bir çağıranın yerini hiçbir sonraki adım tutamaz.

Adım 2: gerçek ana bilgisayar adını ve giriş adresini toplayın

Ortamın varsayılan etki alanını, statik özel giriş adresini ve uygulamanın yapılandırılmış FQDN'sini kaydedin; bunları eski bir ekran görüntüsünden veya wiki sayfasından değil kaynaktan alı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 özel giriş kılavuzu ortamın etki alanının iç adresiyle eşleştirilmesini, uygulamanın ana bilgisayar adları bozulmadan açıklar. Burada elle oluşturduğunuz biçim tam olarak budur, bu nedenle yeni bir adlandırma şeması icat etmek yerine bölge içeriğini buna göre hizalayın.

Okuduğunuz etki alanı uygulamanın bildirdiği FQDN ile eşleşmiyorsa durun ve şimdi bunları uzlaştırın. Yanlış sonek üzerinde bölge oluşturmak, mükemmel çözümlenen ve yine de yanlış sanal ana bilgisayara inen bir ana bilgisayar adı üretir.

Adım 3: özel bölgeyi VPN'in çözümleyici yoluna koyun

Ortamın gerçek varsayılan etki alanı için desteklenen özel DNS bölgesini oluşturun veya yeniden kullanın; belgelenmiş joker ve adres kayıtları statik girişe işaret etsin. Bu bölgeyi uygun sanal ağa bağlayın ve bağlantının yeterli olduğunu varsaymak yerine özel yetkiyi VPN'in onaylanmış çözümleyici yolu üzerinden erişilebilir kılın.

Noktadan siteye istemci genellikle o bölgeye ulaşmak için özel bir çözümleyicinin gelen uç noktasına veya desteklenen bir DNS ileticisine ihtiyaç duyar. Bir bölgeyi bağlamak Azure'un bağlı ağlar için çözümlediği şeyi değiştirir; her dış dizüstü bilgisayarın genel çözümleyicisini yönlendirmez. Başka bir Container Apps ağ modelinden ödünç alınan özel uç nokta DNS bölgesiyle değiştirmeyin, çünkü kayıt adları ve bölge soneki eşleşmeyecektir.

Bu adımın geri alınması bölge bağlantısını veya eklediğiniz kaydı kaldırmaktır. Hangisi olduğunu not edin, çünkü tek bir bağlantıyı geri almak için paylaşılan bir bölgeyi silmek ikinci bir ortamı bozmanın iyi bilinen bir yoludur.

Adım 4: adı, ardından reddedilen kitleyi test edin

Ana bilgisayar adını ve TLS kimliğini birlikte test edin, yalnızca adresi değil. Kontrollü ad eşleme tanılaması için ana bilgisayar adını korurken adresi sabitleyebilirsiniz:

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

Ana bilgisayar adını uygulamanın gerçek FQDN'siyle, adresi de gerçek iç girişle değiştirin. Bu yalnızca o tek isteği etkiler ve DNS sağlama değildir. Kimlik hatasını görünürde bir geçişe dönüştürmek için -k eklemeyin, çünkü sertifika uyuşmazlığı yanlış dinleyiciye çarptığınızın işaretidir.

Sayısal adresi doğrudan istemek, TCP 443 yanıt verirken bile yanlış sanal ana bilgisayarı seçebilir veya doğrulamayı başarısız kılabilir, bu nedenle başarılı bir IP testini ağ hakkında kanıt olarak görün ve daha fazlası değil. Amaçlanan dizüstü bilgisayardan normal çözümleyici yolu, istemcinin DNS ileticisi veya bölgeyi barındıran özel çözümleyicinin gelen uç noktasıdır ve oradaki hata eksik bir kayıt değil, çözümleyiciye erişilebilirlik sorunudur. Aynı isteğin o yolda başarılı olduğunu doğrulayın, ardından reddedilen kitlenin hâlâ reddedildiğini doğrulayın.

Neyin kaydedileceği ve neyin geri alınacağı

Kapsayıcının hedef bağlantı noktası ve istemcinin HTTPS bağlantı noktası ayrı ayarlardır. Kapsayıcı orada dinlediği için hedef bağlantı noktasını VPN üzerinden yayımlamayın ve bir bağlantı noktası testinin geçmesi için ağ kuralını genişletmeyin. Her iki değişiklik de olaydan sonra yaşar ve daha sonra ilişkilendirilmesi zordur.

Amaçlanan dizüstü bilgisayardan yetkili kimliği ve normal DNS'i ile yeni bir uygulama işlemiyle bitirin, ardından yetkisiz bir çağıranın hâlâ başarısız olduğunu kontrol edin. Uygulama yapılandırmasındayken, ortam düzeyinde bir HTTP rotasının bu uygulamayı hedef olarak açığa çıkarıp çıkarmadığını da doğrulayın, çünkü o rota giriş kapsamının tanımlamadığı ikinci kapıdır.

Beş değeri birlikte kaydedin: ortam kapsamı, uygulamanın giriş kapsamı, FQDN, özel giriş adresi ve çözümleyicinin sahibi. Bu beşi tüm erişim sözleşmesini tanımlar ve bunu hata ayıklayacak bir sonraki kişi tam olarak bunları isteyecektir.