NAT ಹಿಂದಿನ ಪೀರ್‌ನೊಂದಿಗೆ Azure ಸೈಟ್-ಟು-ಸೈಟ್ VPN: ಪರಿಶೀಲನಾ ಪಟ್ಟಿ

ಈ ಪರಿಶೀಲನೆಗಳನ್ನು ಕ್ರಮದಲ್ಲಿ ಮಾಡಿ ಮತ್ತು ಮೊದಲು ವಿಫಲವಾದುದರಲ್ಲಿ ನಿಲ್ಲಿಸಿ. Azure NAT ಹಿಂದಿನ ಸಾಧನವನ್ನು ಬೆಂಬಲಿಸುವುದಿಲ್ಲ ಎಂಬ ಹೆಚ್ಚಿನ ವರದಿಗಳು ವಾಸ್ತವವಾಗಿ Azure ತಲುಪಲಾಗದ ಪೀರ್ ವಿಳಾಸ, ಅಥವಾ ಸರಿಯಾದ ಬದಿಯಿಂದ ಎಂದಿಗೂ ಪ್ರಾರಂಭವಾಗದ ಸುರಂಗವಾಗಿರುತ್ತವೆ. ಹೊರಗಿನ ಸಾಗಣೆ ಮತ್ತು ಒಳಗಿನ ರೂಟಿಂಗ್ ಎರಡು ವಿಭಿನ್ನ ಸಮಸ್ಯೆಗಳು, ಮತ್ತು ಅವುಗಳನ್ನು ಬೆರೆಸುವುದು ಅರ್ಧ ದಿನವನ್ನು ವ್ಯರ್ಥ ಮಾಡುತ್ತದೆ. ಕೆಳಗಿನ ಪ್ರತಿ ಹಂತವೂ ಬೇರೆಯವರಿಗೆ ನೀಡಬಹುದಾದ ವೀಕ್ಷಣೆಯನ್ನು ನೀಡುತ್ತದೆ.

ಹಂತ 1: ಪೀರ್ ನಿಜವಾಗಿಯೂ NAT ಹಿಂದೆ ಇದೆ ಎಂದು ದೃಢೀಕರಿಸಿ

ಸಾಧನದ WAN ಇಂಟರ್ಫೇಸ್‌ನಲ್ಲಿನ ವಿಳಾಸವನ್ನು Azure ಅದಕ್ಕಾಗಿ ನೋಡುವ ವಿಳಾಸದೊಂದಿಗೆ ಹೋಲಿಸಿ. ಅವು ಭಿನ್ನವಾಗಿದ್ದರೆ, ಏನೋ ಅನುವಾದ ಮಾಡುತ್ತಿದೆ, ಮತ್ತು ಆ ಅನುವಾದಕ ಈಗ ನಿಮ್ಮ VPN ವಿನ್ಯಾಸದ ಭಾಗವಾಗಿದೆ. ಒದಗಿಸುವವರನ್ನು ಕೇಳಿ ಮ್ಯಾಪಿಂಗ್ ಸ್ಥಿರವೇ ಅಥವಾ ಹಂಚಿಕೆಯೇ, ಏಕೆಂದರೆ ಹಂಚಿಕೆಯ ಮ್ಯಾಪಿಂಗ್ ನೀವು ಅವಲಂಬಿಸಬಹುದಾದದ್ದನ್ನು ಬದಲಿಸುತ್ತದೆ. ಖಾಸಗಿ WAN ವಿಳಾಸ ಮತ್ತು ಫಾರ್ವರ್ಡಿಂಗ್ ಇಲ್ಲದ ಸಾಧನವು ಸ್ಥಿರ ಸಾರ್ವಜನಿಕ ಮ್ಯಾಪಿಂಗ್ ಇರುವ ಕ್ಯಾರಿಯರ್-ಗ್ರೇಡ್ NAT ಹಿಂದಿನ ಸಾಧನಕ್ಕಿಂತ ಬೇರೆ ಪ್ರಕರಣ.

