VPN ಉಪಕರಣವನ್ನು ಚಲಾಯಿಸುವ Azure VM ಎರಡು ಸ್ವತಂತ್ರ ನಿರ್ಧಾರ ವ್ಯವಸ್ಥೆಗಳ ಒಳಗೆ ಇರುತ್ತದೆ. ಪ್ಯಾಕೆಟ್ ಯಾವ ಸಬ್ನೆಟ್ನಿಂದ ಹೊರಡುತ್ತದೆ ಎಂಬುದನ್ನು Azure ನಿರ್ಧರಿಸುತ್ತದೆ, ರೂಟ್ ಟೇಬಲ್ಗಳು ಮತ್ತು NIC ನ ಫಾರ್ವರ್ಡಿಂಗ್ ಸೆಟ್ಟಿಂಗ್ ಬಳಸಿ. ಡೀಕ್ರಿಪ್ಟ್ ಆದ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಮುಂದೆ ಕಳುಹಿಸುವುದೋ ಇಲ್ಲವೋ ಎಂಬುದನ್ನು ಉಪಕರಣದ ಸ್ವಂತ ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ ನಿರ್ಧರಿಸುತ್ತದೆ. ಪರಿಪೂರ್ಣವಾಗಿ ಏರುವ ಟನೆಲ್ ಎರಡನೇ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ವಿಫಲವಾಗಬಹುದು, ಮತ್ತು ಅಲ್ಲಿಯೇ ಇಂತಹ ಬಹುತೇಕ ನಿಯೋಜನೆಗಳು ನಿಲ್ಲುತ್ತವೆ.

ಒಂದು ಮಾರ್ಗದ ಮೂರು ಮಾಲೀಕರು

ಒಂದು ಶಾಖಾ ನೆಟ್ವರ್ಕ್ ತೆಗೆದುಕೊಳ್ಳಿ 192.168.50.0/24 ಮತ್ತು ಒಂದು ವರ್ಕ್ಲೋಡ್ ಸಬ್ನೆಟ್ ತೆಗೆದುಕೊಳ್ಳಿ 10.0.10.0/24, ಉಪಕರಣವು ಈ ವಿಳಾಸದಲ್ಲಿದೆ 10.0.0.4 ತನ್ನದೇ ಸಬ್ನೆಟ್ನಲ್ಲಿ. ಒಂದೇ ವಿನಂತಿ ಮೂರು ಪ್ರತ್ಯೇಕ ಸಂರಚನೆಗಳನ್ನು ಸ್ಪರ್ಶಿಸುತ್ತದೆ.

DecisionConfigured inHow it fails
Where the workload subnet sends branch trafficAzure route table entryTraffic leaves the subnet and never reaches the appliance
Whether a NIC may accept traffic not addressed to itAzure NIC IP forwardingPackets arrive and disappear at the interface
Whether the guest forwards decrypted trafficGuest OS or vendor appliance policyTunnel is up, workload is unreachable
Whether the workload accepts the sourceNSG and service policyRequests delivered, replies refused

ಬಹುತೇಕ ಸಂಸ್ಥೆಗಳಲ್ಲಿ ಪ್ರತಿ ಸಾಲನ್ನು ಬೇರೆ ತಂಡ ಹೊಂದಿದೆ, ಆದ್ದರಿಂದ ಈ ವೈಫಲ್ಯ ಸಾಮಾನ್ಯವಾಗಿ ಒಂದರ ಬದಲು ಮೂರು ಟಿಕೆಟ್ಗಳಾಗಿ ಬರುತ್ತದೆ.

ಉಪಕರಣದ ಕಡೆಗೆ ತೋರಿಸುವ ಮಾರ್ಗ

ವರ್ಕ್ಲೋಡ್ ಸಬ್ನೆಟ್ಗೆ ರೂಟ್ ಟೇಬಲ್ ಸಂಯೋಜಿಸಿ ಮತ್ತು ಶಾಖಾ ಪೂರ್ವಪ್ರತ್ಯಯಕ್ಕೆ Virtual appliance ಪ್ರಕಾರದ ಮುಂದಿನ ಹಾಪ್ ನೀಡಿ 10.0.0.4 ವಿಳಾಸವಾಗಿ. ಉಪಕರಣದ ತಲುಪಬಹುದಾದ ಖಾಸಗಿ ವಿಳಾಸವನ್ನು ಬಳಸಿ, ಎಂದಿಗೂ ಅದರ ಸಾರ್ವಜನಿಕ VPN ಪ್ರವೇಶ ಬಿಂದುವನ್ನು. ಮುಂದಿನ ಹಾಪ್ ವರ್ಕ್ಲೋಡ್ ಸಬ್ನೆಟ್ ಈಗಾಗಲೇ ತಲುಪಬಲ್ಲ ವಿಳಾಸವಾಗಿರಬೇಕು. ವರ್ಕ್ಲೋಡ್ನ ಉಳಿದ ರೂಟಿಂಗ್ ಅನ್ನು ಹಾಗೆಯೇ ಬಿಡಿ, ನೀವು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗವನ್ನು ಬದಲಿಸಲು ನಿರ್ಧರಿಸದ ಹೊರತು.

