ಒಂದು Azure VPN VM ನಲ್ಲಿ ಎರಡು ಸಾರ್ವಜನಿಕ IP: ಯಾವುದು ಏನು ಮಾಡುತ್ತದೆ

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

ನಿರ್ಧಾರ 1: ಟನೆಲ್ ಎಲ್ಲಿ ಕೊನೆಗೊಳ್ಳುತ್ತದೆ

Azure ನ ಸಾರ್ವಜನಿಕ IP NIC ನಲ್ಲಿನ ಖಾಸಗಿ IP ಸಂರಚನೆಗೆ ಸಂಬಂಧಿಸಿದೆ; ಅದು ಅತಿಥಿ ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ ಒಳಗೆ ಸೇರಿಸುವ ವಿಳಾಸವಲ್ಲ. ಊಹಿಸುವ ಬದಲು ಮ್ಯಾಪಿಂಗ್ ಓದಿ: az network nic show --ids /subscriptions/.../networkInterfaces/vpn-nic --query 'ipConfigurations[].{private:privateIPAddress,public:publicIPAddress.id}'. ಆ ಪ್ರಶ್ನೆ ಯಾವ ಖಾಸಗಿ ವಿಳಾಸವನ್ನು ಹಿಂತಿರುಗಿಸಿದರೂ, ಅತಿಥಿಯು ನಿಜವಾಗಿ ಅದನ್ನೇ ಹೊಂದಿರಬೇಕು.

ಒಂದು NIC ಹಲವು IP ಸಂರಚನೆಗಳನ್ನು ಹೊತ್ತುಕೊಳ್ಳಬಲ್ಲದು, ಆದ್ದರಿಂದ ಎರಡು ಸಾರ್ವಜನಿಕ ವಿಳಾಸಗಳಿಗೆ ಎರಡು NIC ಬೇಕಿಲ್ಲ. ವಿನ್ಯಾಸವು ನಿಜವಾಗಿ ಎರಡು NIC ಬಳಸಿದರೆ, ಪ್ರತಿಯೊಂದೂ ತನ್ನದೇ ಅತಿಥಿ ಮಾರ್ಗಗಳನ್ನು ಮತ್ತು ಮುಂದಿನ ಹಾಪ್ಗಳನ್ನು ತರುತ್ತದೆ, ಮತ್ತು ನೀವು ಸರಳಗೊಳಿಸುವ ಬದಲು ಒಂದು ರೂಟಿಂಗ್ ನಿರ್ಧಾರ ಸೇರಿಸಿದ್ದೀರಿ.

ಸ್ಪಷ್ಟ ಸ್ಥಳೀಯ ಬೈಂಡ್ ಇರುವ ಸೇವೆಗೆ ಅತಿಥಿಯ ನಿಜವಾದ ಖಾಸಗಿ ವಿಳಾಸಕ್ಕೆ ಬೈಂಡ್ ಮಾಡಿ, ಎಂದಿಗೂ ಸಾರ್ವಜನಿಕ ಪ್ಲೇಸ್ಹೋಲ್ಡರ್ಗೆ ಅಲ್ಲ. ಎಲ್ಲಾ ವಿಳಾಸಗಳನ್ನು ಸ್ವೀಕರಿಸುವ ಶ್ರೋತೃವು ತಲುಪುವ ಪ್ರತಿ IP ಸಂರಚನೆಯ ಮೂಲಕ ಸಂಚಾರ ಪಡೆಯುತ್ತದೆ, ಆದ್ದರಿಂದ ಬೈಂಡ್ ಕ್ರಮ ನಿರ್ಧರಿಸುತ್ತದೆ ಎಂದು ನಿರೀಕ್ಷಿಸುವ ಬದಲು ನೆಟ್ವರ್ಕ್ ಭದ್ರತಾ ಗುಂಪು ಮತ್ತು ಹೋಸ್ಟ್ ಫೈರ್ವಾಲ್ನಿಂದ ಪ್ರವೇಶವನ್ನು ಮಿತಿಗೊಳಿಸಿ.