ಎರಡೂ ವಿಳಾಸಗಳು ಹೊಂದಿಕೆಯಾದರೆ, ಇಲ್ಲೇ ನಿಲ್ಲಿಸಿ: NAT ನಿಮ್ಮ ಸಮಸ್ಯೆ ಅಲ್ಲ ಮತ್ತು ಈ ಪಟ್ಟಿಯ ಉಳಿದ ಭಾಗ ಸಹಾಯ ಮಾಡುವುದಿಲ್ಲ.

ಟಿಕೆಟ್‌ನಲ್ಲಿ ಎರಡೂ ವಿಳಾಸಗಳನ್ನು ಮತ್ತು ಅನುವಾದಕದ ಮಾದರಿಯನ್ನು ಬರೆಯಿರಿ. ಆ ಒಂದು ಸಾಲು ಸಂರಚಿಸಿದ ಪೀರ್ ಏಕೆ ಉತ್ತರಿಸುವುದಿಲ್ಲ ಎಂಬ ಮುಂದಿನ ಪ್ರಶ್ನೆಗಳ ಸುತ್ತನ್ನು ತಡೆಯುತ್ತದೆ.

ಹಂತ 2: ಯಾರು ಪ್ರಾರಂಭಿಸುತ್ತಾರೆ ಎಂದು ಒಪ್ಪಿಕೊಳ್ಳಿ

Azure VPN Gateway FAQ NAT-T ಬೆಂಬಲವನ್ನು ತಿಳಿಸುತ್ತದೆ ಮತ್ತು ಆನ್-ಪ್ರಿಮೈಸ್ ಸಾಧನವು NAT ಹಿಂದೆ ಇದ್ದಾಗ IPsec ಸುರಂಗವನ್ನು ಪ್ರಾರಂಭಿಸಬೇಕು ಎಂದು ಸೇರಿಸುತ್ತದೆ. ಇದು ಸ್ಥಿತಿಯೊಂದಿಗೆ ಅನುವಾದ ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂಬುದಕ್ಕೆ ಹೊಂದುತ್ತದೆ, ಏಕೆಂದರೆ ಒಳಗಿನ ಸಾಧನ ಮೊದಲ ಪ್ಯಾಕೆಟ್ ಕಳುಹಿಸಿದ್ದರಿಂದ ಅನುವಾದಕ ಮ್ಯಾಪಿಂಗ್ ಇಟ್ಟುಕೊಳ್ಳುತ್ತದೆ. Azure ಪ್ರಾರಂಭಿಸಬೇಕೆಂದು ನಿರೀಕ್ಷಿಸಿದರೆ ಮತ್ತು ಆ ಮ್ಯಾಪಿಂಗ್ ರಚಿಸಲು ಏನೂ ಬಂದರೆ, ಸುರಂಗ ಎಂದಿಗೂ ಪ್ರಾರಂಭವಾಗುವುದಿಲ್ಲ.

ಪೀರ್ ಅನ್ನು ಕೇವಲ-ಉತ್ತರದಾತ ತಪ್ಪು ಸ್ಪಷ್ಟವಾಗುವಂತೆ ಸಂರಚಿಸಿ, ಮತ್ತು ಸಾಧನ ತಾನೇ ಮತ್ತೆ ಪ್ರಯತ್ನಿಸುತ್ತದೆಯೇ ಅಥವಾ ಟ್ರಿಗರ್ ಬೇಕೇ ಎಂದು ಪರಿಶೀಲಿಸಿ. ಕೆಲವು ಸಾಧನಗಳು ಆಸಕ್ತಿದಾಯಕ ಟ್ರಾಫಿಕ್ ಕಾಣಿಸಿದಾಗ ಮಾತ್ರ ಸುರಂಗ ಎತ್ತುತ್ತವೆ, ಅದು ಆಸಕ್ತಿದಾಯಕ ಟ್ರಾಫಿಕ್ ಎಂದಿಗೂ ಬಾರದ ಆರೋಗ್ಯ ಪ್ರೋಬ್ ಆಗುವವರೆಗೆ ಸರಿ.

