Pristup privatnoj aplikaciji Container Apps preko VPN-a tipa točka-na-lokaciju

Ovaj priručnik pokriva okruženje Container Apps sa profilima radnog opterećenja i internim ulazom u virtualnu mrežu, do kojeg se s laptopa dolazi preko odobrenog VPN-a tipa točka-na-lokaciju, koristeći direktni FQDN aplikacije i bez HTTP ruta na razini okruženja. ulaz u okruženje je dostupan s klijenta, opseg ulaznog prometa aplikacije dopušta pozivatelja, a ime hosta se razrješava na privatni ulaz. Svaki korak u nastavku ostavlja provjerljiv rezultat i vraćanje unatrag koje ne dira ništa što niste promijenili. Prođite kroz njih zadanim redoslijedom, jer nijedan kasniji korak ne može nadoknaditi odluku o opsegu donesenu pogrešno u koraku 1.

Prije nego što dotaknete DNS, razjasnite riječ interno. U ovom proizvodu ona se koristi za dva različita opsega, a njihova zamjena najčešći je razlog zašto radno ime još uvijek ne vraća ništa korisno.

Korak 1: utvrdite opseg okruženja i aplikacije

Pročitajte konfiguraciju ulaznog prometa aplikacije prije nego što promijenite bilo koji zapis:

Interni ulazni promet izložen je na internom balanseru opterećenja okruženja unutar VNet-a okruženja, pa pitanje nije je li laptop još jedna kontejnerska aplikacija, nego može li doći do tog VNet-a. VPN klijent s rutom u VNet i zadanom domenom okruženja koja se razrješava kroz privatnu zonu jest prihvatljiv pozivatelj, a to je upravo ono što preostali koraci grade. Interno okruženje bez javnog ulaza druga je činjenica od aplikacije s internim ulaznim prometom, a vanjski ulazni promet na razini aplikacije ne daje okruženju javna vrata. Zapišite opseg u tiket, kao i u portal, jer sljedeći inženjer prvo čita tiket.

Potvrdite taj opseg s vlasnikom konfiguracije prije nego što nastavite i držite vrata uskima: ako ne postoji ruta u VNet okruženja ili se zadana domena okruženja ne razrješava kroz privatnu zonu, zaustavite se i prvo popravite taj put. Nijedan kasniji korak ne može zamijeniti pozivatelja koji ne može doći do VNet-a ili razriješiti ime.

Korak 2: prikupite stvarno ime hosta i adresu ulaza

Zapišite zadanu domenu okruženja, njegovu statičku privatnu adresu ulaza i konfigurirani FQDN aplikacije, uzete iz resursa, a ne sa stare snimke zaslona ili wiki stranice:

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"

Smjernice za privatni ulaz Container Apps opisuju usklađivanje domene okruženja s njegovom internom adresom uz zadržavanje imena hostova aplikacije netaknutima. To je točno oblik koji ovdje gradite ručno, pa uskladite sadržaj zone s njim umjesto da izmišljate novu shemu imenovanja.

Ako se domena koju ste pročitali ne podudara s FQDN-om koji aplikacija prijavljuje, zaustavite se i uskladite ih sada. Gradnja zone na pogrešnom sufiksu daje ime hosta koje se savršeno razrješava i ipak završava na pogrešnom virtualnom hostu.

Korak 3: stavite privatnu zonu na put resolvera VPN-a

Izradite ili ponovno upotrijebite podržanu privatnu DNS zonu za stvarnu zadanu domenu okruženja, s dokumentiranim zapisima zamjenskog znaka i adrese koji pokazuju na statički ulaz. Povežite tu zonu s odgovarajućom virtualnom mrežom i učinite privatno tijelo dostupnim preko odobrenog puta resolvera VPN-a, umjesto da pretpostavljate da je veza dovoljna.

Klijent tipa točka-na-lokaciju obično treba ulaznu završnu točku privatnog resolvera ili podržani DNS prosljeđivač da bi došao do te zone. Povezivanje zone mijenja ono što Azure razrješava za povezane mreže; ono ne preusmjerava javni resolver svakog vanjskog laptopa. Ne zamjenjujte je DNS zonom privatne završne točke posuđenom iz drugog mrežnog modela Container Apps, jer se imena zapisa i sufiks zone neće poklopiti.

Vraćanje unatrag za ovaj korak je uklanjanje veze zone ili zapisa koji ste dodali. Zabilježite koje je od toga bilo, jer brisanje zajedničke zone da biste poništili jednu vezu poznat je način da pokvarite drugo okruženje.

Korak 4: testirajte ime, zatim odbijenu publiku

Testirajte ime hosta i TLS identitet zajedno, ne samo adresu. Za kontroliranu dijagnostiku mapiranja imena možete prikvačiti adresu uz zadržavanje imena hosta:

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

Zamijenite ime hosta stvarnim FQDN-om aplikacije, a adresu stvarnim internim ulazom. To utječe samo na taj jedan zahtjev i nije DNS provisioning. Ne dodajte -k da biste neuspjeh identiteta pretvorili u prividan uspjeh, jer nesklad certifikata signal je da pogađate pogrešnog slušatelja.

Izravno traženje numeričke adrese može odabrati pogrešan virtualni host ili pasti validaciju čak i dok TCP 443 odgovara, pa uspješan IP test tretirajte kao dokaz o mreži i ništa više. S namjeravanog laptopa normalan put resolvera je DNS prosljeđivač klijenta ili ulazna završna točka privatnog resolvera koji ugošćuje zonu, a neuspjeh tamo je problem dostupnosti resolvera, a ne zapis koji nedostaje. Potvrdite da isti zahtjev uspijeva na tom putu, zatim potvrdite da je odbijena publika još uvijek odbijena.

Što zabilježiti i što vratiti unatrag

Ciljni port kontejnera i HTTPS port klijenta odvojene su postavke. Ne objavljujte ciljni port kontejnera preko VPN-a zato što kontejner tamo sluša i ne proširujte mrežno pravilo da bi test porta prošao. Obje promjene nadživljavaju incident i kasnije ih je teško pripisati.

Završite svježom operacijom aplikacije s namjeravanog laptopa, koristeći njegov ovlašteni identitet i uobičajeni DNS, pa provjerite da neovlašteni pozivatelj još uvijek ne uspijeva. Dok ste u konfiguraciji aplikacije, također potvrdite izlaže li HTTP ruta na razini okruženja ovu aplikaciju kao metu, jer je ta ruta druga vrata koja opseg ulaznog prometa ne opisuje.

Zapišite pet vrijednosti zajedno: opseg okruženja, opseg ulaznog prometa aplikacije, FQDN, privatnu adresu ulaza i vlasnika resolvera. Tih pet opisuje cijeli ugovor o pristupu, a sljedeća osoba koja će ga otklanjati tražit će točno njih.