ಉಪಕರಣವನ್ನು ಅದರ ಸ್ವಂತ ಸಬ್ನೆಟ್ನಲ್ಲಿ ಇರಿಸಿ ಮತ್ತು ಶಾಖಾ ಸಂಚಾರವನ್ನು ಉಪಕರಣಕ್ಕೆ ಕಳುಹಿಸುವ ಮಾರ್ಗವು ಉಪಕರಣದ ಸ್ವಂತ ಹೊರಹೋಗುವ ಮಾರ್ಗವನ್ನೂ ಹಿಡಿಯದಂತೆ ಖಚಿತಪಡಿಸಿ. ಅಂತಹ ಲೂಪ್ ಶೂನ್ಯ ಉತ್ತರಗಳಿರುವ ಆರೋಗ್ಯಕರ ಟನೆಲ್ನಂತೆ ಕಾಣುತ್ತದೆ, ಮತ್ತು ರಾತ್ರಿ 2 ಗಂಟೆಗೆ ಅದನ್ನು ಡೀಬಗ್ ಮಾಡುವುದು ಬಹಳ ಕಷ್ಟಕರ.

ಎಲ್ಲರೂ ಮರೆಯುವ NIC ಫ್ಲ್ಯಾಗ್

Azure ನಲ್ಲಿ ಪ್ರತಿ NIC ಗೂ IP ಫಾರ್ವರ್ಡಿಂಗ್ ಸೆಟ್ಟಿಂಗ್ ಇದೆ, ಮತ್ತು ಅದು ಡೀಫಾಲ್ಟ್ ಆಗಿ ಆಫ್ ಇರುತ್ತದೆ. ಅದು ಇರುವುದು ಏಕೆಂದರೆ ಫಾರ್ವರ್ಡ್ ಮಾಡುವ NIC ತನ್ನದೇ ಅಲ್ಲದ ಬೇರೆ ಯಾವುದೋ ವಿಳಾಸಕ್ಕೆ ಕಳುಹಿಸಿದ ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ, ಮತ್ತು ಅವನ್ನು ಸದ್ದಿಲ್ಲದೆ ಬಿಟ್ಟುಬಿಡುವುದು ಉಳಿದವರಿಗೆ ಸುರಕ್ಷಿತ ಡೀಫಾಲ್ಟ್.

az network nic update --resource-group rg-net --name appliance-nic --ip-forwarding true ಒಂದು ಇಂಟರ್ಫೇಸ್ಗೆ ಅದನ್ನು ಆನ್ ಮಾಡುತ್ತದೆ. Microsoft ನ NIC ಫಾರ್ವರ್ಡಿಂಗ್ ಮಾರ್ಗದರ್ಶನ ಸಂಚಾರವನ್ನು ಫಾರ್ವರ್ಡ್ ಮಾಡುವ ಪ್ರತಿಯೊಂದು ಸಂಪರ್ಕಿತ NIC ನಲ್ಲಿ ಈ ಸೆಟ್ಟಿಂಗ್ ಬೇಕೆಂದು ಹೇಳುತ್ತದೆ, ಆದ್ದರಿಂದ ಒಂದೇ NIC ಇರುವ ಉಪಕರಣಕ್ಕೂ ಅದನ್ನು ಆ NIC ನಲ್ಲಿ ಸೆಟ್ ಮಾಡಬೇಕು.

ಫ್ಲ್ಯಾಗ್ ಮಾರ್ಗವಲ್ಲ ಮತ್ತು ಫೈರ್‌ವಾಲ್ ನಿಯಮವೂ ಅಲ್ಲ. ಅದನ್ನು ಆನ್ ಮಾಡುವುದು ಅನುಮತಿ ನೀಡುತ್ತದೆ, ಬೇರೇನೂ ಇಲ್ಲ.

ಅತಿಥಿ ಡೀಕ್ರಿಪ್ಟ್ ಆದ ಪ್ಯಾಕೆಟ್ನೊಂದಿಗೆ ಏನು ಮಾಡುತ್ತದೆ

