Mencapai aplikasi Container Apps peribadi melalui VPN titik ke tapak
Persekitaran Container Apps dalaman memerlukan entri peribadi, nama hos yang sepadan dan penyelesai yang boleh dicapai oleh VPN. Jalankan setiap langkah, kemudian sahkan penafian.
Buku panduan ini merangkumi persekitaran Container Apps dengan profil beban kerja dan entri rangkaian maya dalaman, yang dicapai dari komputer riba melalui VPN titik ke tapak yang diluluskan, menggunakan FQDN langsung aplikasi dan tanpa laluan HTTP pada peringkat persekitaran. entri persekitaran boleh dicapai dari klien, skop ingress aplikasi menerima pemanggil, dan nama hos diselesaikan ke entri peribadi. Setiap langkah di bawah meninggalkan hasil yang boleh disahkan dan pembalikan yang tidak menyentuh apa-apa yang tidak anda ubah. Lakukan mengikut urutan yang diberi, kerana tiada langkah kemudian boleh mengimbangi keputusan skop yang dibuat secara salah dalam langkah 1.
Sebelum menyentuh DNS, jelaskan perkataan dalaman. Ia digunakan untuk dua skop berbeza dalam produk ini, dan menukarnya ialah punca paling biasa nama yang berfungsi masih tidak memulangkan apa-apa yang berguna.
Langkah 1: tetapkan skop persekitaran dan aplikasi
Baca konfigurasi ingress aplikasi sebelum menukar mana-mana rekod:
| Setting | Boundary |
|---|---|
| Internal environment | The environment entry is reached through its private network arrangement |
| App with internal ingress | Callers from the environment VNet only; a VPN laptop qualifies once it has a route into that VNet and the domain resolves privately |
| App with external ingress in an internal environment | The app accepts outside traffic through the environment's private entry |
Ingress dalaman didedahkan pada pengimbang beban dalaman persekitaran di dalam VNet persekitaran, jadi soalannya bukan sama ada komputer riba itu aplikasi kontena lain, tetapi sama ada ia boleh mencapai VNet itu. Klien VPN dengan laluan ke VNet dan domain lalai persekitaran yang diselesaikan melalui zon peribadi ialah pemanggil yang layak, dan itulah yang dibina oleh langkah selebihnya. Persekitaran dalaman tanpa entri awam ialah fakta berbeza daripada aplikasi dengan ingress dalaman, dan ingress luaran pada peringkat aplikasi tidak memberi persekitaran pintu awam. Tulis skop itu dalam tiket dan juga dalam portal, kerana jurutera seterusnya membaca tiket dahulu.
Sahkan skop itu dengan pemilik konfigurasi sebelum meneruskan, dan kekalkan pintu itu sempit: jika tiada laluan ke VNet persekitaran, atau domain lalai persekitaran tidak diselesaikan melalui zon peribadi, berhenti dan betulkan laluan itu dahulu. Tiada langkah kemudian boleh menggantikan pemanggil yang tidak dapat mencapai VNet atau menyelesaikan nama.
Langkah 2: kumpulkan nama hos sebenar dan alamat entri
Catat domain lalai persekitaran, alamat entri peribadi statiknya dan FQDN aplikasi yang dikonfigurasikan, diambil daripada sumber dan bukan daripada tangkapan skrin lama atau halaman wiki:
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"Panduan entri peribadi Container Apps menerangkan pemadanan domain persekitaran dengan alamat dalamannya sambil mengekalkan nama hos aplikasi tanpa diubah. Itulah bentuk yang anda bina secara manual di sini, jadi selaraskan kandungan zon dengannya dan bukannya mencipta skema penamaan baharu.
Jika domain yang anda baca tidak sepadan dengan FQDN yang dilaporkan oleh aplikasi, berhenti dan selaraskan kedua-duanya sekarang. Membina zon pada akhiran yang salah menghasilkan nama hos yang diselesaikan dengan sempurna dan tetap mendarat pada hos maya yang salah.
Langkah 3: letakkan zon peribadi pada laluan penyelesai VPN
Cipta atau guna semula zon DNS peribadi yang disokong untuk domain lalai sebenar persekitaran, dengan rekod wildcard dan alamat yang didokumenkan menunjuk ke entri statik. Pautkan zon itu ke rangkaian maya yang sesuai, dan jadikan kuasa peribadi boleh dicapai melalui laluan penyelesai VPN yang diluluskan dan bukannya menganggap pautan itu mencukupi.
Klien titik ke tapak biasanya memerlukan titik akhir masuk penyelesai peribadi atau penghantar DNS yang disokong untuk mencapai zon itu. Memautkan zon mengubah apa yang diselesaikan oleh Azure untuk rangkaian berpaut; ia tidak mengubah hala penyelesai awam setiap komputer riba luaran. Jangan gantikannya dengan zon DNS titik akhir peribadi yang dipinjam daripada model rangkaian Container Apps lain, kerana nama rekod dan akhiran zon tidak akan sepadan.
Pembalikan untuk langkah ini ialah membuang pautan zon atau rekod yang anda tambah. Catat yang mana satu daripadanya, kerana memadam zon dikongsi untuk membatalkan satu pautan ialah cara yang terkenal untuk merosakkan persekitaran kedua.
Langkah 4: uji nama, kemudian audiens yang dinafikan
Uji nama hos dan identiti TLS bersama-sama, bukan alamat sahaja. Untuk diagnostik pemetaan nama terkawal anda boleh menyematkan alamat sambil mengekalkan nama hos:
curl --resolve app.ENVIRONMENT_DOMAIN:443:10.40.0.10 \
https://app.ENVIRONMENT_DOMAIN/Gantikan nama hos dengan FQDN sebenar aplikasi dan alamat dengan entri dalaman sebenar. Ini hanya mempengaruhi satu permintaan itu dan bukan peruntukan DNS. Jangan tambah -k untuk menukar kegagalan identiti menjadi lulus yang kelihatan, kerana ketidakpadanan sijil ialah isyarat bahawa anda memukul pendengar yang salah.
Meminta alamat berangka secara langsung boleh memilih hos maya yang salah atau menggagalkan pengesahan walaupun TCP 443 menjawab, jadi anggap ujian IP yang berjaya sebagai bukti tentang rangkaian dan tidak lebih. Dari komputer riba yang dimaksudkan, laluan penyelesai biasa ialah penghantar DNS klien atau titik akhir masuk penyelesai peribadi yang mengehos zon, dan kegagalan di situ ialah masalah kebolehcapaian penyelesai, bukan rekod yang hilang. Sahkan bahawa permintaan yang sama berjaya pada laluan itu, kemudian sahkan bahawa audiens yang dinafikan masih dinafikan.
Apa yang perlu direkodkan dan apa yang perlu dibalikkan
Port sasaran kontena dan port HTTPS klien ialah tetapan berasingan. Jangan terbitkan port sasaran kontena melalui VPN kerana kontena mendengar di situ, dan jangan luaskan peraturan rangkaian untuk meluluskan ujian port. Kedua-dua perubahan bertahan selepas insiden dan sukar dikaitkan kemudian.
Akhiri dengan operasi aplikasi baharu dari komputer riba yang dimaksudkan, menggunakan identiti sahnya dan DNS biasa, kemudian semak bahawa pemanggil tidak sah masih gagal. Semasa anda dalam konfigurasi aplikasi, sahkan juga sama ada laluan HTTP pada peringkat persekitaran mendedahkan aplikasi ini sebagai sasaran, kerana laluan itu ialah pintu kedua yang tidak diterangkan oleh skop ingress.
Catat lima nilai bersama-sama: skop persekitaran, skop ingress aplikasi, FQDN, alamat entri peribadi dan pemilik penyelesai. Kelima-lima itu menerangkan keseluruhan kontrak akses, dan orang seterusnya yang akan menyahpepijatnya akan meminta tepat kelima-lima itu.