ಕೈಯಿಂದ ಪ್ರಾರಂಭದ ಸಮಯದಲ್ಲಿ ಸಾಧನದಲ್ಲಿ IKE ವಿನಿಮಯವನ್ನು ಗಮನಿಸಿ; ಅಲ್ಲಿನ ಮೌನ ರೂಟಿಂಗ್ ಅಥವಾ ಫೈರ್‌ವಾಲ್‌ನ ಉತ್ತರ, Azureನ ಉತ್ತರವಲ್ಲ.

ಹಂತ 3: ಪೀರ್ ವಿಳಾಸವನ್ನು ಸರಿಯಾಗಿ ಪಡೆಯಿರಿ

Azure ತನ್ನ ಸ್ಥಳೀಯ ಜಾಲಬಂಧ ಗೇಟ್‌ವೇ ಆಬ್ಜೆಕ್ಟ್‌ನಲ್ಲಿ ಪೀರ್‌ಗಾಗಿ ತಲುಪಬಹುದಾದ ಸಾರ್ವಜನಿಕ ವಿಳಾಸ ಬೇಕು, ಸಾಮಾನ್ಯವಾಗಿ ಸಾಧನದ ಒಳಗಿನ ವಿಳಾಸದ ಬದಲು ಅನುವಾದಕದ ಸಾರ್ವಜನಿಕ ವಿಳಾಸ. ಸಾಧನವು ರುಜುವಾತು ಮಾಡುವ ಗುರುತು ಪ್ರತ್ಯೇಕ ಕ್ಷೇತ್ರ ಮತ್ತು Azure ಡಯಲ್ ಮಾಡುವ ವಿಳಾಸದಿಂದ ಕಾನೂನುಬದ್ಧವಾಗಿ ಭಿನ್ನವಾಗಿರಬಹುದು. ಎರಡನ್ನೂ ಪ್ರತ್ಯೇಕವಾಗಿ ಇರಿಸಿ, ಏಕೆಂದರೆ ಅವುಗಳನ್ನು ಅದಲುಬದಲು ಮಾಡಿದರೆ NAT ಸಮಸ್ಯೆಯಂತೆಯೇ ಕಾಣುವ ರುಜುವಾತು ವೈಫಲ್ಯ ಉಂಟಾಗುತ್ತದೆ.

ಸಾರ್ವಜನಿಕ ವಿಳಾಸ ಬದಲಾದರೆ ಆ ಆಬ್ಜೆಕ್ಟ್ ಕೂಡ ಅದರೊಂದಿಗೆ ಬದಲಾಗಬೇಕು. ಹಳೆಯ ವಿಳಾಸಕ್ಕೆ ಪರಿಹರಿಸುವ ಹೆಸರು ಕೈಯಿಂದ ನವೀಕರಿಸಬೇಕಾದ ಸ್ಥಿರ ವಿಳಾಸಕ್ಕಿಂತ ಕೆಟ್ಟದು.

ಮೂರೂ ಮೌಲ್ಯಗಳನ್ನು ಬರೆಯಿರಿ: ಸಾಧನದ ಸ್ಥಳೀಯ ವಿಳಾಸ, ಅನುವಾದಿತ ಸಾರ್ವಜನಿಕ ವಿಳಾಸ, ಸಂರಚಿಸಿದ ಪೀರ್ ಗುರುತು.

ಹಂತ 4: NAT-Tಗೆ ಬೇಕಾದ ಪೋರ್ಟ್‌ಗಳನ್ನು ಮಾತ್ರ ತೆರೆಯಿರಿ