ಟನೆಲ್ ಮುಗಿದ ನಂತರ ಉಪಕರಣದ ಸ್ವಂತ ಸ್ಟ್ಯಾಕ್ ಮುಂದಿನ ನಿರ್ಧಾರ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. Linux ಅತಿಥಿಯಲ್ಲಿ IPv4 ಫಾರ್ವರ್ಡಿಂಗ್ ರನ್‌ಟೈಮ್ ಸೆಟ್ಟಿಂಗ್, ಮತ್ತು sysctl -w net.ipv4.ip_forward=1 ಮುಂದಿನ ಬೂಟ್‌ವರೆಗೆ ಇರುತ್ತದೆ. ಅದನ್ನು ಬದಲಿಗೆ /etc/sysctl.d/ ಅಡಿಯಲ್ಲಿ ಒಂದು ಫೈಲ್‌ನಲ್ಲಿ ಉಳಿಸಿ. ವೆಂಡರ್ ಉಪಕರಣಕ್ಕೆ ತನ್ನದೇ ಸಮಾನಾಂತರ ಇರುತ್ತದೆ, ಮತ್ತು ವೆಂಡರ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ನಲ್ಲಿ ಅಂಟಿಸಿದ Linux ಸೂಚನೆಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಏನೂ ಮಾಡುವುದಿಲ್ಲ.

ಅತಿಥಿ ಫೈರ್‌ವಾಲ್ ನೀತಿ ಮತ್ತೆ ಪ್ರತ್ಯೇಕ, ವರ್ಕ್‌ಲೋಡ್‌ನ ನೆಟ್‌ವರ್ಕ್ ಭದ್ರತಾ ಗುಂಪೂ ಹಾಗೆಯೇ. VM ನ ಸಾರ್ವಜನಿಕ ವಿಳಾಸಕ್ಕೆ UDP 500 ಮತ್ತು 4500 ಅನುಮತಿಸುವುದು ಟನೆಲ್ ಅನ್ನು ರಕ್ಷಿಸುತ್ತದೆ; ಡೀಕ್ರಿಪ್ಟ್ ಆದ ಶಾಖಾ ವಿನಂತಿ ವರ್ಕ್‌ಲೋಡ್ ಪೋರ್ಟ್ ತಲುಪಬಹುದೇ ಎಂಬ ಬಗ್ಗೆ ಅದು ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ.

ಒಂದು ವಿನಂತಿ ಮತ್ತು ಅದರ ಉತ್ತರವನ್ನು ಅನುಸರಿಸಿ

ಒಂದು ಅನುಮತಿಸಿದ ಫ್ಲೋ ಆಯ್ಕೆಮಾಡಿ ಮತ್ತು ಅದನ್ನು ಆರಂಭದಿಂದ ಕೊನೆಯವರೆಗೆ ಅನುಸರಿಸಿ. ಶಾಖೆಗೆ ಒಂದು ಮಾರ್ಗ ಬೇಕು 10.0.10.0/24 ಸೈಟ್ ಸಂಪರ್ಕದ ಮೂಲಕ, ಉಪಕರಣಕ್ಕೆ ವರ್ಕ್‌ಲೋಡ್ ಸಬ್ನೆಟ್‌ಗೆ ತಲುಪಿಸುವ ಮಾರ್ಗ ಬೇಕು, ಮತ್ತು ವರ್ಕ್‌ಲೋಡ್ ಸಬ್ನೆಟ್‌ಗೆ ಶಾಖೆಯ ಕಡೆಗೆ ಮರಳು ಮಾರ್ಗ ಬೇಕು.

ವಿನ್ಯಾಸವು ಶಾಖೆಯ ಮೂಲ ವಿಳಾಸವನ್ನು ಉಳಿಸುತ್ತದೆಯೋ ಅಥವಾ ಅನುವಾದಿಸುತ್ತದೆಯೋ ಎಂಬುದನ್ನು ಬೇಗ ನಿರ್ಧರಿಸಿ. NAT ವರ್ಕ್‌ಲೋಡ್ ನೋಡುವುದನ್ನು ಬದಲಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಅದರ ಪ್ರವೇಶ ನಿಯಮಗಳು ನೀವು ನಿಜವಾಗಿ ಆಯ್ಕೆ ಮಾಡಿದ ಮಾದರಿಯನ್ನು ವಿವರಿಸಬೇಕು, ಊಹಿಸಿದ ಗೇಟ್‌ವೇ ವಿಳಾಸವನ್ನಲ್ಲ.

ಯಶಸ್ವಿ ಹ್ಯಾಂಡ್‌ಶೇಕ್ ಆ ಸರಪಳಿಯ ಒಂದು ಕೊಂಡಿಯನ್ನು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ. ಉತ್ತರವು ಅದೇ ಉಪಕರಣದ ಮೂಲಕ ಮರಳಿ ಬಂದಾಗ ಮತ್ತು ವರ್ಕ್‌ಲೋಡ್‌ನ ಸ್ವಂತ ನೀತಿ ಅನುಮತಿಸಿದಾಗ ಮಾರ್ಗ ಪೂರ್ಣವಾಗುತ್ತದೆ.

ಸಂಬಂಧಿತ ಲೇಖನಗಳು