Kie apliki NSG-ojn por Azure VPN-trafiko de loko al loko

La tunelo de loko al loko funkcias, la loka kliento atingas kelkajn Azure-gastigantojn kaj ne aliajn, kaj iu aldonis retan sekurecan grupon al GatewaySubnet por ripari tion. Haltu tie. Azure ne subtenas NSG-on sur GatewaySubnet, kaj la grupo ne povas vidi la internan paketon tiel, kiel regulo de laborŝarĝo faras. Metu la politikon sur la celan subreton aŭ la NIC, kongruigu la fontadreson kiu ekzistas post malĉifrado, kaj poste kontrolu per nova konekto, ne per malnova.

Metu la NSG-on tie, kie Azure ĝin taksas

La subtenata limo por filtrado de laborŝarĝo estas la cela subreto aŭ la cela reta interfaco. Pordega subreto estas infrastrukturo, kaj Azure dokumentas, ke NSG-oj ne estas subtenataj tie kaj povas damaĝi la funkciadon de la pordego.

Estas ankaŭ logika problemo pri la lokado. La NSG sur GatewaySubnet taksus la eksteran IPsec-interŝanĝon, kies adresoj apartenas al la du pordegoj. Via aplikaĵa regulo bezonas la privatan fonton ene de la tunelo, kaj tiu paketo ekzistas nur post kiam la pordego malĉifras ĝin. Alkroĉu la grupon al la laborŝarĝa subreto kaj la regulo vidos la adreson por kiu ĝi estis skribita.

Kontrolu la nunajn asociiĝojn antaŭ ol ŝanĝi ion ajn, por ke vi sciu, kion vi movas:

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

Trovu la fontadreson post malĉifrado

La interna fonto estas la privata adreso de la loka kliento, aŭ la adreso kiun aparato aŭ VPN-NAT prezentas post tradukado. Ĝi ne estas la publika adreso de la loka VPN-pordego, kiu apartenas al la ekstera interŝanĝo.

Kiam NAT estas parto de la dezajno, konfirmu la prezentatan fonton anstataŭ supozi ĝin. Paketa kaptado sur la Azure-VM, aŭ la fonta kampo en la konekta protokolo de la servo, solvas la demandon pli rapide ol legi la lokan agordon. Poste skribu la regulon kontraŭ tiu adreso kaj la reala cela pordo.

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

Uzu unu regulon por ĉiu servo, kiun vi intencas elmeti, kaj tenu la liston de pordoj mallonga. Regulo, kiu permesas ĉiujn pordojn el la loka gamo, igas la NSG-on formaleco.

Kontrolu la defaŭltan amplekson VirtualNetwork

La servo-etikedo VirtualNetwork estas pli larĝa ol la loka virtuala reto. Ĝia difino inkluzivas konektitajn lokajn adresspacojn, kunligitajn retojn kaj aliajn pordego-konektitajn prefiksojn. Tial defaŭlta permesa regulo limigita al VirtualNetwork jam povas permesi tunelan trafikon, kiun operatoro konsideris ekstera.

Legu la defaŭltajn regulojn antaŭ ol aldoni mallarĝajn, kaj legu ĉiun pli altprioritatan regulon, kiu povus unue kongrui. Aldoni eksplicitan permeson ne forigas pli larĝan regulon, kiu jam permesas la fluon. Kie politiko postulas malpermeson, metu ĝin ĉe prioritato, kiu efektive estas taksata antaŭ la permeso.

La dokumentaro de Microsoft pri servaj etikedoj listigas, kion kovras la etikedo VirtualNetwork, kaj ĝi estas la referenco citinda kiam iu argumentas, ke la etikedo signifas nur la gamon de VNet.

Legu la efektivajn regulojn ĉe ambaŭ limoj

Kiam validas kaj subreta NSG kaj NIC-NSG, la fluo devas kontentigi ambaŭ. Permeso en unu ne nuligas malpermeson en la alia, kaj la kunigita vido estas tio, kion la paketo efektive renkontas.

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

Se administraj sekurecaj reguloj de Azure Virtual Network Manager estas en ludo, reviziu ankaŭ tiun tavolon. Administra regulo Always allow povas liveri trafikon sen NSG-takso, dum administra Deny haltigas ĝin antaŭ ol la NSG-oj vidas ĝin. Revizio nur de NSG-oj estas nekompleta por tia aranĝo.

Memoru, ke NSG-oj konservas staton. Redakti regulon ne nepre finigas ekzistantan permesitan konekton, do akcepta testado bezonas freŝan fluon. Tiu eco utilas en produkto kaj misgvidas dum ŝanĝa fenestro.

Kontrolu per freŝa konekto

Malfermu novan seancon de la loka kliento al la serva pordo, poste ripetu de gastiganto, kiu devus esti malakceptita. Rulu la fluteston ankaŭ de la VM-flanko, por ke vi sciu, ke la revena vojo estas sendifekta.

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-permeso estas unu alirdecido, ne vojo kaj ne aŭskultanto. Se la regulo permesas la fluon kaj la konekto ankoraŭ malsukcesas, kontrolu la vojon de la kliento en la VPN-on, la revenan vojon de Azure kaj la gastigantan fajromuron antaŭ ol redekredi la grupon. Notu la faktan fontadreson, la NSG-asociiĝojn kaj la kongruan regulon kun la aprobita servo, ĉar la sekva ŝanĝo de kunligado aŭ vojo povas ŝanĝi, kion kovras la etikedo VirtualNetwork.