Jak aplikacja internetowa platformy Azure dociera do środowiska lokalnego za pośrednictwem sieci VPN

Żądanie wychodzące aplikacji internetowej opuszcza pracownika, którego nigdy nie widzisz, z niewybranego źródła, a zapora sieciowa biura musi je zaakceptować. Oto cały problem w jednym zdaniu. Integracja regionalnej sieci wirtualnej zapewnia żądanie ścieżkę do sieci wirtualnej, a stamtąd sieć VPN typu lokacja-lokacja przenosi je. Wszystko, co później pójdzie nie tak, dotyczy zakresu źródła i trasy, z której faktycznie korzystał pakiet.

Co faktycznie wysyła pracownik

App Service uruchamia Twój kod na pracownikach znajdujących się poza widokiem sieci Twojej subskrypcji. Po włączeniu integracji regionalnej ruch wychodzący jest przekazywany do delegowanej podsieci w sieci wirtualnej w tym samym regionie, a pakiet pojawia się tam, zanim będzie kontynuowany. Integracja nie przenosi aplikacji do sieci wirtualnej i nie zmienia jej adresu przychodzącego. Nadaje przepływom wychodzącym inny pierwszy przeskok.

Domyślnie tą ścieżką podąża tylko prywatna przestrzeń adresowa, więc zwykłe miejsca docelowe w Internecie nadal są opuszczane bezpośrednio przez proces roboczy. Routowanie wszystkiego przez sieć wirtualną to osobne ustawienie i osobna decyzja, ponieważ powoduje to także przesłanie przez tunel Twoich zależności publicznych.

Ruch konfiguracyjny, taki jak pobieranie obrazu kontenera przy uruchomieniu, podlega własnym regułom routingu i może zakończyć się niepowodzeniem, jeśli wywołania interfejsu API powiodą się.

Podsieć integracji jest źródłem, na które musisz zezwolić

Biuro widzi zakres adresów podsieci integracji lub cokolwiek, na co urządzenie go tłumaczy, a nie publiczne adresy wychodzące aplikacji. Umieść ten zakres w selektorach ruchu sieci VPN lokacji i w lokalnej regule zapory. Jeśli tunel jest oparty na zasadach, selektory, które go pomijają, odrzucają pakiet nawet jeśli trasa istnieje.

Nie zezwalaj na pojedynczy adres pracownika, który zdarzyło Ci się zaobserwować. Instancje zmieniają się wraz ze skalowaniem i konserwacją platformy, a reguła przypięta do jednego adresu psuje się w najgorszym momencie.

Utrzymuj wąską stronę docelową: jedna usługa, jeden port, jeden kierunek, z wyraźnie dozwoloną ścieżką powrotną.

Łączenie równorzędne i tranzyt przez bramę są jawne

Jeśli brama VPN znajduje się w koncentrującej sieci wirtualnej, a podsieć integracji w szprysze, ścieżka wymaga zezwolenia na tranzyt bramy w komunikacji równorzędnej koncentratora i włączonego korzystania z bramy zdalnej w komunikacji równorzędnej szprych. Samo połączenie równorzędne przenosi ruch między dwiema sieciami wirtualnymi i nic więcej. Efektywne trasy w podsieci integracji to miejsca, w których można potwierdzić, że naprawdę istnieje następny przeskok bramy.

Projekt typu hub-and-szprychy, w którym tabela tras wysyła 0.0.0.0/0 do zapory ogniowej, jest powszechnym wariantem, a zapora ta potrzebuje wówczas własnej reguły dla prefiksu lokalnego.

Narysuj ścieżkę na papierze przed otwarciem biletu z zespołem sieci, ponieważ oszczędza to dzień zgadywania. Uwzględnij na rysunku kierunek powrotu, ponieważ to połowa ludzi zapomina.

Przychodzący prywatny punkt końcowy to inny kierunek

Prywatny punkt końcowy umożliwia dostęp do aplikacji z poziomu sieci wirtualnej. Nie ma to żadnego wpływu na połączenia wychodzące aplikacji z biurem, a zespoły regularnie je konfigurują, podczas gdy rzeczywiste wymagania były odwrotne.

Starsza dokumentacja opisuje integrację wymaganą przez bramę, opartą na sieci VPN typu punkt-lokacja, co stanowi inną funkcję z własnymi wymaganiami. Firma Microsoft planuje wycofanie tej funkcji na 31 marca 2027 r. i zamiast tego zaleca integrację regionalną.

Nie kopiuj starszej konfiguracji typu punkt-lokacja tylko dlatego, że korzystała z niej stary przykład.

Sprawdź, korzystając z własnego kontekstu aplikacji

Testuj we wdrożonej aplikacji, a nie na laptopie ani na maszynie wirtualnej w tej samej sieci wirtualnej. Rejestruj oddzielnie rozpoznany adres, wynik połączenia i odpowiedź na poziomie aplikacji, ponieważ wystąpiła awaria DNS, przekroczono limit czasu protokołu TCP i punkt odrzucenia uwierzytelnienia u trzech różnych właścicieli. Jeśli rozpoznawanie nazw nie powiedzie się, napraw prywatny DNS dla sieci wirtualnej przed dotknięciem tunelu.

Stan zielonego tunelu potwierdza jedynie, że brama działa. Nie mówi nic o selektorach, regułach zapory sieciowej ani DNS.

Gdy żądanie w końcu zadziała, zapisz zakres źródłowy, port docelowy i strefę DNS w elemencie Runbook aplikacji. Następna osoba, która będzie to debugować, zacznie od Twojej notatki, a nie od strony stanu bramy.