ಪಾಯಿಂಟ್-ಟು-ಸೈಟ್‌ಗೆ ರೂಟ್-ಆಧಾರಿತ Azure VPN ಗೇಟ್‌ವೇ ಏಕೆ ಬೇಕು
ನೀತಿ-ಆಧಾರಿತ ಗೇಟ್‌ವೇಯಲ್ಲಿ ಕ್ಲೈಂಟ್ ರೂಟ್‌ಗಳಿಗೆ ಯಾವುದೇ ಟನಲ್ ಇಂಟರ್ಫೇಸ್ ಇಲ್ಲ. ಏನನ್ನು ಮತ್ತೆ ನಿರ್ಮಿಸಬೇಕು, ಯಾವ ಕ್ರಮದಲ್ಲಿ, ಮತ್ತು ಬದಲಾವಣೆಯ ನಂತರ ಯಾವ ಮಿತಿಗಳು ಉಳಿಯುತ್ತವೆ.
ನೀತಿ-ಆಧಾರಿತ ಗೇಟ್‌ವೇ ಟ್ರಾಫಿಕ್ ಆಯ್ಕೆಗಾರರಿಂದ ಆಯ್ಕೆಯಾದ IPsec ಟನಲ್ ಅನ್ನು ನಿರ್ಮಿಸುತ್ತದೆ, ಮತ್ತು ಕ್ಲೈಂಟ್ ರೂಟ್‌ಗಳನ್ನು ಹಸ್ತಾಂತರಿಸಲು ಯಾವುದೇ ಇಂಟರ್ಫೇಸ್ ಹೊಂದಿಲ್ಲ. ಪಾಯಿಂಟ್-ಟು-ಸೈಟ್ ಒಂದು ರೂಟಿಂಗ್ ವೈಶಿಷ್ಟ್ಯ: ಗೇಟ್‌ವೇ ಕ್ಲೈಂಟ್ ವಿಳಾಸಗಳ ಪೂಲ್ ಅನ್ನು ಹೊಂದಿದೆ ಮತ್ತು ವರ್ಚುವಲ್ ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿ ಆ ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ ರೂಟ್‌ಗಳನ್ನು ಸ್ಥಾಪಿಸುತ್ತದೆ. ಈ ಅಸಾಮರಸ್ಯವೇ ಪೋರ್ಟಲ್ ಅದನ್ನು ಸೇರಿಸುವ ಯಾವುದೇ ಆಯ್ಕೆಯನ್ನು ತೋರಿಸದಿರುವ ಕಾರಣ. ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಗೇಟ್‌ವೇಯಲ್ಲಿ ಇಂಟರ್ಫೇಸ್ ರಚಿಸಲು ಟಾಗಲ್ ಮಾಡಬಹುದಾದ ಯಾವುದೂ ಇಲ್ಲ, ಆದ್ದರಿಂದ ಬದಲಾವಣೆ ಕಾನ್ಫಿಗರೇಶನ್ ಸಂಪಾದನೆಯಲ್ಲ, ಬದಲಿ.
ವೈಯಕ್ತಿಕ ಹಂತಗಳಿಗಿಂತ ಕ್ರಮವೇ ಹೆಚ್ಚು ಮುಖ್ಯ. ಕ್ರಮ ತಪ್ಪಾದರೆ ಸೈಟ್-ಟು-ಸೈಟ್ ಅಡಚಣೆ ನಿರ್ವಹಣಾ ವಿಂಡೋವನ್ನು ಮೀರಿ ಹೋಗುತ್ತದೆ.
ನೀತಿ-ಆಧಾರಿತ ಗೇಟ್‌ವೇ ವಾಸ್ತವವಾಗಿ ಏನು ಮಾಡುತ್ತದೆ
ನೀತಿ-ಆಧಾರಿತ ಗೇಟ್‌ವೇ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಸಂಪರ್ಕದಲ್ಲಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಿದ ಟ್ರಾಫಿಕ್ ಆಯ್ಕೆಗಾರರೊಂದಿಗೆ ಹೊಂದಿಸುತ್ತದೆ ಮತ್ತು ಹೊಂದಿಕೆಗಳನ್ನು ಒಂದೇ ಟನಲ್‌ಗೆ ಕಳುಹಿಸುತ್ತದೆ. ವಿಳಾಸವಿರುವ ಟನಲ್ ಇಂಟರ್ಫೇಸ್ ಇಲ್ಲ, ಮತ್ತು ವರ್ಚುವಲ್ ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿ ಎಲ್ಲಿಯೂ ಪ್ರತಿ-ಕ್ಲೈಂಟ್ ರೂಟ್ ಕಾಣಿಸುವುದಿಲ್ಲ. ರೂಟ್ ಟೇಬಲ್ ಕೇವಲ ಗೇಟ್‌ವೇಯತ್ತ ತೋರಿಸುವ ಸ್ಥಳೀಯ ಪ್ರಿಫಿಕ್ಸ್‌ಗಳನ್ನು ಪಡೆಯುತ್ತದೆ. ಈ ಮಾದರಿ ಎರಡು ಸ್ಥಿರ ವಿಳಾಸ ಸ್ಥಳಾವಕಾಶಗಳ ನಡುವಿನ ಸೈಟ್-ಟು-ಸೈಟ್ ಸಂಪರ್ಕಕ್ಕೆ ಸಾಕು.
ರೂಟ್-ಆಧಾರಿತ ಗೇಟ್‌ವೇ ವಿರುದ್ಧವಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತದೆ: ಅದು ಟನಲ್ ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ಒದಗಿಸುತ್ತದೆ, ಮತ್ತು ಅದರೊಳಗೆ ಏನು ಪ್ರವೇಶಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ರೂಟ್‌ಗಳು ನಿರ್ಧರಿಸುತ್ತವೆ. ಪಾಯಿಂಟ್-ಟು-ಸೈಟ್, ಮತ್ತು ಸಹವರ್ತಿಗಳ ಗುಂಪು ಬದಲಾಗುವ ಯಾವುದೇ ವಿನ್ಯಾಸ, ಆ ಇಂಟರ್ಫೇಸ್ ಇರುವಿಕೆಯನ್ನು ಅವಲಂಬಿಸಿದೆ.
ಕ್ಲೈಂಟ್ ಪೂಲ್‌ಗೆ ಆ ಇಂಟರ್ಫೇಸ್ ಏಕೆ ಬೇಕು
ಲ್ಯಾಪ್‌ಟಾಪ್ ಸಂಪರ್ಕಗೊಂಡಾಗ, ಗೇಟ್‌ವೇ ಅದಕ್ಕೆ ಪಾಯಿಂಟ್-ಟು-ಸೈಟ್ ಪೂಲ್‌ನಿಂದ ವಿಳಾಸವನ್ನು ನೀಡುತ್ತದೆ. ನಂತರ ವರ್ಚುವಲ್ ನೆಟ್‌ವರ್ಕ್‌ಗೆ ಈ ವಿಳಾಸವು ಗೇಟ್‌ವೇ ಮೂಲಕ ತಲುಪಬಹುದು ಎಂದು ಹೇಳುವ ರೂಟ್ ಬೇಕು. ಟನಲ್ ಇಂಟರ್ಫೇಸ್ ಇಲ್ಲದೆ ಆ ರೂಟ್ ಅನ್ನು ಜೋಡಿಸಲು ಏನೂ ಇಲ್ಲ.
ಪೂಲ್ ನೀವು ನಿಗದಿಪಡಿಸಿದ ಶ್ರೇಣಿಯಿಂದ ಬರುತ್ತದೆ, ಮತ್ತು ಗೇಟ್‌ವೇ ಅಲ್ಲಿಂದ ಹಂಚುತ್ತದೆ. ಆ ಶ್ರೇಣಿ ಸ್ಥಳೀಯ ನೆಟ್‌ವರ್ಕ್ ಅಥವಾ ಪೀರ್ ಮಾಡಿದ ವರ್ಚುವಲ್ ನೆಟ್‌ವರ್ಕ್‌ನೊಂದಿಗೆ ಅತಿಕ್ರಮಿಸಿದರೆ, ಸಂಘರ್ಷವು ಕ್ಲೈಂಟ್ ಸಂಪರ್ಕಗೊಂಡ ನಂತರವೇ ಕಾಣಿಸುತ್ತದೆ, ಅದನ್ನು ಕಂಡುಹಿಡಿಯಲು ಇದು ಕೆಟ್ಟ ಸಮಯ. ಸ್ಥಳಾಂತರಣೆ ಪ್ರಾರಂಭವಾಗುವ ಮೊದಲು ಪೂಲ್ ಅನ್ನು ಕಾಯ್ದಿರಿಸಿ.
ಪ್ರಕಾರವೂ ಪ್ರತಿ-ಸಂಪರ್ಕ ಸೆಟ್ಟಿಂಗ್ ಅಲ್ಲ. ಒಂದು ಗೇಟ್‌ವೇಗೆ ಒಂದೇ ಪ್ರಕಾರ ಇರುತ್ತದೆ, ಮತ್ತು ಅದು ಹೊಂದಿರುವ ಪ್ರತಿ ಸಂಪರ್ಕವೂ ಅದಕ್ಕೆ ಅನುಗುಣವಾಗಿ ವರ್ತಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಮಿಶ್ರ ವಿನ್ಯಾಸಕ್ಕೆ ಎರಡನೇ ಸಂಪರ್ಕವಲ್ಲ, ಎರಡನೇ ಗೇಟ್‌ವೇ ಬೇಕು.
ಪ್ರಕಾರ ರಚನೆಯ ಸಮಯದಲ್ಲಿ ಸ್ಥಿರವಾಗಿರುತ್ತದೆ
Microsoft ಹೇಳುವಂತೆ ವರ್ಚುವಲ್ ನೆಟ್‌ವರ್ಕ್ ಗೇಟ್‌ವೇಯನ್ನು ನಿಯೋಜನೆಯ ನಂತರ ನೀತಿ-ಆಧಾರಿತ ಮತ್ತು ರೂಟ್-ಆಧಾರಿತ ನಡುವೆ ಬದಲಾಯಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. ಪರಿವರ್ತನಾ ಆದೇಶವೂ ಇಲ್ಲ, ಪೋರ್ಟಲ್‌ನಲ್ಲಿ ಟಾಗಲ್ ಕೂಡ ಇಲ್ಲ. ಅದೇ ಸಬ್‌ನೆಟ್‌ನಲ್ಲಿ ಎರಡನೇ ಗೇಟ್‌ವೇ ರಚಿಸುವುದೂ ಪರ್ಯಾಯ ಉಪಾಯವಲ್ಲ, ಏಕೆಂದರೆ Azure ಪ್ರತಿ ವರ್ಚುವಲ್ ನೆಟ್‌ವರ್ಕ್‌ಗೆ ಒಂದು ಗೇಟ್‌ವೇಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಆದ್ದರಿಂದ ಸ್ಥಳಾಂತರಣೆ ಎಂದರೆ ತೆಗೆದುಹಾಕುವುದು, ಮತ್ತೆ ನಿರ್ಮಿಸುವುದು, ಮತ್ತೆ ಸಂಪರ್ಕಿಸುವುದು.
ಇದು SKU ನಿರ್ಣಯವನ್ನೂ ಅದೇ ನಿರ್ಮಾಣದಲ್ಲಿ ಸೇರಿಸುತ್ತದೆ. ನಂತರ ದೊಡ್ಡ SKU ಗೆ ಹೋಗುವುದು ಇನ್ನೊಂದು ಅಡಚಣೆಯೊಂದಿಗೆ ಇನ್ನೊಂದು ಗೇಟ್‌ವೇ ಬದಲಿ.
ಒಂದು ಗೇಟ್‌ವೇ, ಒಂದು GatewaySubnet
ಗೇಟ್‌ವೇ GatewaySubnet ಎಂಬ ಸಬ್‌ನೆಟ್‌ನಲ್ಲಿ ವಾಸಿಸುತ್ತದೆ, ಮತ್ತು ಅದನ್ನು ಒಂದೇ ಗೇಟ್‌ವೇ ಆಕ್ರಮಿಸುತ್ತದೆ. ಆ ಸಬ್‌ನೆಟ್‌ನ ಗಾತ್ರ ನಿರ್ಧಾರಣೆ ಸಿದ್ಧತೆಯ ಭಾಗ, ಏಕೆಂದರೆ ದೊಡ್ಡ SKU ಗೆ ಹೆಚ್ಚು ವಿಳಾಸಗಳು ಬೇಕು ಮತ್ತು ಸಬ್‌ನೆಟ್ ಅನ್ನು ನಂತರ ಚಿಕ್ಕದಾಗಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. ಏನನ್ನೂ ಸ್ಪರ್ಶಿಸುವ ಮೊದಲು ಪ್ರಸ್ತುತ ಸೈಟ್-ಟು-ಸೈಟ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳು, ಹಂಚಿದ ಕೀ, ಸ್ಥಳೀಯ ನೆಟ್‌ವರ್ಕ್ ಗೇಟ್‌ವೇ ಮತ್ತು ಪರಿಣಾಮಕಾರಿ ರೂಟ್‌ಗಳನ್ನು ದಾಖಲಿಸಿ. ನಂತರ ವಿಂಡೋವನ್ನು ಅಡಚಣೆಯಾಗಿ ಪರಿಗಣಿಸಿ, ಏಕೆಂದರೆ ಹೊಸ ಸಂಪರ್ಕ ಕಾನ್ಫಿಗರ್ ಆಗುವವರೆಗೆ ಸೈಟ್-ಟು-ಸೈಟ್ ಟನಲ್ ಆಫ್ ಆಗಿರುತ್ತದೆ.
ಅಡಚಣೆಯನ್ನು ಸೀಮಿತವಾಗಿ ಇರಿಸುವ ಮರುನಿರ್ಮಾಣ ಕ್ರಮ: ರೂಟ್-ಆಧಾರಿತ ಗೇಟ್‌ವೇ ರಚಿಸಿ, ಅದೇ ಸ್ಥಳೀಯ ನೆಟ್‌ವರ್ಕ್ ಗೇಟ್‌ವೇಗೆ ಸೈಟ್-ಟು-ಸೈಟ್ ಸಂಪರ್ಕವನ್ನು ಮತ್ತೆ ರಚಿಸಿ, ಟನಲ್ ಮತ್ತು ಒಂದು ಹೋಸ್ಟ್-ಟು-ಹೋಸ್ಟ್ ವಿನಂತಿಯನ್ನು ದೃಢೀಕರಿಸಿ, ಮತ್ತು ನಂತರವೇ ಪಾಯಿಂಟ್-ಟು-ಸೈಟ್ ಸೇರಿಸಿ ಹೊಸ ಕ್ಲೈಂಟ್ ಪ್ಯಾಕೇಜ್ ರಚಿಸಿ.
ಬದಲಿ ಏನನ್ನು ಸರಿಪಡಿಸುವುದಿಲ್ಲ
ಎರಡನೇ ಮಿತಿ Azure ನದಲ್ಲ, ಸಹವರ್ತಿಯದ್ದು. ನೀತಿ-ಆಧಾರಿತ ಸ್ಥಳೀಯ ಸಾಧನವು ತಾನು ಸಂಪರ್ಕಿಸುವ ವರ್ಚುವಲ್ ನೆಟ್‌ವರ್ಕ್‌ಗೆ ಮಾತ್ರ ತಲುಪಬಲ್ಲದು, ಮತ್ತು ಅದೇ ಗೇಟ್‌ವೇ ಮೂಲಕ ಇತರ ಸ್ಥಳೀಯ ನೆಟ್‌ವರ್ಕ್‌ಗಳಿಗೆ ಅಥವಾ ಇತರ ವರ್ಚುವಲ್ ನೆಟ್‌ವರ್ಕ್‌ಗಳಿಗೆ ಹಾದುಹೋಗಲು ಸಾಧ್ಯವಿಲ್ಲ. Azure ಬದಿಯನ್ನು ಬದಲಿಸುವುದರಿಂದ ಸಹವರ್ತಿ ಏನನ್ನು ಆಯ್ಕೆ ಮಾಡಬಹುದು ಎಂಬುದು ಬದಲಾಗುವುದಿಲ್ಲ.
ಅಗತ್ಯವು ನಿಜವಾಗಿಯೂ ಸೈಟ್‌ಗಳ ನಡುವಿನ ಸಾಗಣೆ ಆಗಿದ್ದರೆ, ಉತ್ತರ ರೂಟ್-ಆಧಾರಿತ ಸಹವರ್ತಿ ಸಾಧನ ಅಥವಾ ಪ್ರತಿ ಗಮ್ಯಸ್ಥಾನವೂ ಪ್ರತ್ಯೇಕವಾಗಿ ಕೊನೆಗೊಳ್ಳುವ ಟೋಪಾಲಜಿ. ದಿನಾಂಕವನ್ನು ಭರವಸೆ ನೀಡುವ ಮೊದಲು ಇದನ್ನು ನಿರ್ಧರಿಸಿ, ಏಕೆಂದರೆ ಕೇವಲ ಗೇಟ್‌ವೇ ಬದಲಿ ಅದನ್ನು ನೀಡುವುದಿಲ್ಲ.
ಕಾರ್ಯಾಚರಣೆಗಳು ಮತ್ತು ಪರಿಶೀಲನೆಗಳ ಕ್ರಮ
ಪ್ರತಿ ಸಾಮರ್ಥ್ಯವನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಪರಿಶೀಲಿಸಿ. ಮೊದಲು ಸೈಟ್-ಟು-ಸೈಟ್ ಟನಲ್ ಸ್ಥಿತಿ ಮತ್ತು ಒಂದು ಹೋಸ್ಟ್-ಟು-ಹೋಸ್ಟ್ ವಿನಂತಿ, ನಂತರ ಪಾಯಿಂಟ್-ಟು-ಸೈಟ್ ಸಂಪರ್ಕ ಮತ್ತು ಒಂದು ಖಾಸಗಿ ಸಂಪನ್ಮೂಲ, ನಂತರ ವಿನ್ಯಾಸವು ಹೇಳಿಕೊಳ್ಳುವ ಯಾವುದೇ ಸಾಗಣೆ ಮಾರ್ಗ. ಹಸಿರು ಗೇಟ್‌ವೇ ಸ್ಥಿತಿ ಭದ್ರತಾ ಸಂಬಂಧವು ಮೇಲೆ ಬಂದಿದೆ ಎಂದು ಮಾತ್ರ ಸಾಬೀತುಪಡಿಸುತ್ತದೆ, ಹೆಚ್ಚೇನೂ ಇಲ್ಲ. ಪರಿಶೀಲನೆಗಳನ್ನು ಅದೇ ಕ್ರಮದಲ್ಲಿ ಇರಿಸಿ ಆದ್ದರಿಂದ ವೈಫಲ್ಯವು ಅದನ್ನು ತಂದ ಹಂತವನ್ನು ಸೂಚಿಸುತ್ತದೆ.
ಯಾವುದೇ ಟೋಪಾಲಜಿ ಬದಲಾವಣೆಯ ನಂತರ ಕ್ಲೈಂಟ್ ಪ್ಯಾಕೇಜ್‌ಗಳನ್ನು ಮತ್ತೆ ರಚಿಸಿ, ಮತ್ತು ಪೂಲ್ ಅನ್ನು ಪ್ರತಿ ಸ್ಥಳೀಯ ಮತ್ತು ಪೀರ್ ಮಾಡಿದ ಶ್ರೇಣಿಯಿಂದ ದೂರವಿಡಿ. ಮಿತಿಗಳು ಮತ್ತು SKU ವ್ಯತ್ಯಾಸಗಳು Azure VPN Gateway ಸೆಟ್ಟಿಂಗ್‌ಗಳ ಉಲ್ಲೇಖದಲ್ಲಿ ಸಂಗ್ರಹವಾಗಿವೆ.