Azure VM ನಲ್ಲಿ RRAS ಬೆಂಬಲಿತವಲ್ಲ: ವಿನ್ಯಾಸಕ್ಕೂ ಮೊದಲು ಪರಿಶೀಲಿಸಿ

ನೀವು ಪೋರ್ಟಲ್ ತೆರೆಯುತ್ತೀರಿ, Windows Server 2022 ಅನ್ನು ಸಬ್ನೆಟ್ಗೆ ನಿಯೋಜಿಸುತ್ತೀರಿ, ಮತ್ತು Remote Access ಪಾತ್ರವು ಸ್ವಚ್ಛವಾಗಿ ಸ್ಥಾಪನೆಯಾಗುತ್ತದೆ. ಆ ಅನುಕ್ರಮವು ಇನ್ಸ್ಟಾಲರ್ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂದು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ, Microsoft ಈ ಸಂರಚನೆಯನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ ಎಂದಲ್ಲ. Azure ವರ್ಚುವಲ್ ಯಂತ್ರಗಳಿಗಾಗಿ ಪ್ರಕಟಿತ ಸರ್ವರ್ ಸಾಫ್ಟ್ವೇರ್ ಬೆಂಬಲ ಮಾರ್ಗಸೂಚಿ RRAS ಅನ್ನು Azure VM ನಲ್ಲಿ ಬೆಂಬಲಿತವಲ್ಲದ Windows Server ವೈಶಿಷ್ಟ್ಯಗಳ ಪಟ್ಟಿಗೆ ಸೇರಿಸುತ್ತದೆ, ಮತ್ತು ಇದು ದೋಷನಿವಾರಣೆಯ ವಿವರವಲ್ಲ, ವಾಸ್ತುಶಿಲ್ಪ ನಿರ್ಧಾರ. ಮೇಲೇರುವ ಸುರಂಗವು ನಿಯೋಜನೆಯನ್ನು ಬೆಂಬಲ ಗಡಿಯ ಒಳಗೆ ಸರಿಸುವುದಿಲ್ಲ.

ಕೆಳಗಿನ ಮಾರ್ಗದರ್ಶನವು ಬೆಂಬಲ ಪುಟದಿಂದ ಪ್ರಾರಂಭವಾಗಿ, ನಂತರ ಅಗತ್ಯತೆಗಳು ಮತ್ತು ಬದಲಿ ಆಯ್ಕೆಗಳ ಕಡೆಗೆ ಸಾಗುತ್ತದೆ.

ಪ್ರಯೋಗಾಲಯದಲ್ಲಿ ಅಲ್ಲ, ಬೆಂಬಲ ಪುಟದಿಂದ ಪ್ರಾರಂಭಿಸಿ

ಏನನ್ನಾದರೂ ಅಳೆಯುವ ಮೊದಲು Azure VM ಬೆಂಬಲ ಮಾರ್ಗಸೂಚಿ ಓದಿ. ಇದು Windows Server ಅನ್ನು ಒಂದೇ ವಿಭಜಿಸದ ಬ್ಲಾಕ್ ಎಂದು ಪರಿಗಣಿಸುವ ಬದಲು ಬೆಂಬಲಿತ ಉತ್ಪನ್ನಗಳು, ಪಾತ್ರಗಳು ಮತ್ತು ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಬೇರ್ಪಡಿಸುತ್ತದೆ. ನಿಮ್ಮ ಉದ್ದೇಶಿತ ಕೆಲಸದ ಹೊರೆ ನಿಜವಾಗಿ ಯಾವ ಸಾಲಿನ ಅಡಿಯಲ್ಲಿ ಬರುತ್ತದೆ ಎಂಬುದನ್ನು ಗಮನಿಸಿ, ಏಕೆಂದರೆ ಕನ್ಸೋಲ್ನಲ್ಲಿ ಸಂಬಂಧಿತವಾಗಿ ಕಾಣುವ ಎರಡು ಘಟಕಗಳು ವಿಭಿನ್ನ ಸಾಲುಗಳಲ್ಲಿ ಇರಬಹುದು.

ಪುಟ ತೆರೆದಿರುವಾಗಲೇ ವಿನ್ಯಾಸ ದಾಖಲೆಯಲ್ಲಿ ಉಲ್ಲೇಖವನ್ನು ಬರೆಯಿರಿ. ಬೆಂಬಲ ಸ್ಥಿತಿಯು ಮೂಲವನ್ನು ಹೊಂದಿರುವ ಸತ್ಯ, ಮತ್ತು ಅದನ್ನು ಉಲ್ಲೇಖಿಸಲಾಗದ ವಿನ್ಯಾಸ ಪರಿಶೀಲನೆಯನ್ನು ಡೆಮೊ ಹೊಂದಿರುವವರು ವಾದದಲ್ಲಿ ಸೋಲಿಸುತ್ತಾರೆ.

