Mihin NSG:t sijoitetaan Azure-sivustojen välisessä VPN-liikenteessä

Sivustojen välinen tunneli on pystyssä, paikallinen asiakas tavoittaa osan Azure-isännistä ja osan ei, ja joku on lisännyt verkkoturvaryhmän GatewaySubnetiin korjatakseen sen. Pysähdy siihen. Azure ei tue NSG:tä GatewaySubnetissä, eikä ryhmä näe sisäistä pakettia kuten työkuorman sääntö näkee. Aseta käytäntö kohde-aliverkkoon tai NIC:iin, sovita salauksen purkamisen jälkeen olemassa oleva lähdeosoite ja varmista sitten uudella yhteydellä, ei vanhalla.

Sijoita NSG sinne, missä Azure arvioi sen

Työkuorman suodatuksen tuettu raja on kohde-aliverkko tai kohdeverkkoliitäntä. Yhdyskäytävän aliverkko on infrastruktuuria, ja Azure dokumentoi, että NSG:t eivät ole siellä tuettuja ja voivat heikentää yhdyskäytävän toimintaa.

Sijoittelussa on myös looginen ongelma. GatewaySubnetin NSG arvioisi ulkoista IPsec-vaihtoa, jonka osoitteet kuuluvat kahdelle yhdyskäytävälle. Sovelluksesi sääntö tarvitsee yksityisen lähteen tunnelin sisältä, ja se paketti on olemassa vasta kun yhdyskäytävä purkaa sen salauksen. Kiinnitä ryhmä työkuorman aliverkkoon, niin sääntö näkee osoitteen, jota varten se kirjoitettiin.

Tarkista nykyiset liitokset ennen kuin muutat mitään, jotta tiedät mitä siirrät:

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

Etsi lähdeosoite salauksen purkamisen jälkeen

Sisäinen lähde on paikallisen asiakkaan yksityinen osoite tai osoite, jonka laite tai VPN:n NAT esittää käännöksen jälkeen. Se ei ole paikallisen VPN-yhdyskäytävän julkinen osoite, joka kuuluu ulkoiseen vaihtoon.

Kun NAT on osa suunnittelua, vahvista esitetty lähde sen sijaan että oletat sen. Paketin kaappaus Azure-VM:ssä tai palvelun yhteyslokin lähdekenttä ratkaisee kysymyksen nopeammin kuin paikallisen kokoonpanon lukeminen. Kirjoita sääntö sitten tuota osoitetta ja todellista kohdeporttia vasten.

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

Käytä yhtä sääntöä palvelua kohden, jonka haluat altistaa, ja pidä porttiluettelo lyhyenä. Sääntö, joka sallii kaikki portit paikallisesta alueesta, tekee NSG:stä muodollisuuden.

Tarkista VirtualNetworkin oletuslaajuus

VirtualNetwork-palvelutunniste on laajempi kuin paikallinen virtuaaliverkko. Sen määritelmä kattaa liitetyt paikalliset osoitealueet, peering-verkot ja muut yhdyskäytävään liitetyt etuliitteet. Siksi VirtualNetworkiin rajattu oletus-sallintasääntö voi jo sallia tunneliliikennettä, jonka operaattori luuli ulkoiseksi.

Lue oletussäännöt ennen kuin lisäät kapeita, ja lue jokainen korkeamman prioriteetin sääntö, joka voisi täsmätä ensin. Selkeän sallinnan lisääminen ei poista laajempaa sääntöä, joka jo sallii virran. Kun käytäntö vaatii eston, aseta se prioriteetille, joka todella arvioidaan ennen sallintaa.

Microsoftin palvelutunnisteiden dokumentaatio luettelee, mitä VirtualNetwork-tunniste kattaa, ja se on viite, johon vedotaan, kun joku väittää tunnisteen tarkoittavan vain VNetin aluetta.

Lue voimassa olevat säännöt molemmilla rajoilla

Kun sekä aliverkon NSG että NIC:n NSG ovat voimassa, virran on täytettävä molemmat. Sallinta toisessa ei kumoa estoa toisessa, ja paketti kohtaa todella yhdistetyn näkymän.

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

Jos Azure Virtual Network Managerin turvallisuusjärjestelmänvalvojan säännöt ovat pelissä, tarkista myös se kerros. Järjestelmänvalvojan Always allow -sääntö voi toimittaa liikennettä ilman NSG-arviointia, kun taas järjestelmänvalvojan Deny pysäyttää sen ennen kuin NSG:t näkevät sen. Pelkkä NSG-tarkistus on puutteellinen tällaisessa järjestelyssä.

Muista, että NSG:t ovat tilallisia. Säännön muokkaaminen ei välttämättä lopeta olemassa olevaa sallittua yhteyttä, joten hyväksymistesti tarvitsee tuoreen virran. Tämä ominaisuus on hyödyllinen tuotannossa ja harhaanjohtava muutosikkunan aikana.

Varmista tuoreella yhteydellä

Avaa uusi istunto paikallisesta asiakkaasta palvelun porttiin ja toista se sitten isännästä, joka pitäisi hylätä. Aja virtaustesti myös VM:n puolelta, jotta tiedät paluureitin olevan ehjä.

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

NSG:n lupa on yksi käyttöoikeuspäätös, ei reitti eikä kuuntelija. Jos sääntö sallii virran ja yhteys epäonnistuu silti, tarkista asiakkaan reitti VPN:ään, Azure palaureitti ja isännän palomuuri ennen kuin muokkaat ryhmää uudelleen. Kirjaa todellinen lähdeosoite, NSG-liitokset ja täsmäävä sääntö hyväksytyn palvelun kanssa, koska seuraava peering- tai reittimuutos voi muuttaa sitä, mitä VirtualNetwork-tunniste kattaa.