Gdzie stosować NSG dla ruchu VPN typu site-to-site w Azure

Tunel site-to-site działa, klient lokalny dociera do niektórych hostów Azure, a do innych nie, i ktoś podłączył sieciową grupę zabezpieczeń do GatewaySubnet, aby to naprawić. Zatrzymaj się tutaj. Azure nie obsługuje NSG na GatewaySubnet, a grupa nie widzi pakietu wewnętrznego tak jak reguła obciążenia. Umieść zasady w podsieci lub karcie sieciowej miejsca docelowego, dopasuj adres źródłowy, który istnieje po odszyfrowaniu, a następnie sprawdź nowym, a nie starym połączeniem.

Umieść NSG tam, gdzie Azure go ocenia

Obsługiwaną granicą filtrowania obciążenia jest podsieć lub interfejs sieciowy miejsca docelowego. Podsieć bramy to infrastruktura, a Azure dokumentuje, że NSG nie są tam obsługiwane i mogą pogorszyć działanie bramy.

Jest też problem logiczny z umiejscowieniem. NSG na GatewaySubnet oceniałby wymianę IPsec zewnętrzną, której adresy należą do obu bram. Reguła aplikacji potrzebuje prywatnego źródła wewnątrz tunelu, a ten pakiet istnieje dopiero po odszyfrowaniu przez bramę. Podłącz grupę do podsieci obciążenia, a reguła zobaczy adres, dla którego została napisana.

Sprawdź bieżące skojarzenia, zanim cokolwiek zmienisz, aby wiedzieć, co przenosisz:

az network vnet subnet show -g rg-net -n snet-app --vnet-name vnet-prod --query networkSecurityGroup.id
az network vnet subnet show -g rg-net -n GatewaySubnet --vnet-name vnet-prod --query networkSecurityGroup.id

Znajdź adres źródłowy po odszyfrowaniu

Źródło wewnętrzne to prywatny adres klienta lokalnego albo adres, który urządzenie lub NAT VPN przedstawia po translacji. To nie jest publiczny adres lokalnej bramy VPN, który należy do wymiany zewnętrznej.

Gdy NAT jest częścią projektu, potwierdź przedstawiane źródło, zamiast je zakładać. Przechwycenie pakietów na maszynie wirtualnej Azure albo pole źródła w dzienniku połączeń usługi rozstrzyga kwestię szybciej niż czytanie konfiguracji lokalnej. Następnie napisz regułę dla tego adresu i rzeczywistego portu docelowego.

az network nsg rule create -g rg-net --nsg-name nsg-app -n allow-onprem-https --priority 200 --direction Inbound --access Allow --protocol Tcp --source-address-prefixes 192.168.10.0/24 --destination-address-prefixes 10.1.2.0/24 --destination-port-ranges 443

Używaj jednej reguły na usługę, którą chcesz udostępnić, i utrzymuj krótką listę portów. Reguła zezwalająca na wszystkie porty z zakresu lokalnego czyni NSG formalnością.

Sprawdź domyślny zakres VirtualNetwork

Tag usługi VirtualNetwork jest szerszy niż lokalna sieć wirtualna. Jego definicja obejmuje połączone lokalne przestrzenie adresowe, sieci połączone peeringiem i inne prefiksy połączone przez bramę. Dlatego domyślna reguła zezwolenia ograniczona do VirtualNetwork może już zezwalać na ruch tunelu, który operator uważał za zewnętrzny.

Przeczytaj reguły domyślne, zanim dodasz wąskie, i przeczytaj każdą regułę o wyższym priorytecie, która może pasować jako pierwsza. Dodanie jawnego zezwolenia nie usuwa szerszej reguły, która już zezwala na przepływ. Tam, gdzie zasady wymagają odmowy, umieść ją na priorytecie, który naprawdę jest oceniany przed zezwoleniem.

Dokumentacja Microsoftu dotycząca tagów usług wymienia, co obejmuje tag VirtualNetwork, i to jest odniesienie, które się cytuje, gdy ktoś twierdzi, że tag oznacza tylko zakres sieci wirtualnej.

Przeczytaj reguły efektywne na obu granicach

Gdy obowiązuje zarówno NSG podsieci, jak i NSG karty sieciowej, przepływ musi spełniać oba. Zezwolenie w jednym nie unieważnia odmowy w drugim, a pakiet naprawdę napotyka widok zbiorczy.

az network nic show-effective-nsg -g rg-net -n vm-app-nic -o table

Jeśli w grę wchodzą reguły administratora zabezpieczeń Azure Virtual Network Manager, przejrzyj też tę warstwę. Reguła administracyjna Always allow może dostarczyć ruch bez oceny NSG, a Deny administracyjna zatrzymuje go, zanim NSG go zobaczą. Przegląd tylko NSG jest niepełny dla takiego układu.

Pamiętaj, że NSG są stanowe. Edycja reguły niekoniecznie kończy istniejące dozwolone połączenie, więc test akceptacyjny wymaga nowego przepływu. Ta właściwość jest przydatna w produkcji i myląca w okienku zmian.

Sprawdź nowym połączeniem

Otwórz nową sesję z klienta lokalnego do portu usługi, a następnie powtórz to z hosta, który powinien zostać odrzucony. Uruchom test przepływu także po stronie maszyny wirtualnej, aby wiedzieć, że droga powrotna jest nienaruszona.

az network watcher test-ip-flow -g rg-net --vm vm-app --direction Inbound --protocol Tcp --local 10.1.2.4:443 --remote 192.168.10.50:51515

Zezwolenie NSG to jedna decyzja o dostępie, nie trasa i nie nasłuch. Jeśli reguła zezwala na przepływ, a połączenie nadal nie działa, sprawdź trasę klienta do VPN, trasę powrotną Azure i zaporę hosta, zanim ponownie edytujesz grupę. Zapisz rzeczywisty adres źródłowy, skojarzenia NSG i pasującą regułę wraz z zatwierdzoną usługą, ponieważ następna zmiana peeringu lub trasy może zmienić to, co obejmuje tag VirtualNetwork.