Hvar á að beita NSG á Azure site-to-site VPN umferð
Azure styður ekki NSG á GatewaySubnet. Setjið vinnuálagsreglur á áfangasubnetið eða NIC-ið, passið innri upptök og farið yfir breið sjálfgefin gildi.
Site-to-site-göngin eru uppi, staðbundni biðlarinn nær til sumra Azure-hýsla en annarra ekki, og einhver hefur tengt netöryggishóp við GatewaySubnet til að laga það. Stoppið þar. Azure styður ekki NSG á GatewaySubnet, og hópurinn sér ekki innra pakkann eins og vinnuálagsregla gerir. Setjið stefnuna á áfangasubnetið eða NIC-ið, passið upprunafangið sem er til staðar eftir afkóðun, og sannreynið síðan með nýrri tengingu frekar en gamalli.
Setjið NSG þar sem Azure metur það
Studdu mörkin fyrir vinnuálagssíun eru áfangasubnetið eða áfanga-netviðmótið. Hliðarsubnet er innviðir, og Azure skjalfestir að NSG séu ekki studd þar og geti skaðað rekstur hliðsins.
Einnig er rökfræðivandamál með staðsetninguna. NSG á GatewaySubnet myndi meta ytri IPsec-skiptin, en föng þeirra tilheyra hliðunum tveimur. Regla forritsins þíns þarf einkaupprunann inni í göngunum, og sá pakki er aðeins til eftir að hliðið afkóðar hann. Tengið hópinn við vinnuálagssubnetið og reglan sér fangið sem hún var skrifuð fyrir.
Athugið núverandi tengingar áður en þið breytið einhverju, svo þið vitið hvað þið eruð að flytja:
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.idFinndu upprunafangið eftir afkóðun
Innra uppruninn er einkafang staðbundna biðlarans, eða fangið sem tæki eða NAT VPNsins sýnir eftir þýðingu. Það er ekki opinbert fang staðbundna VPN-hliðsins, sem tilheyrir ytri skiptunum.
Þegar NAT er hluti af hönnuninni, staðfestið sýnda upprunann í stað þess að gera ráð fyrir honum. Pakkaskráning á Azure-VM eða upprunareiturinn í tengingarskrá þjónustunnar leysir spurninguna hraðar en að lesa staðbundna stillinguna. Skrifið síðan regluna gegn því fangi og raunverulegri áfangahöfn.
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 443Notið eina reglu fyrir hverja þjónustu sem þið viljið opna, og haldið hafnarlistanum stuttum. Regla sem leyfir allar hafnir úr staðbundna bilinu gerir NSG að formsatriði.
Athugið sjálfgefið umfang VirtualNetwork
VirtualNetwork-þjónustumerkið er breiðara en staðbundna sýndarnetið. Skilgreining þess nær til tengdra staðbundinna fangarýma, jafningjaneta og annarra forskeyta sem tengjast hliðinu. Því getur sjálfgefin leyfisregla sem takmarkast við VirtualNetwork þegar leyft gönguumferð sem rekstraraðili taldi ytri.
Lesið sjálfgefinar reglur áður en þið bætið við þröngum, og lesið hverja reglu með hærri forgang sem gæti passað fyrst. Að bæta við skýru leyfi fjarlægir ekki breiðari reglu sem leyfir flæðið þegar. Þar sem stefnan krefst synjunar skal setja hana á forgang sem er raunverulega metinn fyrir leyfið.
Skjöl Microsoft um þjónustumerki telja upp hvað VirtualNetwork-merkið nær yfir, og það er tilvísunin sem vitna skal í þegar einhver heldur því fram að merkið þýði aðeins VNet-bilið.
Lesið gildandi reglur á báðum mörkum
Þegar bæði subnet-NSG og NIC-NSG gilda verður flæðið að uppfylla bæði. Leyfi í öðru fellir ekki úr gildi synjun í hinu, og það er samantekna sýnin sem pakkinn mætir í raun.
az network nic show-effective-nsg -g rg-net -n vm-app-nic -o tableEf öryggisstjórnunarreglur Azure Virtual Network Manager eru í gangi, farið yfir það lag líka. Stjórnunarregla Always allow getur afhent umferð án NSG-mats, en stjórnunarleg Deny stöðvar hana áður en NSG-in sjá hana. Yfirferð sem aðeins skoðar NSG er ófullnægjandi fyrir það fyrirkomulag.
Munið að NSG eru stöðufest. Breyting á reglu endar ekki endilega núverandi leyft tenging, svo samþykktarpróf þarf nýtt flæði. Þessi eiginleiki er gagnlegur í framleiðslu og villandi í breytingaglugga.
Sannreynið með nýrri tengingu
Opnið nýja setu frá staðbundna biðlaranum að þjónustuhöfninni, og endurtakið síðan frá hýsli sem á að vera hafnað. Keyrið flæðiprófið líka frá VM-hliðinni, svo þið vitið að endurkomuleiðin sé heil.
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:51515NSG-leyfi er ein aðgangsákvörðun, ekki leið og ekki hlustandi. Ef reglan leyfir flæðið og tengingin mistekst samt, athugið leið biðlarans inn í VPN-ið, endurkomuleið Azure og eldvegg hýsilsins áður en þið breytið hópnum aftur. Skráið raunverulegt upprunafang, tengingar NSG og samsvarandi reglu ásamt samþykktu þjónustunni, því næsta jafningja- eða leiðarbreyting getur breytt því sem VirtualNetwork-merkið nær yfir.