Къде да приложим NSG за трафик на Azure VPN сайт към сайт

Тунелът сайт към сайт работи, локалният клиент достига някои хостове в 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.