ನಿರ್ಧಾರ 2: ಫಾರ್ವರ್ಡ್ ಮಾಡಿದ ಕ್ಲೈಂಟ್ ಯಾವ ಮೂಲವನ್ನು ಬಳಸುತ್ತದೆ

ಗೇಟ್ವೇ ಕ್ಲೈಂಟ್ ವಿನಂತಿಯನ್ನು ಡೀಕ್ರಿಪ್ಟ್ ಮಾಡಿದ ನಂತರ, ಅದು ಫಾರ್ವರ್ಡ್ ಮಾಡುವ ಪ್ಯಾಕೆಟ್ VPN ಶ್ರೋತೃವನ್ನು ತಲುಪಿದ ಪ್ಯಾಕೆಟ್ಗಿಂತ ಬೇರೆಯದು. ಅತಿಥಿಗೆ ಫಾರ್ವರ್ಡಿಂಗ್ ಸಕ್ರಿಯ, ಹರಿವಿಗೆ ಅನುಮತಿ ನೀಡುವ ಫೈರ್ವಾಲ್ ನೀತಿ ಮತ್ತು ಕ್ಲೌಡ್ ವಿನ್ಯಾಸ ಅನುಮತಿಸುವ ಮೂಲ ವಿಳಾಸ ಬೇಕು. ಕ್ಲೈಂಟ್ನ ಒಳಗಿನ ವಿಳಾಸವನ್ನು ಅನುವಾದಿಸಿದರೆ, Azure ಮೌಲ್ಯಮಾಪನ ಮಾಡುವುದು ಆ ಅನುವಾದಿತ ಮೂಲವನ್ನೇ, ಕ್ಲೈಂಟ್ನ ಒಳಗಿನ ವಿಳಾಸವನ್ನಲ್ಲ.

ಸಂಕುಚಿತ SNAT ನಿಯಮವು ಅತಿಥಿ-ಖಾಸಗಿ ಮೂಲವನ್ನು ಆಯ್ಕೆ ಮಾಡಬಹುದು, ಆದರೆ ನಂತರದ Azure ಅನುವಾದವನ್ನು ಮೀರಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. VM ಒಳಗೆ ಪ್ರತಿ ಕ್ಲೈಂಟ್ಗೆ ಹೊಣೆಗಾರಿಕೆ ಬೇಕಾದರೆ SNAT ಆಯ್ಕೆಮಾಡಿ; ಸಬ್ನೆಟ್ನ ಹೊರಹೋಗುವ ವಿನ್ಯಾಸ ಈಗಾಗಲೇ ಸ್ಥಿರ ಸಾರ್ವಜನಿಕ ಮೂಲವನ್ನು ನೀಡಿದರೆ ಮತ್ತು ಎರಡನೇ ಅನುವಾದವು ಸ್ಥಿತಿಯನ್ನು ಮಾತ್ರ ಸೇರಿಸುತ್ತದೆಯಾದರೆ ಅದನ್ನು ಬಿಟ್ಟುಬಿಡಿ.

ನಿರ್ಧಾರ 3: ಯಾವ Azure ಹೊರಹೋಗುವ ವಿಧಾನ ಗೆಲ್ಲುತ್ತದೆ

