Kam umístit NSG pro provoz Azure VPN typu site-to-site

Tunel site-to-site je nahoře, místní klient dosáhne na některé hostitele Azure a na jiné ne a někdo kvůli tomu přidal na GatewaySubnet skupinu zabezpečení sítě. Zastavte se tady. Azure nepodporuje NSG na GatewaySubnet a skupina nevidí vnitřní paket tak jako pravidlo zátěže. Umístěte zásadu na cílovou podsíť nebo NIC, slaďte zdrojovou adresu, která existuje po dešifrování, a pak to ověřte novým připojením, ne starým.

Umístěte NSG tam, kde ho Azure vyhodnocuje

Podporovanou hranicí pro filtrování zátěže je cílová podsíť nebo cílové síťové rozhraní. Podsíť brány je infrastruktura a Azure dokumentuje, že NSG tam nejsou podporovány a mohou zhoršit provoz brány.

S umístěním je i logický problém. NSG na GatewaySubnet by vyhodnocoval vnější výměnu IPsec, jejíž adresy patří oběma branám. Vaše pravidlo aplikace potřebuje privátní zdroj uvnitř tunelu a tento paket existuje až poté, co ho brána dešifruje. Připojte skupinu k podsíti zátěže a pravidlo uvidí adresu, pro kterou bylo napsáno.

Před jakoukoli změnou zkontrolujte současná přidružení, abyste věděli, co přesouváte:

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

Najděte zdrojovou adresu po dešifrování

Vnitřní zdroj je privátní adresa místního klienta nebo adresa, kterou zařízení či NAT VPN předkládá po překladu. Není to veřejná adresa místní brány VPN, která patří vnější výměně.

Když je NAT součástí návrhu, potvrďte předkládaný zdroj, místo abyste ho předpokládali. Zachytávání paketů na VM Azure nebo pole zdroje v protokolu připojení služby vyřeší otázku rychleji než čtení místní konfigurace. Potom napište pravidlo proti této adrese a skutečnému cílovému portu.

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

Použijte jedno pravidlo na každou službu, kterou chcete vystavit, a držte seznam portů krátký. Pravidlo, které povolí všechny porty z místního rozsahu, mění NSG ve formalitu.

Zkontrolujte výchozí rozsah VirtualNetwork

Značka služby VirtualNetwork je širší než místní virtuální síť. Její definice zahrnuje připojené místní adresní prostory, sítě propojené peeringem a další prefixy připojené přes bránu. Výchozí pravidlo povolení omezené na VirtualNetwork tak už může povolit provoz tunelu, který operátor považoval za vnější.

Přečtěte si výchozí pravidla, než přidáte úzká, a přečtěte si každé pravidlo s vyšší prioritou, které by mohlo odpovídat první. Přidání výslovného povolení neodstraní širší pravidlo, které tok už povoluje. Kde zásada vyžaduje zamítnutí, umístěte ho na prioritu, která se skutečně vyhodnotí před povolením.

Dokumentace Microsoftu ke značkám služeb uvádí, co značka VirtualNetwork pokrývá, a je to odkaz, který citujete, když někdo tvrdí, že značka znamená jen rozsah VNet.

Přečtěte si efektivní pravidla na obou hranicích

Když platí NSG podsítě i NSG NIC, tok musí splnit oba. Povolení v jednom neruší zamítnutí ve druhém a paket skutečně potkává souhrnný pohled.

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

Pokud se uplatňují pravidla správce zabezpečení Azure Virtual Network Manager, projděte i tuto vrstvu. Administrátorské pravidlo Always allow může doručit provoz bez vyhodnocení NSG, zatímco administrátorské Deny ho zastaví dřív, než ho NSG uvidí. Revize pouze NSG je pro takové uspořádání neúplná.

Pamatujte, že NSG jsou stavové. Úprava pravidla nemusí ukončit existující povolené připojení, takže přejímací test potřebuje nový tok. Tato vlastnost je užitečná v produkci a zavádějící během změnového okna.

Ověřte novým připojením

Otevřete novou relaci z místního klienta na port služby a pak to zopakujte z hostitele, který má být odmítnut. Spusťte test toku i ze strany VM, abyste věděli, že zpětná cesta je v pořádku.

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

Povolení v NSG je jedno rozhodnutí o přístupu, ne trasa a ne posluchač. Pokud pravidlo tok povolí a připojení přesto selže, zkontrolujte trasu klienta do VPN, zpětnou trasu Azure a firewall hostitele, než skupinu znovu upravíte. Zaznamenejte skutečnou zdrojovou adresu, přidružení NSG a odpovídající pravidlo spolu se schválenou službou, protože další změna peeringu nebo trasy může změnit, co značka VirtualNetwork pokrývá.