Menjangkau aplikasi Container Apps privat melalui VPN point-to-site
Lingkungan Container Apps internal membutuhkan entri privat, nama host yang cocok, dan resolver yang dapat dijangkau VPN. Jalankan setiap langkah, lalu verifikasi penolakan.
Runbook ini mencakup lingkungan Container Apps dengan profil beban kerja dan entri jaringan virtual internal, yang dijangkau dari laptop melalui VPN point-to-site yang disetujui, menggunakan FQDN langsung aplikasi dan tanpa rute HTTP tingkat lingkungan. entri lingkungan dapat dijangkau dari klien, cakupan ingress aplikasi menerima pemanggil, dan nama host diselesaikan ke entri privat. Setiap langkah di bawah menyisakan hasil yang dapat diverifikasi dan rollback yang tidak menyentuh apa pun yang tidak Anda ubah. Kerjakan sesuai urutan yang diberikan, karena tidak ada langkah berikutnya yang dapat mengompensasi keputusan cakupan yang salah di langkah 1.
Sebelum menyentuh DNS, tuntaskan kata internal. Kata itu dipakai untuk dua cakupan berbeda di produk ini, dan menukarnya adalah penyebab paling umum nama yang berfungsi tetap tidak mengembalikan apa pun yang berguna.
Langkah 1: tetapkan cakupan lingkungan dan aplikasi
Baca konfigurasi ingress aplikasi sebelum mengubah catatan apa pun:
| 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 internal diekspos pada penyeimbang beban internal lingkungan di dalam VNet lingkungan, jadi pertanyaannya bukan apakah laptop itu aplikasi kontainer lain, melainkan apakah ia dapat menjangkau VNet tersebut. Klien VPN dengan rute ke VNet dan domain default lingkungan yang diselesaikan melalui zona privat adalah pemanggil yang memenuhi syarat, dan itulah yang dibangun oleh langkah-langkah selanjutnya. Lingkungan internal tanpa entri publik adalah fakta berbeda dari aplikasi dengan ingress internal, dan ingress eksternal di tingkat aplikasi tidak memberi lingkungan pintu publik. Tulis cakupan itu di tiket maupun di portal, karena teknisi berikutnya membaca tiket lebih dulu.
Konfirmasikan cakupan itu dengan pemilik konfigurasi sebelum melanjutkan, dan jaga gerbang tetap sempit: jika tidak ada rute ke VNet lingkungan, atau domain default lingkungan tidak diselesaikan melalui zona privat, berhenti dan perbaiki jalur itu lebih dulu. Tidak ada langkah berikutnya yang dapat menggantikan pemanggil yang tidak dapat menjangkau VNet atau menyelesaikan nama.
Langkah 2: kumpulkan nama host dan alamat entri yang sebenarnya
Catat domain default lingkungan, alamat entri privat statisnya, dan FQDN aplikasi yang dikonfigurasi, yang diambil dari sumber daya dan bukan dari tangkapan layar 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 privat Container Apps menjelaskan pencocokan domain lingkungan dengan alamat internalnya sambil menjaga nama host aplikasi tetap utuh. Itulah bentuk yang Anda bangun secara manual di sini, jadi selaraskan isi zona dengannya alih-alih mengarang skema penamaan baru.
Jika domain yang Anda baca tidak cocok dengan FQDN yang dilaporkan aplikasi, berhenti dan rekonsiliasikan sekarang. Membangun zona pada sufiks yang salah menghasilkan nama host yang terselesaikan sempurna dan tetap mendarat di host virtual yang salah.
Langkah 3: letakkan zona privat di jalur resolver VPN
Buat atau gunakan kembali zona DNS privat yang didukung untuk domain default aktual lingkungan, dengan catatan wildcard dan alamat terdokumentasi yang mengarah ke entri statis. Tautkan zona itu ke jaringan virtual yang sesuai, dan buat otoritas privat dapat dijangkau melalui jalur resolver VPN yang disetujui alih-alih menganggap tautannya cukup.
Klien point-to-site biasanya memerlukan titik akhir masuk resolver privat atau penerus DNS yang didukung untuk menjangkau zona itu. Menautkan zona mengubah apa yang diselesaikan Azure untuk jaringan yang ditautkan; itu tidak mengalihkan resolver publik setiap laptop eksternal. Jangan menggantinya dengan zona DNS titik akhir privat yang dipinjam dari model jaringan Container Apps lain, karena nama catatan dan sufiks zona tidak akan sejajar.
Rollback untuk langkah ini adalah menghapus tautan zona atau catatan yang Anda tambahkan. Catat yang mana di antara keduanya, karena menghapus zona bersama untuk membatalkan satu tautan adalah cara yang terkenal untuk merusak lingkungan kedua.
Langkah 4: uji nama, lalu audiens yang ditolak
Uji nama host dan identitas TLS bersama-sama, bukan hanya alamatnya. Untuk diagnostik pemetaan nama yang terkendali Anda dapat menyematkan alamat sambil mempertahankan nama host:
curl --resolve app.ENVIRONMENT_DOMAIN:443:10.40.0.10 \
https://app.ENVIRONMENT_DOMAIN/Ganti nama host dengan FQDN aplikasi yang sebenarnya dan alamat dengan entri internal yang sebenarnya. Ini hanya memengaruhi satu permintaan itu dan bukan penyediaan DNS. Jangan tambahkan -k untuk mengubah kegagalan identitas menjadi lolos semu, karena ketidakcocokan sertifikat adalah sinyal bahwa Anda mengenai pendengar yang salah.
Meminta alamat numerik secara langsung dapat memilih host virtual yang salah atau menggagalkan validasi bahkan saat TCP 443 menjawab, jadi perlakukan uji IP yang berhasil sebagai bukti tentang jaringan dan tidak lebih. Dari laptop yang dimaksud, jalur resolver normal adalah penerus DNS klien atau titik akhir masuk resolver privat yang meng-hosting zona, dan kegagalan di sana adalah masalah keterjangkauan resolver, bukan catatan yang hilang. Konfirmasikan bahwa permintaan yang sama berhasil pada jalur itu, lalu konfirmasikan bahwa audiens yang ditolak masih ditolak.
Apa yang dicatat dan apa yang di-rollback
Port target kontainer dan port HTTPS klien adalah pengaturan terpisah. Jangan publikasikan port target kontainer melalui VPN karena kontainer mendengarkan di sana, dan jangan perluas aturan jaringan agar uji port lolos. Kedua perubahan bertahan setelah insiden dan sulit diatribusikan nanti.
Akhiri dengan operasi aplikasi baru dari laptop yang dimaksud, menggunakan identitas yang diotorisasi dan DNS normalnya, lalu periksa bahwa pemanggil tidak sah masih gagal. Selagi Anda berada di konfigurasi aplikasi, konfirmasikan juga apakah rute HTTP tingkat lingkungan mengekspos aplikasi ini sebagai target, karena rute itu adalah pintu kedua yang tidak dijelaskan cakupan ingress.
Catat lima nilai bersama-sama: cakupan lingkungan, cakupan ingress aplikasi, FQDN, alamat entri privat, dan pemilik resolver. Kelima nilai itu menjelaskan seluruh kontrak akses, dan orang berikutnya yang akan men-debug-nya akan meminta persis kelima itu.