Дзе ўжываць NSG для трафіку Azure site-to-site VPN

Тунэль site-to-site працуе, лакальны кліент дасягае некаторыя хасты Azure, а іншыя не, і хтосьці далучыў групу сеткавай бяспекі да GatewaySubnet, каб гэта выправіць. Спыніцеся тут. Azure не падтрымлівае NSG на GatewaySubnet, і група не бачыць унутраны пакет так, як бачыць правіла працоўнай нагрузкі. Размясціце палітыку на мэтавай падсетцы або NIC, супастаўце адрас крыніцы, які існуе пасля расшыфроўкі, і затым праверце новым злучэннем, а не старым.

Размясціце NSG там, дзе Azure яго ацэньвае

Падтрыманая мяжа для фільтрацыі працоўнай нагрузкі — мэтавая падсетка або мэтавы сеткавы інтэрфейс. Падсетка шлюза — гэта інфраструктура, і Azure дакументуе, што NSG там не падтрымліваюцца і могуць пашкодзіць працы шлюза.

Ёсць і лагічная праблема з размяшчэннем. NSG на GatewaySubnet ацэньваў бы знешні абмен IPsec, чые адрасы належаць двум шлюзам. Вашаму правілу праграмы патрэбна прыватная крыніца ўнутры тунэля, а гэты пакет існуе толькі пасля таго, як шлюз яго расшыфруе. Далучыце групу да падсеткі працоўнай нагрузкі, і правіла ўбачыць адрас, для якога яно напісана.

Праверце бягучыя сувязі, перш чым нешта змяняць, каб ведаць, што вы пераносіце:

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

Знайдзіце адрас крыніцы пасля расшыфроўкі

Унутраная крыніца — гэта прыватны адрас лакальнага кліента або адрас, які прадстаўляе прылада ці NAT VPN пасля трансляцыі. Гэта не публічны адрас лакальнага шлюза VPN, бо ён належыць знешняму абмену.

Калі NAT уваходзіць у архітэктуру, пацвердзіце прадстаўленую крыніцу, а не мяркуйце яе. Захоп пакетаў на VM Azure або поле крыніцы ў журнале злучэнняў сэрвісу вырашае пытанне хутчэй, чым чытанне лакальнай канфігурацыі. Затым напішыце правіла для гэтага адраса і рэальнага мэтавага порта.

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

Выкарыстоўвайце адно правіла на кожны сэрвіс, які збіраецеся адкрыць, і трымайце спіс партоў кароткім. Правіла, якое дазваляе ўсе парты з лакальнага дыяпазону, ператварае NSG у фармальнасць.

Праверце прадвызначаны абсяг VirtualNetwork

Тэг сэрвісу VirtualNetwork шырэйшы за лакальную віртуальную сетку. Яго азначэнне ўключае падключаныя лакальныя адрасныя прасторы, сеткі з peering і іншыя прэфіксы, падключаныя праз шлюз. Гэта значыць, што прадвызначанае правіла дазволу, абмежаванае VirtualNetwork, ужо можа дазваляць трафік тунэля, які аператар лічыў знешнім.

Чытайце прадвызначаныя правілы перад даданнем вузкіх і чытайце кожнае правіла з вышэйшым прыярытэтам, якое можа супасці першым. Даданне яўнага дазволу не выдаляе шырэйшае правіла, якое ўжо дазваляе паток. Калі палітыка патрабуе забароны, размясціце яе на прыярытэце, які сапраўды ацэньваецца перад дазволам.

Дакументацыя Microsoft па тэгах сэрвісаў пералічвае, што ахоплівае тэг VirtualNetwork, і гэта крыніца, на якую спасылаюцца, калі хтосьці сцвярджае, што тэг азначае толькі дыяпазон VNet.

Чытайце эфектыўныя правілы на абодвух межах

Калі дзейнічаюць і NSG падсеткі, і NSG NIC, паток мусіць задаволіць абодва. Дазвол у адным не адмяняе забарону ў другім, і менавіта сукупны выгляд сустракае пакет.

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

Калі ўдзельнічаюць правілы адміністратара бяспекі Azure Virtual Network Manager, праглядзіце і гэты ўзровень. Адміністрацыйнае правіла Always allow можа даставіць трафік без ацэнкі NSG, а адміністрацыйнае Deny спыняе яго раней, чым NSG яго ўбачаць. Разгляд толькі NSG няпоўны для такой схемы.

Памятайце, што NSG захоўваюць стан. Рэдагаванне правіла не абавязкова спыняе існуючае дазволенае злучэнне, таму прыёмачны тэст патрабуе свежага патоку. Гэтая ўласцівасць карысная ў прадукцыі і падманная падчас акна змен.

Праверце свежым злучэннем

Адкрыйце новую сесію з лакальнага кліента да порта сэрвісу, затым паўтарыце з хаста, які мусіць быць адхілены. Запусціце тэст патоку і з боку VM, каб ведаць, што зваротны шлях цэлы.

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 — гэта адно рашэнне аб доступе, не маршрут і не слухач. Калі правіла дазваляе паток, а злучэнне ўсё яшчэ не ўдаецца, праверце маршрут кліента ў VPN, зваротны маршрут Azure і файрвол хаста, перш чым зноў рэдагаваць групу. Запішыце фактычны адрас крыніцы, сувязі NSG і адпаведнае правіла разам з зацверджаным сэрвісам, бо наступнае змяненне peering або маршруту можа змяніць тое, што ахоплівае тэг VirtualNetwork.