Tuneli nga sajti në sajt është aktiv, klienti lokal arrin disa hoste të Azure dhe të tjerë jo, dhe dikush ka bashkangjitur një grup sigurie rrjeti në GatewaySubnet për ta rregulluar. Ndaloni aty. Azure nuk mbështet një NSG në GatewaySubnet, dhe grupi nuk e sheh paketën e brendshme siç e sheh një rregull i ngarkesës. Vendosni politikën në nënrrjetin ose NIC-in e destinacionit, përputhni adresën e burimit që ekziston pas dekriptimit dhe më pas verifikoni me një lidhje të re, jo me një të vjetër.

Vendosni NSG-në aty ku Azure e vlerëson

Kufiri i mbështetur për filtrimin e ngarkesës është nënrrjeti ose ndërfaqja e rrjetit e destinacionit. Nënrrjeti i portës është infrastrukturë, dhe Azure dokumenton që NSG-të nuk mbështeten aty dhe mund të dëmtojnë funksionimin e portës.

Ka edhe një problem logjik me vendosjen. NSG në GatewaySubnet do të vlerësonte shkëmbimin e jashtëm IPsec, adresat e të cilit i përkasin dy portave. Rregulli i aplikacionit tuaj ka nevojë për burimin privat brenda tunelit, dhe ajo paketë ekziston vetëm pasi porta ta dekriptojë. Bashkangjitni grupin në nënrrjetin e ngarkesës dhe rregulli do të shohë adresën për të cilën është shkruar.

Kontrolloni shoqërimet aktuale përpara se të ndryshoni diçka, që të dini çfarë po lëvizni:

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

Gjeni adresën e burimit pas dekriptimit

Burimi i brendshëm është adresa private e klientit lokal, ose adresa që një pajisje ose NAT-i i VPN-së paraqet pas përkthimit. Nuk është adresa publike e portës VPN lokale, e cila i përket shkëmbimit të jashtëm.

Kur NAT është pjesë e projektimit, konfirmoni burimin e paraqitur në vend që ta supozoni. Kapja e paketave në VM-në Azure, ose fusha e burimit në regjistrin e lidhjeve të shërbimit, e zgjidh çështjen më shpejt sesa leximi i konfigurimit lokal. Pastaj shkruani rregullin për atë adresë dhe portën reale të destinacionit.

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

Përdorni një rregull për çdo shërbim që dëshironi të ekspozoni dhe mbani listën e porteve të shkurtër. Një rregull që lejon të gjitha portet nga diapazoni lokal e kthen NSG-në në formalitet.

Kontrolloni shtrirjen e parazgjedhur VirtualNetwork

Etiketa e shërbimit VirtualNetwork është më e gjerë se rrjeti virtual lokal. Përkufizimi i saj përfshin hapësira adresash lokale të lidhura, rrjete me peering dhe parashtesa të tjera të lidhura me portën. Prandaj një rregull parazgjedhur lejimi i kufizuar në VirtualNetwork mund të lejojë tashmë trafik tuneli që operatori e konsideronte të jashtëm.

Lexoni rregullat e parazgjedhura përpara se të shtoni të ngushta, dhe lexoni çdo rregull me prioritet më të lartë që mund të përputhet i pari. Shtimi i një lejeje të qartë nuk heq një rregull më të gjerë që e lejon tashmë rrjedhën. Aty ku politika kërkon një mohim, vendoseni në një prioritet që vlerësohet vërtet përpara lejes.

Dokumentacioni i Microsoft për etiketat e shërbimit rendit çfarë mbulon etiketa VirtualNetwork, dhe është referenca që citohet kur dikush argumenton se etiketa nënkupton vetëm diapazonin e VNet.

Lexoni rregullat efektive në të dy kufijtë

Kur zbatohen njëkohësisht një NSG nënrrjeti dhe një NSG NIC-i, rrjedha duhet t'i plotësojë të dyja. Një leje në njërën nuk anulon një mohim në tjetrën, dhe paketa takon në të vërtetë pamjen e përmbledhur.

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

Nëse janë në lojë rregullat administrative të sigurisë të Azure Virtual Network Manager, rishikoni edhe atë shtresë. Një rregull administrativ Always allow mund të dërgojë trafik pa vlerësimin e NSG-së, ndërsa një Deny administrative e ndalon përpara se NSG-të ta shohin. Një rishikim vetëm i NSG-ve është i paplotë për atë rregullim.

Mbani mend se NSG-të janë me gjendje. Redaktimi i një rregulli nuk e përfundon medoemos një lidhje ekzistuese të lejuar, prandaj një test pranimi ka nevojë për një rrjedhë të re. Kjo veti është e dobishme në prodhim dhe mashtruese gjatë një dritareje ndryshimi.

Verifikoni me një lidhje të re

Hapni një sesion të re nga klienti lokal në portën e shërbimit, më pas përsëriteni nga një host që duhet të refuzohet. Ekzekutoni testin e rrjedhës edhe nga ana e VM-së, që të dini se rruga e kthimit është e paprekur.

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

Një leje e NSG-së është një vendim i vetëm aksesi, jo një rrugë dhe jo një dëgjues. Nëse rregulli e lejon rrjedhën dhe lidhja dështon përsëri, kontrolloni rrugën e klientit në VPN, rrugën e kthimit të Azure dhe murin e zjarrit të hostit përpara se ta redaktoni përsëri grupin. Regjistroni adresën reale të burimit, shoqërimet e NSG-së dhe rregullin përputhës bashkë me shërbimin e miratuar, sepse ndryshimi i radhës i peering-ut ose i rrugës mund të ndryshojë çfarë mbulon etiketa VirtualNetwork.

Artikuj të ngjashëm