Azure ಸೈಟ್-ಟು-ಸೈಟ್ VPN ಸಂಚಾರಕ್ಕೆ NSG ಅನ್ನು ಎಲ್ಲಿ ಅನ್ವಯಿಸಬೇಕು

ಸೈಟ್-ಟು-ಸೈಟ್ ಸುರಂಗ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದೆ, ಸ್ಥಳೀಯ ಕ್ಲೈಂಟ್ ಕೆಲವು Azure ಹೋಸ್ಟ್‌ಗಳನ್ನು ತಲುಪುತ್ತದೆ ಮತ್ತು ಇನ್ನು ಕೆಲವನ್ನು ತಲುಪುವುದಿಲ್ಲ, ಮತ್ತು ಅದನ್ನು ಸರಿಪಡಿಸಲು ಯಾರೋ GatewaySubnet ಗೆ ನೆಟ್‌ವರ್ಕ್ ಭದ್ರತಾ ಗುಂಪನ್ನು ಜೋಡಿಸಿದ್ದಾರೆ. ಅಲ್ಲೇ ನಿಲ್ಲಿಸಿ. Azure GatewaySubnet ನಲ್ಲಿ NSG ಬೆಂಬಲಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಗುಂಪು ವರ್ಕ್‌ಲೋಡ್ ನಿಯಮದಂತೆ ಒಳಗಿನ ಪ್ಯಾಕೆಟ್ ನೋಡಲಾರದು. ನೀತಿಯನ್ನು ಗುರಿ ಸಬ್‌ನೆಟ್ ಅಥವಾ NIC ನಲ್ಲಿ ಇರಿಸಿ, ಡೀಕ್ರಿಪ್ಶನ್ ನಂತರ ಇರುವ ಮೂಲ ವಿಳಾಸವನ್ನು ಹೊಂದಿಸಿ, ನಂತರ ಹಳೆಯದಕ್ಕಿಂತ ಹೊಸ ಸಂಪರ್ಕದಿಂದ ಪರಿಶೀಲಿಸಿ.

Azure ಅದನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡುವ ಸ್ಥಳದಲ್ಲಿ NSG ಇರಿಸಿ

ವರ್ಕ್‌ಲೋಡ್ ಫಿಲ್ಟರಿಂಗ್‌ಗೆ ಬೆಂಬಲಿತ ಗಡಿ ಗುರಿ ಸಬ್‌ನೆಟ್ ಅಥವಾ ಗುರಿ ನೆಟ್‌ವರ್ಕ್ ಇಂಟರ್‌ಫೇಸ್. ಗೇಟ್‌ವೇ ಸಬ್‌ನೆಟ್ ಮೂಲಸೌಕರ್ಯವಾಗಿದೆ, ಮತ್ತು ಅಲ್ಲಿ NSG ಬೆಂಬಲಿತವಲ್ಲ ಮತ್ತು ಗೇಟ್‌ವೇ ಕಾರ್ಯಾಚರಣೆಗೆ ಹಾನಿ ಮಾಡಬಹುದು ಎಂದು Azure ದಾಖಲಿಸುತ್ತದೆ.

ನಿಯೋಜನೆಯಲ್ಲಿ ತಾರ್ಕಿಕ ಸಮಸ್ಯೆಯೂ ಇದೆ. GatewaySubnet ನಲ್ಲಿನ NSG ಹೊರಗಿನ 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

ಡೀಕ್ರಿಪ್ಶನ್ ನಂತರ ಮೂಲ ವಿಳಾಸವನ್ನು ಹುಡುಕಿ

ಒಳಗಿನ ಮೂಲವು ಸ್ಥಳೀಯ ಕ್ಲೈಂಟ್‌ನ ಖಾಸಗಿ ವಿಳಾಸ, ಅಥವಾ ಸಾಧನ ಅಥವಾ VPN NAT ಅನುವಾದದ ನಂತರ ಪ್ರಸ್ತುತಪಡಿಸುವ ವಿಳಾಸ. ಇದು ಸ್ಥಳೀಯ VPN ಗೇಟ್‌ವೇಯ ಸಾರ್ವಜನಿಕ ವಿಳಾಸವಲ್ಲ, ಅದು ಹೊರಗಿನ ವಿನಿಮಯಕ್ಕೆ ಸೇರಿದೆ.

