Saan ilalapat ang NSG para sa Azure site-to-site VPN traffic

Buhay ang site-to-site tunnel, naaabot ng lokal na kliyente ang ilang host ng Azure at hindi ang iba, at may naglakip ng network security group sa GatewaySubnet para ayusin iyon. Tumigil doon. Hindi sinusuportahan ng Azure ang NSG sa GatewaySubnet, at hindi nakikita ng grupo ang panloob na packet tulad ng isang panuntunan ng workload. Ilagay ang patakaran sa destination subnet o NIC, itugma ang source address na umiiral pagkatapos ng decryption, at pagkatapos ay i-verify sa bagong koneksyon hindi sa luma.

Ilagay ang NSG kung saan ito sinusuri ng Azure

Ang sinusuportahang hangganan para sa pag-filter ng workload ay ang destination subnet o ang destination network interface. Ang gateway subnet ay imprastruktura, at itinatala ng Azure na hindi sinusuportahan ang NSG doon at maaaring makasira sa operasyon ng gateway.

May problema rin sa lohika ang paglalagay. Ang NSG sa GatewaySubnet ay susuriin ang panlabas na palitan ng IPsec, na ang mga address ay pag-aari ng dalawang gateway. Kailangan ng panuntunan ng application mo ang pribadong pinagmulan sa loob ng tunnel, at ang packet na iyon ay umiiral lamang pagkatapos i-decrypt ng gateway. Ilakip ang grupo sa workload subnet at makikita ng panuntunan ang address na pinaglaanan nito.

Suriin ang kasalukuyang mga asosasyon bago magbago ng anuman, para malaman kung ano ang inililipat:

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

Hanapin ang source address pagkatapos ng decryption

Ang panloob na pinagmulan ay ang pribadong address ng lokal na kliyente, o ang address na ipinapakita ng appliance o NAT ng VPN pagkatapos ng pagsasalin. Hindi ito ang pampublikong address ng lokal na VPN gateway, na bahagi ng panlabas na palitan.

Kapag bahagi ng disenyo ang NAT, kumpirmahin ang ipinakita na pinagmulan sa halip na ipagpalagay ito. Ang pagkuha ng packet sa Azure VM, o ang field ng pinagmulan sa log ng koneksyon ng serbisyo, ay nagtatapos sa tanong nang mas mabilis kaysa sa pagbasa ng lokal na configuration. Pagkatapos ay isulat ang panuntunan laban sa address na iyon at sa tunay na destination port.

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

Gumamit ng isang panuntunan bawat serbisyong nais mong ilantad, at panatilihing maikli ang listahan ng port. Ang panuntunang nagpapahintulot sa lahat ng port mula sa lokal na saklaw ay ginagawang pormalidad ang NSG.

Suriin ang default na saklaw ng VirtualNetwork

Ang service tag na VirtualNetwork ay mas malawak kaysa sa lokal na virtual network. Kasama sa kahulugan nito ang mga konektadong lokal na address space, mga network na naka-peer, at iba pang prefix na konektado sa gateway. Kaya ang default na panuntunan ng pagpayag na nililimitahan sa VirtualNetwork ay maaaring nagpapahintulot na sa tunnel traffic na inaakala ng operator na panlabas.

Basahin ang mga default na panuntunan bago magdagdag ng makitid, at basahin ang bawat panuntunang may mas mataas na priyoridad na maaaring tumugma muna. Ang pagdaragdag ng tahasang pagpayag ay hindi nag-aalis ng mas malawak na panuntunang nagpapahintulot na sa daloy. Kung saan kailangan ng patakaran ang pagtanggi, ilagay ito sa priyoridad na talagang sinusuri bago ang pagpayag.

Dokumentasyon ng service tag ng Microsoft ang naglilista kung ano ang sakop ng tag na VirtualNetwork, at iyon ang sangguniang binabanggit kapag may nangangatwiran na ang tag ay tumutukoy lamang sa saklaw ng VNet.

Basahin ang epektibong panuntunan sa dalawang hangganan

Kapag parehong nalalapat ang NSG ng subnet at NSG ng NIC, dapat matugunan ng daloy ang dalawa. Ang pagpayag sa isa ay hindi nagpapawalang-bisa sa pagtanggi sa isa, at ang pinagsama-samang tanaw ang aktwal na hinaharap ng packet.

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

Kung kasama ang mga panuntunan ng tagapangasiwa ng seguridad ng Azure Virtual Network Manager, suriin din ang layer na iyon. Ang administratibong Always allow ay maaaring maghatid ng traffic nang walang pagsusuri ng NSG, samantalang ang administratibong Deny ay humihinto bago pa ito makita ng mga NSG. Hindi kumpleto ang pagsusuri ng NSG lamang para sa ganoong kaayusan.

Tandaan na ang mga NSG ay stateful. Ang pag-edit ng panuntunan ay hindi laging nagtatapos ng umiiral na pinapayagang koneksyon, kaya kailangan ng sariwang daloy sa pagsubok ng pagtanggap. Kapaki-pakinabang ang katangiang ito sa produksyon at nakalilito sa loob ng window ng pagbabago.

I-verify sa bagong koneksyon

Magbukas ng bagong session mula sa lokal na kliyente patungo sa service port, pagkatapos ay ulitin mula sa host na dapat tanggihan. Patakbuhin din ang pagsubok ng daloy mula sa panig ng VM, para malaman na buo ang daan pabalik.

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

Ang pagpayag ng NSG ay isang desisyon sa pag-access, hindi ruta at hindi tagapakinig. Kung pinapayagan ng panuntunan ang daloy at nabigo pa rin ang koneksyon, suriin ang ruta ng kliyente papasok sa VPN, ang ruta pabalik ng Azure at ang firewall ng host bago i-edit muli ang grupo. Itala ang tunay na source address, ang mga asosasyon ng NSG at ang tumutugmang panuntunan kasama ng aprubadong serbisyo, dahil ang susunod na pagbabago sa peering o ruta ay maaaring magbago kung ano ang sakop ng tag na VirtualNetwork.