Hol alkalmazzuk az NSG-ket az Azure site-to-site VPN-forgalmánál

A site-to-site alagút él, a helyi ügyfél elér néhány Azure-gazdagépet, másokat nem, és valaki hálózati biztonsági csoportot csatolt a GatewaySubnethez, hogy ezt javítsa. Álljon meg ott. Az Azure nem támogatja az NSG-t a GatewaySubneten, és a csoport nem látja a belső csomagot úgy, ahogy a munkaterhelés-szabály. Helyezze a házirendet a célalhálózatra vagy a NIC-re, egyeztesse a visszafejtés után létező forrás-címet, majd új kapcsolattal ellenőrizze, ne régivel.

Helyezze az NSG-t oda, ahol az Azure kiértékeli

A munkaterhelés-szűrés támogatott határa a célalhálózat vagy a cél-hálózati illesztő. Az átjáró-alhálózat infrastruktúra, és az Azure dokumentálja, hogy ott az NSG-k nem támogatottak, és károsíthatják az átjáró működését.

Az elhelyezéssel logikai probléma is van. A GatewaySubneten lévő NSG a külső IPsec-cserét értékelné, amelynek címei a két átjáróhoz tartoznak. Az alkalmazásszabálynak az alagúton belüli magánforrásra van szüksége, és az a csomag csak azután létezik, hogy az átjáró visszafejti. Csatolja a csoportot a munkaterhelés alhálózatához, és a szabály látni fogja a címet, amelyre írták.

Bármilyen változtatás előtt ellenőrizze a jelenlegi társításokat, hogy tudja, mit mozgat:

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

Keresse meg a forráscímet a visszafejtés után

A belső forrás a helyi ügyfél magáncíme, vagy az a cím, amelyet egy eszköz vagy a VPN NAT a fordítás után bemutat. Ez nem a helyi VPN-átjáró nyilvános címe, amely a külső cseréhez tartozik.

Amikor a NAT a tervezés része, erősítse meg a bemutatott forrást ahelyett, hogy feltételezné. Az Azure VM-en végzett csomagrögzítés vagy a szolgáltatás kapcsolati naplójának forrásmezője gyorsabban eldönti a kérdést, mint a helyi konfiguráció olvasása. Ezután írja meg a szabályt arra a címre és a valódi célportra.

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

Egy szabályt használjon szolgáltatásonként, amelyet ki akar tenni, és tartsa rövid a portlistát. Az a szabály, amely a helyi tartomány minden portját engedi, formalitássá teszi az NSG-t.

Ellenőrizze a VirtualNetwork alapértelmezett hatókörét

A VirtualNetwork szolgáltatáscímke szélesebb, mint a helyi virtuális hálózat. Definíciója magában foglalja a csatlakoztatott helyi címtereket, a peeringelt hálózatokat és az átjáróhoz kapcsolt egyéb előtagokat. Ezért a VirtualNetworkre korlátozott alapértelmezett engedélyező szabály már engedélyezhet olyan alagútforgalmat, amelyet az üzemeltető külsőnek hitt.

Olvassa el az alapértelmezett szabályokat, mielőtt szűkeket ad hozzá, és olvassa el minden magasabb prioritású szabályt, amely elsőként illeszkedhet. Egy kifejezett engedély hozzáadása nem távolít el egy szélesebb szabályt, amely már engedi a folyamot. Ahol a házirend tiltást ír elő, azt olyan prioritásra tegye, amelyet ténylegesen az engedély előtt értékelnek.

A Microsoft szolgáltatáscímkékről szóló dokumentációja felsorolja, mit fed le a VirtualNetwork címke, és ez az a hivatkozás, amelyet idézni kell, amikor valaki azt állítja, hogy a címke csak a VNet tartományát jelenti.

Olvassa el az érvényes szabályokat mindkét határon

Amikor alhálózati NSG és NIC-NSG is érvényes, a folyamnak mindkettőt teljesítenie kell. Az egyikben adott engedély nem írja felül a másikban adott tiltást, és a csomag valójában az összesített képpel találkozik.

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

Ha az Azure Virtual Network Manager biztonsági rendszergazdai szabályai is szerepet kapnak, vizsgálja felül azt a réteget is. Egy rendszergazdai Always allow szabály NSG-értékelés nélkül továbbíthat forgalmat, míg egy rendszergazdai Deny megállítja, mielőtt az NSG-k látnák. Az csak NSG-t vizsgáló áttekintés hiányos ehhez az elrendezéshez.

Ne feledje, hogy az NSG-k állapottartók. Egy szabály szerkesztése nem feltétlenül szakítja meg a meglévő engedélyezett kapcsolatot, ezért az átvételi teszt friss folyamot igényel. Ez a tulajdonság éles környezetben hasznos, változási ablakban pedig megtévesztő.

Ellenőrizze friss kapcsolattal

Nyisson új munkamenetet a helyi ügyféltől a szolgáltatás portjára, majd ismételje meg egy olyan gazdagépről, amelyet el kell utasítani. Futtassa a folyamtesztet a VM oldaláról is, hogy tudja, a visszaút sértetlen.

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

Az NSG-engedély egyetlen hozzáférési döntés, nem útvonal és nem figyelő. Ha a szabály engedi a folyamot, és a kapcsolat mégis meghiúsul, ellenőrizze az ügyfél útvonalát a VPN-be, az Azure visszaútját és a gazdagép tűzfalát, mielőtt újra szerkesztené a csoportot. Jegyezze fel a tényleges forráscímet, az NSG-társításokat és az egyező szabályt a jóváhagyott szolgáltatással, mert a következő peering- vagy útvonalváltozás megváltoztathatja, mit fed le a VirtualNetwork címke.