NAT-T UDP ಒಳಗೆ ESP ಸಾಗಿಸುತ್ತದೆ, ಮತ್ತು RFC 3948 ಆ ಎನ್‌ಕ್ಯಾಪ್ಸುಲೇಶನ್ ಅನ್ನು ಪೋರ್ಟ್ 500ರ ಪ್ರಾರಂಭಿಕ ಮಾತುಕತೆಯ ನಂತರ ಬಳಸುವ ಪೋರ್ಟ್ 4500ರೊಂದಿಗೆ ವಿವರಿಸುತ್ತದೆ. ನಿಮ್ಮ ಫೈರ್‌ವಾಲ್ ಮತ್ತು ಅನುವಾದಕ ಎರಡೂ ವಿನಿಮಯ ಮತ್ತು ಅದರ ಹಿಂತಿರುಗುವ ಟ್ರಾಫಿಕ್‌ಗೆ ಅನುಮತಿ ನೀಡಬೇಕು. ಸಂಬಂಧವಿಲ್ಲದ TCP ಪೋರ್ಟ್‌ಗೆ ಅನುಮತಿ ನೀಡುವುದು ಈ ಮಾರ್ಗದ ಬಗ್ಗೆ ಏನನ್ನೂ ಸಾಬೀತು ಮಾಡುವುದಿಲ್ಲ, ಮತ್ತು ಹೊರಹೋಗುವಿಕೆಗೆ ಅನುಮತಿ ನೀಡಿ ಉತ್ತರಕ್ಕೆ ಇಲ್ಲದ ನಿಯಮವೂ ವಿಫಲವಾಗುತ್ತದೆ.

ಪೀರ್ ಪ್ರಾರಂಭಿಸಿ ಅನುವಾದಕ ಸ್ಥಿತಿ ಇಟ್ಟುಕೊಂಡಾಗ ಸ್ಥಿರ ಒಳಬರುವ ಪೋರ್ಟ್ ಫಾರ್ವರ್ಡ್ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಅಗತ್ಯವಿಲ್ಲ. ಮ್ಯಾಪಿಂಗ್ ಅಸ್ಥಿರವಾದಾಗ ಅಥವಾ ಮಾರ್ಗದಲ್ಲಿ ಏನೋ ಸ್ಥಿತಿಯನ್ನು ಆಕ್ರಮಣಕಾರಿಯಾಗಿ ಮುಗಿಸಿದಾಗ ಅದು ಅಗತ್ಯವಾಗುತ್ತದೆ.

ಅನುವಾದಕದ ಎರಡೂ ಬದಿಗಳಲ್ಲಿ ಒಮ್ಮೆ ಸೆರೆಹಿಡಿಯಿರಿ; ಎನ್‌ಕ್ಯಾಪ್ಸುಲೇಶನ್ ವ್ಯತ್ಯಾಸ ತಕ್ಷಣ ಕಾಣುತ್ತದೆ.

ಹಂತ 5: ಹೊರಗಿನ ಸಾಗಣೆಯನ್ನು ಒಳಗಿನ ರೂಟಿಂಗ್‌ನಿಂದ ಬೇರ್ಪಡಿಸಿ

ಸ್ಥಾಪಿತವಾಗಿ ಏನನ್ನೂ ಸಾಗಿಸದ ಸುರಂಗ ರೂಟಿಂಗ್ ಸಮಸ್ಯೆ, NAT-T ಸಮಸ್ಯೆ ಅಲ್ಲ. ಸೈಟ್‌ಗಳಿಗೆ ಇನ್ನೂ ಹೊಂದುವ ಟ್ರಾಫಿಕ್ ಆಯ್ಕೆದಾರರು, ಹೊಂದಿಕೆಯಾಗುವ ವಿಳಾಸ ಸ್ಥಳಗಳು, ಪ್ರವೇಶ ನಿಯಮಗಳು ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಜಾಲಗಳಿಗೆ ಹಿಂತಿರುಗುವ ಮಾರ್ಗ ಬೇಕು. ಇವುಗಳಲ್ಲಿ ಯಾವುದನ್ನೂ ಯಶಸ್ವಿ IKE ವಿನಿಮಯ ನೀಡುವುದಿಲ್ಲ.

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

ಏನನ್ನಾದರೂ ಬದಲಿಸುವ ಮೊದಲು ವೈಫಲ್ಯವನ್ನು ಹಂತದ ಪ್ರಕಾರ ವರ್ಗೀಕರಿಸಿ, ಮತ್ತು ಆ ವರ್ಗೀಕರಣವನ್ನು ಟಿಕೆಟ್‌ನಲ್ಲಿ ಇರಿಸಿ ಇದರಿಂದ ಮುಂದಿನ ವ್ಯಕ್ತಿ ನೀವು ನಿಲ್ಲಿಸಿದಲ್ಲಿಂದ ಪ್ರಾರಂಭಿಸುತ್ತಾರೆ.