NAT ವಿನ್ಯಾಸದ ಭಾಗವಾಗಿದ್ದಾಗ, ಊಹಿಸುವ ಬದಲು ಪ್ರಸ್ತುತಪಡಿಸಿದ ಮೂಲವನ್ನು ದೃಢೀಕರಿಸಿ. Azure VM ನಲ್ಲಿ ಪ್ಯಾಕೆಟ್ ಸೆರೆಹಿಡಿಯುವಿಕೆ, ಅಥವಾ ಸೇವೆಯ ಸಂಪರ್ಕ ಲಾಗ್‌ನ ಮೂಲ ಕ್ಷೇತ್ರ, ಸ್ಥಳೀಯ ಸಂರಚನೆಯನ್ನು ಓದುವುದಕ್ಕಿಂತ ಬೇಗ ಪ್ರಶ್ನೆಯನ್ನು ಪರಿಹರಿಸುತ್ತದೆ. ನಂತರ ಆ ವಿಳಾಸ ಮತ್ತು ನಿಜವಾದ ಗುರಿ ಪೋರ್ಟ್ ವಿರುದ್ಧ ನಿಯಮವನ್ನು ಬರೆಯಿರಿ.

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 ಸೇವಾ ಟ್ಯಾಗ್ ಸ್ಥಳೀಯ ವರ್ಚುವಲ್ ನೆಟ್‌ವರ್ಕ್‌ಗಿಂತ ವಿಶಾಲವಾಗಿದೆ. ಅದರ ವ್ಯಾಖ್ಯಾನವು ಸಂಪರ್ಕಿತ ಸ್ಥಳೀಯ ವಿಳಾಸ ಸ್ಥಳಗಳು, ಪೀರ್ ಮಾಡಿದ ನೆಟ್‌ವರ್ಕ್‌ಗಳು ಮತ್ತು ಗೇಟ್‌ವೇ ಸಂಪರ್ಕಿತ ಇತರ ಪ್ರಿಫಿಕ್ಸ್‌ಗಳನ್ನು ಒಳಗೊಂಡಿದೆ. ಅಂದರೆ VirtualNetwork ಗೆ ಸೀಮಿತವಾದ ಡೀಫಾಲ್ಟ್ ಅನುಮತಿ ನಿಯಮವು ಆಪರೇಟರ್ ಬಾಹ್ಯ ಎಂದು ಭಾವಿಸಿದ ಸುರಂಗ ಸಂಚಾರವನ್ನು ಈಗಾಗಲೇ ಅನುಮತಿಸಬಹುದು.

ಸಣ್ಣ ನಿಯಮಗಳನ್ನು ಸೇರಿಸುವ ಮೊದಲು ಡೀಫಾಲ್ಟ್ ನಿಯಮಗಳನ್ನು ಓದಿ, ಮತ್ತು ಮೊದಲು ಹೊಂದಿಕೆಯಾಗಬಹುದಾದ ಪ್ರತಿ ಹೆಚ್ಚಿನ ಆದ್ಯತೆಯ ನಿಯಮವನ್ನು ಓದಿ. ಸ್ಪಷ್ಟ ಅನುಮತಿ ಸೇರಿಸುವುದು ಹರಿವನ್ನು ಈಗಾಗಲೇ ಅನುಮತಿಸುವ ವಿಶಾಲ ನಿಯಮವನ್ನು ತೆಗೆದುಹಾಕುವುದಿಲ್ಲ. ನೀತಿ ನಿರಾಕರಣೆ ಬಯಸುವಲ್ಲಿ, ಅದನ್ನು ಅನುಮತಿಗಿಂತ ಮೊದಲು ನಿಜವಾಗಿ ಮೌಲ್ಯಮಾಪನವಾಗುವ ಆದ್ಯತೆಯಲ್ಲಿ ಇರಿಸಿ.

Microsoft ನ ಸೇವಾ ಟ್ಯಾಗ್ ದಾಖಲೆ VirtualNetwork ಟ್ಯಾಗ್ ಏನನ್ನು ಆವರಿಸುತ್ತದೆ ಎಂದು ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಟ್ಯಾಗ್ ಕೇವಲ VNet ಶ್ರೇಣಿಯನ್ನು ಸೂಚಿಸುತ್ತದೆ ಎಂದು ಯಾರಾದರೂ ವಾದಿಸಿದಾಗ ಉಲ್ಲೇಖಿಸಬೇಕಾದ ಆಧಾರ ಅದೇ.

ಎರಡೂ ಗಡಿಗಳಲ್ಲಿ ಪರಿಣಾಮಕಾರಿ ನಿಯಮಗಳನ್ನು ಓದಿ

ಸಬ್‌ನೆಟ್ NSG ಮತ್ತು NIC NSG ಎರಡೂ ಅನ್ವಯವಾದಾಗ, ಹರಿವು ಎರಡನ್ನೂ ಪೂರೈಸಬೇಕು. ಒಂದರಲ್ಲಿನ ಅನುಮತಿ ಇನ್ನೊಂದರಲ್ಲಿನ ನಿರಾಕರಣೆಯನ್ನು ರದ್ದುಗೊಳಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಪ್ಯಾಕೆಟ್ ನಿಜವಾಗಿ ಎದುರಿಸುವುದು ಸಂಯೋಜಿತ ನೋಟವನ್ನು.

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 ಸಂಯೋಜನೆಗಳು ಮತ್ತು ಹೊಂದಿಕೆಯಾಗುವ ನಿಯಮವನ್ನು ಅನುಮೋದಿತ ಸೇವೆಯೊಂದಿಗೆ ದಾಖಲಿಸಿ, ಏಕೆಂದರೆ ಮುಂದಿನ ಪೀರಿಂಗ್ ಅಥವಾ ಮಾರ್ಗ ಬದಲಾವಣೆ VirtualNetwork ಟ್ಯಾಗ್ ಏನನ್ನು ಆವರಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಬದಲಿಸಬಹುದು.