VPN ಕ್ಲೈಂಟ್‌ಗಳಿಗಾಗಿ AD ಸೈಟ್ ಮ್ಯಾಪಿಂಗ್ ಮತ್ತು ಡೊಮೇನ್ ಕಂಟ್ರೋಲರ್ ಪಿನಿಂಗ್

VPN ಪೂಲ್‌ನಲ್ಲಿರುವ ದೂರಸ್ಥ ಪ್ರವೇಶ ಕ್ಲೈಂಟ್‌ಗಳು ಕೊನೆಗೆ ಜಗತ್ತಿನ ಇನ್ನೊಂದು ತುದಿಯಲ್ಲಿರುವ ಡೊಮೇನ್ ಕಂಟ್ರೋಲರ್ ಜೊತೆ ಮಾತನಾಡಬಹುದು, ಮತ್ತು ಅದನ್ನು ಸರಿಪಡಿಸಲು ಎರಡು ದಾರಿಗಳಿವೆ: ಪೂಲ್ ಅನ್ನು ಸರಿಯಾದ ಕಂಟ್ರೋಲರ್‌ಗಳಿರುವ ಸೈಟ್‌ಗೆ ಬದ್ಧವಾದ Active Directory ಸಬ್‌ನೆಟ್ ಆಗಿ ವಿವರಿಸುವುದು, ಅಥವಾ ಕ್ಲೈಂಟ್ ಅಥವಾ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಒಂದು ನಿರ್ದಿಷ್ಟ ಕಂಟ್ರೋಲರ್‌ಗೆ ಪಿನ್ ಮಾಡುವುದು. ಮೊದಲನೆಯದು DC Locator ಕಾರ್ಯನಿರ್ವಹಿಸಬಹುದಾದ ಟೋಪಾಲಜಿ ಹೇಳಿಕೆ. ಎರಡನೆಯದು ಟೋಪಾಲಜಿಯನ್ನು ಸಂಪೂರ್ಣ ನಿರ್ಲಕ್ಷಿಸುವ ಪ್ರತಿ-ಅಪ್ಲಿಕೇಶನ್ ಓವರ್‌ರೈಡ್. ಅವು ಬೇರೆ ಬೇರೆ ವೆಚ್ಚ ತಗುತ್ತವೆ, ಮತ್ತು ಇಂದು ವೇಗವಾದದ್ದನ್ನು ಹಿಡಿಯುವುದೇ ಡೈರೆಕ್ಟರಿ ತಂಡ ಕೊನೆಗೆ ಎರಡನ್ನೂ ನಿರ್ವಹಿಸುವ ರೀತಿ.

ಪ್ರತಿ ವಿಧಾನ ನಿಜವಾಗಿ ಏನನ್ನು ಬದಲಿಸುತ್ತದೆ

ಸಬ್‌ನೆಟ್ ಆಬ್ಜೆಕ್ಟ್ ಎಂಬುದು ವಿಳಾಸ ಶ್ರೇಣಿ ಯಾವ ಸೈಟ್‌ಗೆ ಸೇರಿದೆ ಎಂದು ಹೇಳುವ ಡೈರೆಕ್ಟರಿ ದಾಖಲೆ. Active Directory ಮಾಡ್ಯೂಲ್ ಮತ್ತು ಇರುವ ಸೈಟ್ ಜೊತೆಗೆ, ಕಾರ್ಯಾಚರಣೆ ಮುಂಚಿತವಾಗಿ ನೋಡಲು ಸಾಧ್ಯವಾಗುವಷ್ಟು ಚಿಕ್ಕದು:

New-ADReplicationSubnet -Name "10.90.0.0/24" -Site "Remote-Access-Hub" -WhatIf
Get-ADReplicationSubnet -Filter * | Select-Object Name,Site

-WhatIf ಡೈರೆಕ್ಟರಿ ಬರವಣಿಗೆಯನ್ನು ಮುಂಚಿತವಾಗಿ ತೋರಿಸುತ್ತದೆ. ಅದು ಆಬ್ಜೆಕ್ಟ್ ರಚಿಸುವುದಿಲ್ಲ ಮತ್ತು ಆ ಶ್ರೇಣಿಯ ಕ್ಲೈಂಟ್ ಏನನ್ನಾದರೂ ತಲುಪಬಹುದೇ ಎಂದು ಪರೀಕ್ಷಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಜನರು ನಿರೀಕ್ಷಿಸುವ ಭಾಗ ಅದೇ. DC Locator ಸೈಟ್ ಮಾದರಿಯನ್ನು ಓದುತ್ತದೆ ಯಾವಾಗ ಸೇವಾ ದಾಖಲೆಗಳನ್ನು ಪರಿಹರಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ನಿಖರವಾದ ಸಬ್‌ನೆಟ್ ಆಬ್ಜೆಕ್ಟ್ ಕ್ಲೈಂಟ್‌ಗೆ ನೀಡುವುದನ್ನು ಬದಲಿಸುತ್ತದೆ.

ಪಿನಿಂಗ್ ಬೇರೆ ಪದರದಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತದೆ. ಅಪ್ಲಿಕೇಶನ್ ಕಾನ್ಫಿಗ್‌ನಲ್ಲಿ ಸ್ಥಿರ ಕಂಟ್ರೋಲರ್ ಹೆಸರು, ಒಳಗೆ ಹೋಸ್ಟ್ ಇರುವ LDAP ಸ್ಟ್ರಿಂಗ್, ಅಥವಾ ಆದ್ಯತೆಯ ಸರ್ವರ್ ಹೆಸರಿಸುವ ರಿಜಿಸ್ಟ್ರಿ ಮೌಲ್ಯ—ಎಲ್ಲವೂ ಪತ್ತೆಹಚ್ಚುವಿಕೆಯನ್ನು ಮಾರ್ಗದಿಂದ ತೆಗೆಯುತ್ತವೆ. ಅಪ್ಲಿಕೇಶನ್ ಯಾರಾದರೂ ಸೆಟ್ಟಿಂಗ್ ಬದಲಿಸುವವರೆಗೆ ಆ ಕಂಟ್ರೋಲರ್ ಜೊತೆ ಮಾತನಾಡುತ್ತದೆ, ಮತ್ತು ವೈಫಲ್ಯದಲ್ಲಿ ಬದಲಾವಣೆ ಎಂಬುದು ಆ ಅಪ್ಲಿಕೇಶನ್ ಜಾರಿಗೊಳಿಸುವುದು.

ಸಬ್‌ನೆಟ್ ಮ್ಯಾಪಿಂಗ್ ಎಲ್ಲಿ ಗೆಲ್ಲುತ್ತದೆ

ಪೂಲ್ ಮ್ಯಾಪ್ ಮಾಡುವುದು DC Locator ಬಳಸುವ ಪ್ರತಿ ಕ್ಲೈಂಟ್‌ಗೆ ಜಾಲಬಂಧ ಸ್ಥಳವನ್ನು ಒಮ್ಮೆ ವಿವರಿಸುತ್ತದೆ. ಪೂಲ್ ಒಂದು /24 ರಿಂದ ಮೂರಕ್ಕೆ ಬೆಳೆದಾಗ, ಮಾದರಿ ಅಪ್ಲಿಕೇಶನ್ ಪಟ್ಟಿಯಲ್ಲಿ ಅಲ್ಲ, ಎರಡು ಅಥವಾ ಮೂರು ಆಬ್ಜೆಕ್ಟ್‌ಗಳಲ್ಲಿ ಬದಲಾಗುತ್ತದೆ. ಅದೇ ಸಂಪೂರ್ಣ ಪ್ರಯೋಜನ, ಮತ್ತು ಕ್ಲೈಂಟ್ ಜನಸಂಖ್ಯೆ ನಿಮ್ಮ ನಿಯಂತ್ರಣದಲ್ಲಿಲ್ಲದಿದ್ದಾಗ ಅದು ದೊಡ್ಡದು.

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

ಎರಡನೇ ಮಿತಿ: ಸೈಟ್ ಮಾದರಿ ಆದ್ಯತೆ ಮತ್ತು ಟೋಪಾಲಜಿ ಹೇಳಿಕೆ. ಅದು ಕಂಟ್ರೋಲರ್ ಅನ್ನು ತಲುಪಬಹುದಾದಂತೆ ಮಾಡುವುದಿಲ್ಲ ಮತ್ತು ಬಳಕೆದಾರರಿಗೆ ಏನನ್ನೂ ನೀಡುವುದಿಲ್ಲ. ತಲುಪುವಿಕೆಯನ್ನು ಮಾರ್ಗಗಳು ಮತ್ತು ಫೈರ್‌ವಾಲ್ ನೀತಿ ನೀಡುತ್ತವೆ; ಅನುಮತಿಯನ್ನು ಖಾತೆ ನೀತಿ ನೀಡುತ್ತದೆ.

ಪಿನಿಂಗ್ ಎಲ್ಲಿ ಗೆಲ್ಲುತ್ತದೆ

