Dostęp do prywatnej aplikacji Container Apps przez VPN punkt-lokalizacja

Ten runbook obejmuje środowisko Container Apps z profilami obciążenia i wewnętrznym wejściem w sieci wirtualnej, osiąganym z laptopa przez zatwierdzony VPN typu punkt-lokalizacja, z użyciem bezpośredniego FQDN aplikacji i bez tras HTTP na poziomie środowiska. wejście środowiska jest osiągalne z klienta, zakres ruchu przychodzącego aplikacji dopuszcza wywołującego, a nazwa hosta jest rozwiązywana na prywatne wejście. Każdy krok poniżej pozostawia weryfikowalny wynik i wycofanie, które nie dotyka niczego, czego nie zmieniono. Przejdź przez nie w podanej kolejności, ponieważ żaden późniejszy krok nie zrekompensuje błędnie podjętej decyzji o zakresie w kroku 1.

Zanim dotkniesz DNS, wyjaśnij słowo wewnętrzny. W tym produkcie używa się go w dwóch różnych zakresach, a ich pomylenie jest najczęstszą przyczyną, dla której działająca nazwa nadal nie zwraca niczego użytecznego.

Krok 1: ustal zakres środowiska i aplikacji

Przeczytaj konfigurację ruchu przychodzącego aplikacji, zanim zmienisz jakikolwiek rekord:

Wewnętrzny ruch przychodzący jest wystawiony na wewnętrznym równoważeniu obciążenia środowiska wewnątrz VNet środowiska, więc pytanie nie brzmi, czy laptop jest inną aplikacją kontenerową, ale czy może dotrzeć do tej VNet. Klient VPN z trasą do VNet i domyślną domeną środowiska rozwiązywaną przez strefę prywatną jest kwalifikującym się wywołującym, i dokładnie to budują pozostałe kroki. Wewnętrzne środowisko bez wejścia publicznego to inny fakt niż aplikacja z wewnętrznym ruchem przychodzącym, a zewnętrzny ruch przychodzący na poziomie aplikacji nie daje środowisku publicznych drzwi. Zapisuj zakres w zgłoszeniu oraz w portalu, ponieważ następny inżynier najpierw czyta zgłoszenie.

Potwierdź ten zakres z właścicielem konfiguracji, zanim przejdziesz dalej, i trzymaj bramę wąsko: jeśli nie istnieje trasa do VNet środowiska albo domyślna domena środowiska nie jest rozwiązywana przez strefę prywatną, zatrzymaj się i najpierw napraw tę ścieżkę. Żaden późniejszy krok nie zastąpi wywołującego, który nie może dotrzeć do VNet ani rozwiązać nazwy.

Krok 2: zbierz prawdziwą nazwę hosta i adres wejścia

Zapisz domyślną domenę środowiska, jego statyczny prywatny adres wejścia i skonfigurowany FQDN aplikacji, wzięte z zasobu, a nie ze starego zrzutu ekranu lub strony 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"

Wskazówki dotyczące prywatnego wejścia Container Apps opisują dopasowanie domeny środowiska do jego adresu wewnętrznego przy zachowaniu nienaruszonych nazw hostów aplikacji. To dokładnie ten kształt, który budujesz tu ręcznie, więc dopasuj zawartość strefy do niego, zamiast wymyślać nowy schemat nazewnictwa.

Jeśli odczytana domena nie zgadza się z FQDN raportowanym przez aplikację, zatrzymaj się i uzgodnij je teraz. Budowanie strefy na złym sufiksie daje nazwę hosta, która rozwiązuje się idealnie i mimo to trafia na zły host wirtualny.

Krok 3: umieść strefę prywatną na ścieżce resolvera VPN

Utwórz lub użyj ponownie obsługiwanej strefy DNS prywatnej dla rzeczywistej domeny domyślnej środowiska, z udokumentowanymi rekordami wieloznacznymi i adresowymi wskazującymi na statyczne wejście. Połącz tę strefę z odpowiednią siecią wirtualną i udostępnij prywatny organ przez zatwierdzoną ścieżkę resolvera VPN, zamiast zakładać, że połączenie wystarczy.

Klient typu punkt-lokalizacja zwykle potrzebuje przychodzącego punktu końcowego prywatnego resolvera lub obsługiwanego przekazywania DNS, aby dotrzeć do tej strefy. Połączenie strefy zmienia to, co Azure rozwiązuje dla połączonych sieci; nie przekierowuje publicznego resolvera każdego zewnętrznego laptopa. Nie zastępuj jej strefą DNS prywatnego punktu końcowego pożyczoną z innego modelu sieci Container Apps, ponieważ nazwy rekordów i sufiks strefy nie będą się zgadzać.

Wycofanie tego kroku to usunięcie połączenia strefy lub dodanego rekordu. Zapisz, które z tych dwóch to było, ponieważ usunięcie współdzielonej strefy, aby cofnąć jedno połączenie, to dobrze znany sposób zepsucia drugiego środowiska.

Krok 4: przetestuj nazwę, a następnie odrzuconą publiczność

Testuj nazwę hosta i tożsamość TLS razem, nie tylko adres. Do kontrolowanej diagnostyki mapowania nazw możesz przypiąć adres, zachowując nazwę hosta:

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

Zastąp nazwę hosta prawdziwym FQDN aplikacji, a adres prawdziwym wewnętrznym wejściem. Dotyczy to tylko tego jednego żądania i nie jest provisionowaniem DNS. Nie dodawaj -k, aby zamienić błąd tożsamości w pozorne przejście, ponieważ niezgodność certyfikatu jest sygnałem, że trafiasz w niewłaściwego odbiorcę.

Bezpośrednie żądanie adresu numerycznego może wybrać zły host wirtualny lub spowodować niepowodzenie walidacji nawet wtedy, gdy TCP 443 odpowiada, więc udany test IP traktuj jako dowód o sieci i nic więcej. Z zamierzonego laptopa normalna ścieżka resolvera to przekazywanie DNS klienta lub przychodzący punkt końcowy prywatnego resolvera hostującego strefę, a błąd tam jest problemem osiągalności resolvera, a nie brakującym rekordem. Potwierdź, że to samo żądanie się udaje na tej ścieżce, a następnie potwierdź, że odrzucona publiczność nadal jest odrzucana.

Co zapisać i co wycofać

Docelowy port kontenera i port HTTPS klienta to osobne ustawienia. Nie publikuj docelowego portu kontenera przez VPN, ponieważ kontener tam nasłuchuje, i nie rozszerzaj reguły sieciowej, aby test portu przeszedł. Obie zmiany przeżywają incydent i później trudno je przypisać.

Zakończ świeżą operacją aplikacji z zamierzonego laptopa, z jego autoryzowaną tożsamością i normalnym DNS, a następnie sprawdź, że nieautoryzowany wywołujący nadal zawodzi. Będąc w konfiguracji aplikacji, potwierdź też, czy trasa HTTP na poziomie środowiska wystawia tę aplikację jako cel, ponieważ ta trasa to drugie drzwi, których zakres ruchu przychodzącego nie opisuje.

Zapisz pięć wartości razem: zakres środowiska, zakres ruchu przychodzącego aplikacji, FQDN, prywatny adres wejścia i właściciela resolvera. Te pięć opisuje całą umowę dostępu, a następna osoba, która będzie to debugować, poprosi dokładnie o nie.