Přístup k privátní aplikaci Container Apps přes VPN typu bod-lokalita

Tento runbook popisuje prostředí Container Apps s profily úloh a interním vstupem do virtuální sítě, k němuž se z notebooku přistupuje přes schválenou VPN typu bod-lokalita, s použitím přímého FQDN aplikace a bez HTTP tras na úrovni prostředí. vstup do prostředí je z klienta dostupný, rozsah příchozího provozu aplikace připouští volajícího a název hostitele se překládá na privátní vstup. Každý krok níže zanechává ověřitelný výsledek a vrácení zpět, které se nedotkne ničeho, co jste nezměnili. Projděte je v uvedeném pořadí, protože žádný pozdější krok nenahradí rozhodnutí o rozsahu učiněné chybně v kroku 1.

Než se dotknete DNS, ujasněte si slovo interní. V tomto produktu se používá pro dva různé rozsahy a jejich záměna je nejčastějším důvodem, proč funkční název stále nevrací nic užitečného.

Krok 1: stanovte rozsah prostředí a aplikace

Přečtěte si konfiguraci příchozího provozu aplikace, než změníte jakýkoli záznam:

Interní příchozí provoz je vystaven na interním nástroji pro vyrovnávání zatížení prostředí uvnitř VNet prostředí, takže otázka nezní, zda je notebook další kontejnerová aplikace, ale zda se do této VNet dostane. Klient VPN s trasou do VNet a výchozí doménou prostředí, která se překládá přes privátní zónu, je způsobilý volající, a právě to zbývající kroky budují. Interní prostředí bez veřejného vstupu je jiný fakt než aplikace s interním příchozím provozem a externí příchozí provoz na úrovni aplikace nedává prostředí veřejné dveře. Zapište rozsah do tiketu i do portálu, protože další inženýr čte nejprve tiket.

Potvrďte tento rozsah s vlastníkem konfigurace, než budete pokračovat, a držte bránu úzkou: pokud do VNet prostředí neexistuje trasa nebo se výchozí doména prostředí nepřekládá přes privátní zónu, zastavte se a nejprve opravte tuto cestu. Žádný pozdější krok nenahradí volajícího, který se do VNet nedostane nebo nedokáže přeložit název.

Krok 2: shromážděte skutečný název hostitele a adresu vstupu

Zaznamenejte výchozí doménu prostředí, jeho statickou privátní adresu vstupu a nakonfigurovaný FQDN aplikace, převzaté ze zdroje, nikoli ze starého snímku obrazovky nebo wiki stránky:

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"

Pokyny pro privátní vstup Container Apps popisují sladění domény prostředí s jeho interní adresou při zachování názvů hostitelů aplikace. Přesně tento tvar zde budujete ručně, proto s ním slučte obsah zóny, místo abyste vymýšleli nové schéma pojmenování.

Pokud doména, kterou jste přečetli, neodpovídá FQDN, který aplikace hlásí, zastavte se a hned je slučte. Budování zóny na špatné příponě vytvoří název hostitele, který se dokonale přeloží a přesto skončí na špatném virtuálním hostiteli.

Krok 3: umístěte privátní zónu na cestu překladače VPN

Vytvořte nebo znovu použijte podporovanou privátní zónu DNS pro skutečnou výchozí doménu prostředí, s dokumentovanými záznamy zástupného znaku a adresy ukazujícími na statický vstup. Propojte tuto zónu s příslušnou virtuální sítí a zpřístupněte privátní autoritu přes schválenou cestu překladače VPN, místo abyste předpokládali, že propojení stačí.

Klient typu bod-lokalita obvykle potřebuje příchozí koncový bod privátního překladače nebo podporovaný přesměrovač DNS, aby se do této zóny dostal. Propojení zóny mění, co Azure překládá pro propojené sítě; nepřesměrovává veřejný překladač každého externího notebooku. Nenahrazujte ji zónou DNS privátního koncového bodu vypůjčenou z jiného síťového modelu Container Apps, protože názvy záznamů a přípona zóny si nebudou odpovídat.

Vrácením tohoto kroku je odebrání propojení zóny nebo záznamu, který jste přidali. Poznamenejte si, které z toho to bylo, protože smazání sdílené zóny za účelem zrušení jediného propojení je známý způsob, jak rozbít druhé prostředí.

Krok 4: otestujte název a poté odmítnuté publikum

Testujte název hostitele a identitu TLS společně, ne jen adresu. Pro řízenou diagnostiku mapování názvů můžete adresu připnout a název hostitele zachovat:

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

Nahraďte název hostitele skutečným FQDN aplikace a adresu skutečným interním vstupem. Týká se to pouze tohoto jednoho požadavku a není to zřizování DNS. Nepřidávejte -k, abyste selhání identity změnili na zdánlivý úspěch, protože neshoda certifikátu je signál, že míříte na špatný listener.

Přímý požadavek na číselnou adresu může vybrat špatného virtuálního hostitele nebo selhat validaci, i když TCP 443 odpovídá, proto úspěšný test IP berte jako důkaz o síti a nic víc. Z zamýšleného notebooku je normální cestou překladače přesměrovač DNS klienta nebo příchozí koncový bod privátního překladače, který zónu hostuje, a selhání tam je problém dostupnosti překladače, ne chybějící záznam. Potvrďte, že stejný požadavek na této cestě uspěje, a poté potvrďte, že odmítnuté publikum je stále odmítnuto.

Co zaznamenat a co vrátit zpět

Cílový port kontejneru a port HTTPS klienta jsou samostatná nastavení. Nezveřejňujte cílový port kontejneru přes VPN proto, že tam kontejner naslouchá, a nerozšiřujte síťové pravidlo, aby test portu prošel. Obě změny přežijí incident a později se těžko připisují.

Skončete čerstvou operací aplikace ze zamýšleného notebooku s jeho oprávněnou identitou a běžným DNS a poté zkontrolujte, že neoprávněný volající stále selhává. Zatímco jste v konfiguraci aplikace, potvrďte také, zda HTTP trasa na úrovni prostředí vystavuje tuto aplikaci jako cíl, protože tato trasa jsou druhé dveře, které rozsah příchozího provozu nepopisuje.

Zaznamenejte pět hodnot společně: rozsah prostředí, rozsah příchozího provozu aplikace, FQDN, privátní adresu vstupu a vlastníka překladače. Těchto pět popisuje celou smlouvu o přístupu a příští člověk, který ji bude ladit, se zeptá přesně na ně.