Microsoftಹೊರಹೋಗುವ ಆದ್ಯತಾ ಕ್ರಮಅನ್ನು ದಾಖಲಿಸುತ್ತದೆ: ಸಾಧನ ಅಥವಾ ಗೇಟ್ವೇಗೆ ಅನ್ವಯವಾಗುವ ಮಾರ್ಗಕ್ಕೆ ಆದ್ಯತೆ ಇರುತ್ತದೆ, ಮತ್ತು ಸಂಬಂಧಿತ ಮಾರ್ಗದಲ್ಲಿ ಸಬ್ನೆಟ್ NAT Gateway ಸಂಪರ್ಕವು ಇನ್ಸ್ಟಾನ್ಸ್ ಮಟ್ಟದ ಸಾರ್ವಜನಿಕ IP ಗಿಂತ ಆದ್ಯತೆ ಪಡೆಯುತ್ತದೆ. ಈ ಕ್ರಮದಿಂದಾಗಿಯೇ 10.20.0.5 ಗೆ ಅನುವಾದಿಸುವುದು ವೆಬ್ಸೈಟ್ 198.51.100.20 ಅನ್ನು ನೋಡುತ್ತದೆ ಎಂದು ಸಾಬೀತು ಮಾಡುವುದಿಲ್ಲ. ನಿರ್ಗಮನ ವಿನ್ಯಾಸವನ್ನು ಸ್ವೀಕರಿಸುವ ಮೊದಲು ಪರಿಣಾಮಕಾರಿ ಮಾರ್ಗ ಕೋಷ್ಟಕ, NAT Gateway ಸಂಬಂಧ ಮತ್ತು NIC ನ ಸಾರ್ವಜನಿಕ IP ಅನ್ನು ಒಟ್ಟಿಗೆ ಓದಿ.

ಇರಿಸಿAzure NIC ಫಾರ್ವರ್ಡಿಂಗ್ ಸೆಟ್ಟಿಂಗ್ಅನ್ನು Linux ಫಾರ್ವರ್ಡಿಂಗ್ನಿಂದ ಪ್ರತ್ಯೇಕವಾಗಿ. ಕ್ಲೌಡ್ ಧ್ವಜವು ಮೂಲ ಅಥವಾ ಗಮ್ಯಸ್ಥಾನ NIC ಗೆ ನಿಗದಿಪಡಿಸದ ಪ್ಯಾಕೆಟ್ಗಳಿಗೆ ಅನುಮತಿ ನೀಡುತ್ತದೆ; ಅದು net.ipv4.ip_forward ಸಕ್ರಿಯಗೊಳಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಅತಿಥಿ ಸೆಟ್ಟಿಂಗ್ ಕ್ಲೌಡ್ ಅನುಮತಿ ನೀಡುವುದಿಲ್ಲ.

ಟನೆಲ್ ಸಾಕೆಟ್ಗೆ ತನ್ನದೇ ಮೂಲ ನಿರ್ಧಾರ ಇದೆ

wg-quick ಅಡಿಯಲ್ಲಿ WireGuard ನ Address ವೈರ್ಗಾರ್ಡ್ ಇಂಟರ್ಫೇಸ್ಗೆ ವಿಳಾಸ ನಿಗದಿಪಡಿಸುತ್ತದೆ; ಅದು ಬಾಹ್ಯ UDP ಬೈಂಡ್ ಸೂಚನೆಯಲ್ಲ. ಎನ್ಕ್ರಿಪ್ಟ್ ಮಾಡಿದ ಸಾಕೆಟ್ನ ಮೂಲವು ಮಾರ್ಗ ಕೋಷ್ಟಕವನ್ನು ಅನುಸರಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ನೀತಿ ಮಾರ್ಗ ಅಥವಾ ಎರಡನೇ ಡೀಫಾಲ್ಟ್ ಇಂಟರ್ಫೇಸ್ ವಿಳಾಸವನ್ನು ಮುಟ್ಟದೆ ಅದನ್ನು ಸರಿಸಬಹುದು.OpenVPNನ local ಆಯ್ಕೆ ಮತ್ತು UDP multihome ಅದೇ ರೀತಿ ವರ್ತಿಸುತ್ತವೆ: ಅವು ಶ್ರೋತೃ ಮತ್ತು ಅದರ ಉತ್ತರಗಳಿಗೆ ಸಂಬಂಧಿಸಿದ್ದು, ಪ್ರತಿ ಫಾರ್ವರ್ಡ್ ಮಾಡಿದ ಕ್ಲೈಂಟ್ನ ಇಂಟರ್ನೆಟ್ ಮೂಲಕ್ಕಲ್ಲ.

ಟನೆಲ್ ಹೊತ್ತೊಯ್ಯುವ ಅಂಡರ್ಲೇ ಮಾರ್ಗವನ್ನು ಉಳಿಸಿಕೊಳ್ಳಿ ಮತ್ತು ಕ್ಲೈಂಟ್ ಇನ್ನೂ ನಿರೀಕ್ಷಿತ ಪ್ರವೇಶ ವ್ಯವಸ್ಥೆಯಿಂದ ದೃಢೀಕೃತ ಉತ್ತರಗಳನ್ನು ಪಡೆಯುತ್ತಿದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ. ವಿಳಾಸ ಪಟ್ಟಿಯ ಕ್ರಮವನ್ನು ಶಾಶ್ವತ ಮೂಲ-ಆಯ್ಕೆ ನೀತಿಯಾಗಿ ಅವಲಂಬಿಸಬೇಡಿ, ಏಕೆಂದರೆ NIC ಗೆ ಸೇರಿಸುವ ಮುಂದಿನ ವಿಳಾಸವು ಯಾವುದು ಗೆಲ್ಲುತ್ತದೆ ಎಂಬುದನ್ನು ಬದಲಿಸಬಹುದು.

ಏನನ್ನು ಸ್ವೀಕರಿಸಬೇಕು, ಮತ್ತು ಯಾವ ಕ್ರಮದಲ್ಲಿ

ಮೂರು ಫಲಿತಾಂಶಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಸ್ವೀಕರಿಸಿ. ಮೊದಲನೆಯದು, ಬಾಹ್ಯ ಕ್ಲೈಂಟ್ ಉದ್ದೇಶಿತ VPN ಪ್ರವೇಶವನ್ನು ತಲುಪುತ್ತದೆ. ಎರಡನೆಯದು, ಆ VPN ಕ್ಲೈಂಟ್ನ ಹೊಸ ಅನುಮತಿಸಿದ ವಿನಂತಿ ದಾಖಲಿತ ಇಂಟರ್ನೆಟ್ ನಿರ್ಗಮನದ ಮೂಲಕ ಹೊರಡುತ್ತದೆ. ಮೂರನೆಯದು, ಉದ್ದೇಶಿಸದ ಶ್ರೋತೃ ಮತ್ತು ಫಾರ್ವರ್ಡಿಂಗ್ ಮಾರ್ಗಗಳು ನಿರಾಕರಿಸಲ್ಪಟ್ಟೇ ಇರುತ್ತವೆ. ಸಾರ್ವಜನಿಕ-ಇಂದ-ಖಾಸಗಿ ಮ್ಯಾಪಿಂಗ್ಗಳನ್ನು ಮತ್ತು ಪ್ರತಿ ನಿರ್ಧಾರದ ಅತಿಥಿ ಹಾಗೂ ಕ್ಲೌಡ್ ಮಾಲೀಕರನ್ನು ಒಂದೇ ಸ್ಥಳದಲ್ಲಿ ದಾಖಲಿಸಿ.

ಯಶಸ್ವಿ ಟನೆಲ್ ಮೊದಲ ಭಾಗವನ್ನು ಮಾತ್ರ ಸಾಬೀತು ಮಾಡುತ್ತದೆ. ಹೊಸ ಹರಿವಿನೊಂದಿಗೆ ನಿರ್ಗಮನವನ್ನು ಪರೀಕ್ಷಿಸಿ, ಏಕೆಂದರೆ ಕ್ಯಾಶ್ ಮಾಡಿದ ಸಂಪರ್ಕವು ಮಾರ್ಗ ಬದಲಾದ ನಂತರವೂ ಬಹಳ ಕಾಲ ಹಳೆಯ ಮೂಲವನ್ನು ಬಳಸಬಹುದು.