ಪತ್ತೆಹಚ್ಚುವಿಕೆ ಕೆಲಸ ಮಾಡಲಾಗದಿದ್ದಾಗ ಪಿನಿಂಗ್ ಸರಿಯಾದ ಉತ್ತರ: ನೀವು ಬದಲಿಸಲಾಗದ ಹೆಸರಿನಿಂದ ಕಂಟ್ರೋಲರ್ ಪರಿಹರಿಸುವ ಹಳೆಯ ಅಪ್ಲಿಕೇಶನ್, ನಿಖರವಾಗಿ ಒಂದು ಕಂಟ್ರೋಲರ್ ವಿಳಾಸಕ್ಕೆ ಅನುಮತಿ ನೀಡುವ ಫಿಲ್ಟರ್, ಅಥವಾ ಕಂಟ್ರೋಲರ್ ಅಪ್ಲಿಕೇಶನ್ ವಿನ್ಯಾಸದ ಭಾಗವಾಗಿರುವ ಸ್ಥಿರ ಸರ್ವರ್ ಗುಂಪು. ಆ ಸಂದರ್ಭಗಳಲ್ಲಿ ಪಿನ್ ಕಿರುಮಾರ್ಗವಲ್ಲ, ನಿಜವಾದ ಮಿತಿಯ ದಾಖಲೆ.

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

ಡೊಮೇನ್‌ನ ಸಾಮಾನ್ಯ ವಿಳಾಸ ದಾಖಲೆಗಳನ್ನು ಒಂದು ಆದ್ಯತೆಯ ಸರ್ವರ್‌ನಿಂದ ಬದಲಿಸುವುದು ಮೂರನೇ ಆಯ್ಕೆಯಲ್ಲ. ಅದು ಸಾಮಾನ್ಯ ಪತ್ತೆಹಚ್ಚುವಿಕೆ ಗುಂಪನ್ನು ನಿರೀಕ್ಷಿಸುವ ಪ್ರತಿ ಗ್ರಾಹಕನನ್ನೂ ಮುರಿಯುತ್ತದೆ, ಮತ್ತು ಡೈರೆಕ್ಟರಿ-ಅರಿವಿರುವ ಕ್ಲೈಂಟ್ ಸೈಟ್ ಆಯ್ಕೆ ಮಾಡುವ ರೀತಿಯನ್ನು ಇನ್ನೂ ನಿಯಂತ್ರಿಸುವುದಿಲ್ಲ.

ಮೂರು ಷರತ್ತುಗಳ ಮೇಲೆ ಆಯ್ಕೆ ಮಾಡಿ

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

ಡೈರೆಕ್ಟರಿ-ಅರಿವಿರುವ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಜೊತೆಗೆ ಮೂಲವನ್ನು ಉಳಿಸುವ ಮಾರ್ಗನಿರ್ದೇಶನ ಜೊತೆಗೆ ಬದಲಾಗುವ ಪೂಲ್: ಸಬ್‌ನೆಟ್ ಮ್ಯಾಪ್ ಮಾಡಿ. ಪತ್ತೆಹಚ್ಚಲಾಗದ ಅಪ್ಲಿಕೇಶನ್, ಅಥವಾ ಒಂದು ವಿಳಾಸವನ್ನು ಒಪ್ಪುವ ಫಿಲ್ಟರ್: ಅದನ್ನು ಪಿನ್ ಮಾಡಿ, ಮತ್ತು ಏಕೆ ಎಂದು ಬರೆಯಿರಿ. ಉಳಿದೆಲ್ಲವೂ ಇನ್ನೊಂದು ಓವರ್‌ರೈಡ್ ಸೇರಿಸುವುದಲ್ಲ, ಟೋಪಾಲಜಿ ಸರಿಪಡಿಸುವ ಪ್ರಕರಣ.

VPN ಕ್ಲೈಂಟ್‌ನಿಂದ ಪರಿಶೀಲಿಸಿ ಮತ್ತು ಒಪ್ಪಂದಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಇರಿಸಿ

ಸೈಟ್‌ನಲ್ಲಿ ಈಗಾಗಲೇ ಇರುವ LAN ವರ್ಕ್‌ಸ್ಟೇಷನ್‌ನಿಂದ ಅಲ್ಲ, ನಿಜವಾದ ದೂರಸ್ಥ ಮಾರ್ಗದಿಂದ ಪರೀಕ್ಷಿಸಿ. ಕ್ಲೈಂಟ್‌ನ ಸ್ವಂತ ದೃಷ್ಟಿಕೋನವೊಂದೇ ಮುಖ್ಯ:

nltest /dsgetsite
nltest /dsgetdc:corp.example.com /force
echo %LOGONSERVER%

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

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