OS ಬೆಂಬಲವನ್ನು ಪಾತ್ರ ಮತ್ತು ವೈಶಿಷ್ಟ್ಯ ಬೆಂಬಲದಿಂದ ಬೇರ್ಪಡಿಸಿ

ಅದೇ ಮಾರ್ಗಸೂಚಿ Network Policy and Access Services ಅನ್ನು ಬೆಂಬಲಿತ ಪಾತ್ರಗಳಲ್ಲಿ ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ, ಆದರೆ RRAS ಅನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಬೆಂಬಲಿತವಲ್ಲ ಎಂದು ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ. ಆ ಎರಡು ನಮೂದುಗಳು ವಿಭಿನ್ನ ವಿಷಯಗಳನ್ನು ವಿವರಿಸುತ್ತವೆ, ಮತ್ತು ಅವುಗಳನ್ನು “ದೂರಸ್ಥ ಪ್ರವೇಶ ಬೆಂಬಲಿತವಾಗಿದೆ” ಎಂದು ವಿಲೀನಗೊಳಿಸುವುದು ತಪ್ಪಾದ ಓದಿನ ಆಧಾರದ ಮೇಲೆ ಯೋಜನೆಯನ್ನು ಅನುಮೋದಿಸುವ ಮಾರ್ಗ. ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ ಬೆಂಬಲಿತವಾಗಿರುವುದು ತನ್ನದೇ ಸಾಲನ್ನು ಹೊಂದಿರುವ ವೈಶಿಷ್ಟ್ಯದ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ.

ಮಿತಿಯು ಕೆಲವೊಮ್ಮೆ ಉಲ್ಲೇಖಿಸುವುದಕ್ಕಿಂತಲೂ ಕಿರಿದಾಗಿದೆ. ಇದು Azure VM ಒಳಗೆ ಚಲಿಸುವ ಆ ವೈಶಿಷ್ಟ್ಯಕ್ಕೆ ಸಂಬಂಧಿಸಿದೆ; ಖಾಸಗಿ ನೆಟ್ವರ್ಕ್ Azure ಗೆ ಸಂಪರ್ಕಿಸಲಾಗದು ಎಂದಲ್ಲ, ಮತ್ತು RRAS ಎಲ್ಲೆಡೆ ಬೆಂಬಲಿತವಲ್ಲ ಎಂದೂ ಹೇಳುವುದಿಲ್ಲ. ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ಸರಿಯಾಗಿ ಮುಂದಕ್ಕೆ ಕಳುಹಿಸುವ ಹಳೆಯ ಪ್ರಯೋಗಾಲಯವು ಪ್ಯಾಕೆಟ್ಗಳ ಬಗ್ಗೆ ಸಾಕ್ಷ್ಯ, ಬೆಂಬಲ ಹೇಳಿಕೆಯ ಬಗ್ಗೆ ಅಲ್ಲ.

ಉಳಿದ ಯೋಜನೆಯ ಉದ್ದಕ್ಕೂ ಆ ಎರಡು ಪ್ರಶ್ನೆಗಳನ್ನು ಬೇರ್ಪಡಿಸಿ: ಅದು ಕೆಲಸ ಮಾಡುತ್ತದೆಯೇ, ಮತ್ತು ಅದು ಬೆಂಬಲಿತವೇ. ಪ್ರತಿಯೊಂದಕ್ಕೂ ವಿಭಿನ್ನ ಉತ್ತರಗಳು ಮತ್ತು ಕೆಲವೊಮ್ಮೆ ವಿಭಿನ್ನ ಮಾಲೀಕರು ಬೇಕಾಗುತ್ತಾರೆ.

ವಿನ್ಯಾಸವು ನಿಜವಾಗಿ ಏನು ಮಾಡಬೇಕು ಎಂಬುದನ್ನು ಬರೆಯಿರಿ

ಬದಲಿಯನ್ನು ಆಯ್ಕೆ ಮಾಡುವ ಮೊದಲು ಸೈಟ್ ಪಟ್ಟಿಯನ್ನು ಉತ್ಪನ್ನವನ್ನು ಅಳೆಯಬಹುದಾದ ಅಗತ್ಯತೆಗಳಾಗಿ ಪರಿವರ್ತಿಸಿ:

• ಶಾಖಾ ಸಾಧನಗಳು ಈಗಾಗಲೇ ಮಾತನಾಡುವ ಸುರಂಗ ಪ್ರೋಟೋಕಾಲ್ಗಳು, ಮತ್ತು ಯಾವುದೇ ಸೈಟ್ಗೆ ಕ್ರಿಯಾತ್ಮಕ ರೂಟಿಂಗ್ ಬೇಕೇ.
• ದೂರದ ಪೂರ್ವಪ್ರತ್ಯಯಗಳು, ರೂಟಿಂಗ್ ಬದಲು ಅನುವಾದ ಬೇಕಾಗುವ ಯಾವುದೇ ಅತಿವ್ಯಾಪಿಸುವ ವಿಳಾಸ ಸ್ಥಳವನ್ನು ಒಳಗೊಂಡಂತೆ.
• Azure ಜೊತೆ ರೂಟ್ ವಿನಿಮಯ, ಮತ್ತು ರೂಟಿಂಗ್ ಕೋಷ್ಟಕದ ಪ್ರತಿ ನಮೂದಿನ ಮಾಲೀಕರು ಯಾರು.
• ಅತ್ಯಂತ ನಿರಸನದ ಗಂಟೆ ತಡೆದುಕೊಳ್ಳಬೇಕಾದ ಥ್ರೂಪುಟ್ ಮತ್ತು ಸಂಪರ್ಕಗಳ ಸಂಖ್ಯೆ.
• ಸೈಟ್ ಮಾಲೀಕರು ಒಪ್ಪಿರುವ ಫೇಲ್ಓವರ್ ವರ್ತನೆ, ನೀವು ನಿರ್ಮಿಸಬಹುದಾದದ್ದು ಮಾತ್ರವಲ್ಲ.

NAT ಎಂಬುದು ಕೈಬಿಡಲ್ಪಡುವ ಮತ್ತು ನಂತರ ಇಡೀ ವಿನ್ಯಾಸವನ್ನು ನಿರ್ಧರಿಸುವ ಅಂಶ. IPsec ಸ್ಥಾಪಿಸಬಲ್ಲ ಸಾಧನವು ತಾನು ಬದಲಾಯಿಸುತ್ತಿರುವ RRAS ನಿಯೋಜನೆಗಿಂತ ವಿಭಿನ್ನವಾಗಿ ವಿಳಾಸಗಳನ್ನು ಅನುವಾದಿಸಬಹುದು, ಮತ್ತು ಇದು ಶಾಖೆಯು ಯಾವ ವಿಳಾಸಗಳನ್ನು ಮೂಲ ಎಂದು ನೋಡುತ್ತದೆ ಮತ್ತು ನಿಮ್ಮ ಲಾಗ್ಗಳು ಏನನ್ನು ದಾಖಲಿಸುತ್ತವೆ ಎಂಬುದನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ.

ಪಟ್ಟಿಯನ್ನು ನೆಟ್ವರ್ಕ್ ಮಾಲೀಕರ ಬಳಿಗೆ ಒಯ್ಯಿರಿ ಮತ್ತು ಯಾವುದೇ ಉತ್ಪನ್ನ ಚರ್ಚೆಗೂ ಮೊದಲು ಅದನ್ನು ದೃಢೀಕರಿಸಿ. ಅಸ್ಪಷ್ಟ ಅಗತ್ಯತೆಗಳು ಪ್ರತಿ ಮಾರಾಟಗಾರ ಹೋಲಿಕೆಯನ್ನು ಆದ್ಯತೆಯ ವಾದವಾಗಿ ಬದಲಾಯಿಸುತ್ತವೆ.

ಆ ಅಗತ್ಯತೆಗಳ ವಿರುದ್ಧ ಬದಲಿಗಳನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡಿ

Azure ನ ನಿರ್ವಹಿತ ಸಂಪರ್ಕ ಸೇವೆಗಳು ಮತ್ತು ಮಾರಾಟಗಾರ-ಬೆಂಬಲಿತ ನೆಟ್ವರ್ಕ್ ವರ್ಚುವಲ್ ಉಪಕರಣಗಳು ಎರಡನ್ನೂ ಒಂದೇ ಪಟ್ಟಿಯ ವಿರುದ್ಧ ಅಂಕ ನೀಡಬೇಕು. IPsec ಕೊನೆಗೊಳಿಸಬಲ್ಲದು ಎಂಬ ಕಾರಣದಿಂದ ಮಾತ್ರ ಅವುಗಳಲ್ಲಿ ಯಾವುದನ್ನೂ RRAS VM ನ ನೇರ ಸಮಾನ ಎಂದು ಭಾವಿಸಬೇಡಿ: NAT ಮಾದರಿ ಮತ್ತು ರೂಟ್ಗಳ ಮಾಲೀಕತ್ವ ಮತ್ತು ಹೆಚ್ಚಿನ ಲಭ್ಯತೆಯ ವಿನ್ಯಾಸವು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಸೈಟ್ಗಳು ಹೇಗೆ ಸಂಪರ್ಕಗೊಳ್ಳುತ್ತವೆ ಮತ್ತು ಅವುಗಳ ಉತ್ತರಗಳು ಎಲ್ಲಿಗೆ ಮರಳುತ್ತವೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತವೆ. ಪ್ರತಿ ಅಭ್ಯರ್ಥಿಯನ್ನು ಕಾಗದದ ಮೇಲೆ ಪಟ್ಟಿಯ ವಿರುದ್ಧ ಅಂಕ ನೀಡಿ ಮತ್ತು ಯಾವ ಅಗತ್ಯತೆಗಳನ್ನು ಅದು ವಿಫಲಗೊಳಿಸುತ್ತದೆ ಎಂದು ಬರೆಯಿರಿ, ಏಕೆಂದರೆ ಆ ಟಿಪ್ಪಣಿಯೇ ಆಯ್ಕೆಯನ್ನು ನಂತರ ಪರಿಶೀಲಿಸಬಹುದಾದಂತೆ ಮಾಡುತ್ತದೆ.

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

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

RRAS VM ಈಗಾಗಲೇ ಚಲಿಸುತ್ತಿದ್ದರೆ

ಶೋಧನೆ ಅದನ್ನು ಅಳಿಸಲು ಕಾರಣವಲ್ಲ. ಆ VM ಸಂಗ್ರಹಿಸಿದ ಅವಲಂಬನೆಗಳ ಸುತ್ತ ಬದಲಾವಣೆಯನ್ನು ಯೋಜಿಸಿ: ಇತರ ಸಬ್ನೆಟ್ಗಳು ಅವಲಂಬಿಸಿರುವ ರೂಟ್ಗಳು, ಮೂಲ ವಿಳಾಸಗಳನ್ನು ಮರೆಮಾಡುವ NAT ನಿಯಮಗಳು, ಮತ್ತು ಮಾನಿಟರಿಂಗ್ ಅದರ ವಿಳಾಸದಿಂದ ನಿರೀಕ್ಷಿಸಲು ಕಲಿತ ಎಲ್ಲವೂ. ಬೆಂಬಲಿತ ಗುರಿಯನ್ನು ಪಕ್ಕದಲ್ಲಿ ವಿನ್ಯಾಸ ಮಾಡಿ ಮಾನ್ಯಗೊಳಿಸುವಾಗ ಅಗತ್ಯ ರೂಟ್ಗಳು ಮತ್ತು ಪರೀಕ್ಷಿತ ಮರುಪ್ರಾಪ್ತಿ ಮಾರ್ಗವನ್ನು ಸಂರಕ್ಷಿಸಿ.

ಬೆಂಬಲಕ್ಷಮತೆ ಮತ್ತು ತಾಂತ್ರಿಕ ರೋಗನಿರ್ಣಯವನ್ನು ಎಲ್ಲಾ ಸಮಯದಲ್ಲೂ ಪ್ರತ್ಯೇಕ ಸಂಶೋಧನೆಗಳಾಗಿ ಇರಿಸಿ. ಬೆಂಬಲಿತವಲ್ಲದ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಸಾಮಾನ್ಯ ರೂಟಿಂಗ್ ದೋಷವೂ ಇರಬಹುದು, ಮತ್ತು ಆ ದೋಷವನ್ನು ಸರಿಪಡಿಸುವುದು ಅದರ ಬೆಂಬಲ ಸ್ಥಿತಿಯನ್ನು ಬದಲಾಯಿಸುವುದಿಲ್ಲ. ಎರಡೂ ಹೇಳಿಕೆಗಳು ವರದಿಗೆ ಸೇರಿದ್ದವು, ಮತ್ತು ಒಂದೂ ಇನ್ನೊಂದನ್ನು ರದ್ದುಗೊಳಿಸುವುದಿಲ್ಲ.

ಬೆಂಬಲ ಉಲ್ಲೇಖ, ಅಗತ್ಯತೆಗಳ ಪಟ್ಟಿ, ಆಯ್ದ ಬದಲಿ ಮತ್ತು ಕಟ್ಓವರ್ ಕ್ರಮವನ್ನು ದಾಖಲಿಸಿ ಮಾರ್ಗದರ್ಶನವನ್ನು ಮುಗಿಸಿ. ಲೆಕ್ಕಪರಿಶೋಧಕ ಅಥವಾ ಹೊಸ ತಂಡದ ಸದಸ್ಯರು ಮೊದಲು ಕೇಳುವುದೇ ಈ ನಾಲ್ಕು ಅಂಶಗಳನ್ನು.