Sait-ja-sait tunnel on püsti, kohalik klient jõuab mõnda Azure'i hosti ja mõnda mitte, ning keegi lisas selle parandamiseks GatewaySubnetile võrguturberühma. Peatuge siin. Azure ei toeta NSG-d GatewaySubnetil ja rühm ei näe sisemist paketti nii, nagu töökoormuse reegel seda näeb. Pange poliitika sihtalamvõrku või NIC-i, sobitage pärast dekrüpteerimist olemas olev allikaaadress ja seejärel kontrollige uue ühendusega, mitte vanaga.

Pange NSG sinna, kus Azure seda hindab

Töökoormuse filtreerimise toetatud piir on sihtalamvõrk või sihtvõrguliides. Lüüsialamvõrk on infrastruktuur ja Azure dokumenteerib, et NSG-sid seal ei toetata ning need võivad lüüsi tööd kahjustada.

Paigutusel on ka loogiline probleem. GatewaySubneti NSG hindaks välist IPsec-vahetust, mille aadressid kuuluvad kahele lüüsile. Teie rakenduse reegel vajab privaatset allikat tunneli sees ja see pakett on olemas alles pärast seda, kui lüüs selle dekrüpteerib. Kinnitage rühm töökoormuse alamvõrgu külge ja reegel näeb aadressi, mille jaoks see kirjutati.

Kontrollige praeguseid seoseid enne mis tahes muudatust, et teaksite, mida liigutate:

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

Leidke allikaaadress pärast dekrüpteerimist

Sisemine allikas on kohaliku kliendi privaatne aadress või aadress, mille seade või VPN-i NAT pärast tõlkimist esitab. See ei ole kohaliku VPN-lüüsi avalik aadress, mis kuulub välisele vahetusele.

Kui NAT on disaini osa, kinnitage esitatud allikas selle eeldamise asemel. Paketi püüdmine Azure'i VM-is või teenuse ühenduslogi allikaväli lahendab küsimuse kiiremini kui kohaliku konfiguratsiooni lugemine. Seejärel kirjutage reegel selle aadressi ja tegeliku sihtpordi vastu.

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

Kasutage ühte reeglit iga teenuse kohta, mida soovite avada, ja hoidke portide loend lühike. Reegel, mis lubab kõiki porte kohalikust vahemikust, muudab NSG formaalsuseks.

Kontrollige VirtualNetworki vaikeulatust

VirtualNetworki teenusesilt on kohalikust virtuaalvõrgust laiem. Selle määratlus hõlmab ühendatud kohalikke aadressiruumi, peeritud võrke ja muid lüüsiga ühendatud prefikseid. Seega võib VirtualNetworkile piiratud vaikimisi lubamisreegel juba lubada tunneliliiklust, mida operaator pidas väliseks.

Lugege vaikereeglid enne kitsaste lisamist ja lugege iga kõrgema prioriteediga reeglit, mis võiks esimesena sobida. Selgesõnalise lubamise lisamine ei eemalda laiemat reeglit, mis voogu juba lubab. Kui poliitika nõuab keeldu, asetage see prioriteedile, mida tõesti hinnatakse enne lubamist.

Microsofti teenusesiltide dokumentatsioon loetleb, mida VirtualNetworki silt katab, ja see on viide, mida tsiteerida, kui keegi väidab, et silt tähendab ainult VNeti vahemikku.

Lugege kehtivaid reegleid mõlemal piiril

Kui kehtivad nii alamvõrgu NSG kui ka NIC-i NSG, peab voog vastama mõlemale. Lubamine ühes ei tühista keeldu teises ja pakett kohtab tegelikult koondvaadet.

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

Kui mängus on Azure Virtual Network Manageri turbekorraldaja reeglid, vaadake üle ka see kiht. Administraatori Always allow reegel võib liikluse kohale toimetada ilma NSG hindamiseta, samal ajal kui administraatori Deny peatab selle enne, kui NSG-d seda näevad. Ainult NSG ülevaade on sellise korralduse puhul puudulik.

Pidage meeles, et NSG-d on olekupõhised. Reegli muutmine ei lõpeta tingimata olemasolevat lubatud ühendust, seega vajab vastuvõtutest värsket voogu. See omadus on tootmises kasulik ja muudatusaknas eksitav.

Kontrollige värske ühendusega

Avage kohalikust kliendist uus seanss teenuse pordile ja korrake siis hostist, millele peaks juurdepääs keelatud olema. Käivitage vootest ka VM-i poolelt, et teaksite, et tagasitee on terve.

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 luba on üks juurdepääsuotsus, mitte marsruut ja mitte kuulaja. Kui reegel lubab voogu ja ühendus siiski ebaõnnestub, kontrollige kliendi marsruuti VPN-i, Azure'i tagasitee marsruuti ja hosti tulemüüri enne rühma uuesti muutmist. Kirjutage üles tegelik allikaaadress, NSG seosed ja sobiv reegel koos heakskiidetud teenusega, sest järgmine peerimis- või marsruudimuudatus võib muuta seda, mida VirtualNetworki silt katab.

Seotud artiklid