ಸಾರ್ವಜನಿಕ DNS ಕೆಲಸ ಮಾಡಿದರೂ Active Directory ಸಿಗುತ್ತದೆ ಎಂದು ಅರ್ಥವಲ್ಲ
ಬ್ರೌಸರ್ನಲ್ಲಿ ಪುಟ ಲೋಡ್ ಆಗುವುದು ಒಂದೇ ಲುಕಪ್ ಅನ್ನು ಮಾತ್ರ ಸಾಬೀತುಪಡಿಸುತ್ತದೆ. ಡೊಮೇನ್ಗೆ ಸೈನ್-ಇನ್ ಆಗಲು SRV ಲೊಕೇಟರ್ ದಾಖಲೆಗಳು, ನಿಯಂತ್ರಕಗಳ ವಿಳಾಸಗಳು ಮತ್ತು ಒಂದು ಮಾರ್ಗ ಬೇಕು, ಎಲ್ಲವೂ VPN ಮೂಲಕ ಪರಿಹರಿಸಬೇಕು.
VPN ಸಂಪರ್ಕಗೊಳ್ಳುತ್ತದೆ, ಬ್ರೌಸರ್ ಸಾರ್ವಜನಿಕ ಸೈಟ್ ತೆರೆಯುತ್ತದೆ, ಮತ್ತು ಲ್ಯಾಪ್ಟಾಪ್ ಇನ್ನೂ ಡೊಮೇನ್ಗೆ ಸೈನ್-ಇನ್ ಆಗಲು ಸಾಧ್ಯವಿಲ್ಲ. ಸಾಮಾನ್ಯ ತೀರ್ಮಾನ ಎಂದರೆ ಹೆಸರುಗಳು ಪರಿಹರಿಸುವುದರಿಂದ DNS ಸರಿಯಾಗಿದೆ. ಅದು ಸರಿಯಿಲ್ಲ, ಮತ್ತು ಕಾರಣ ಎಂದರೆ ಬ್ರೌಸರ್ ಪರೀಕ್ಷೆ ಡೊಮೇನ್ಗೆ ಸೇರಿದ ಕ್ಲೈಂಟ್ಗೆ ಬೇಕಾದ ಸರಪಳಿಯಿಂದ ಒಂದೇ ಲುಕಪ್ ಅನ್ನು ಪರೀಕ್ಷಿಸುತ್ತದೆ. ಡೊಮೇನ್ ಶೋಧ ಮೊದಲು ಸೇವಾ ದಾಖಲೆಗಳನ್ನು ಕೇಳುತ್ತದೆ, ನಂತರ ಆ ದಾಖಲೆಗಳು ಹೆಸರಿಸುವ ನಿಯಂತ್ರಕಗಳ ವಿಳಾಸಗಳನ್ನು, ನಂತರ ಆ ನಿಯಂತ್ರಕಗಳು ಕೇಳುವ ಪೋರ್ಟ್ಗಳಿಗೆ ಮಾರ್ಗವನ್ನು ಕೇಳುತ್ತದೆ. ಸಾರ್ವಜನಿಕ ಉತ್ತರ ಈ ಯಾವ ಹಂತವನ್ನೂ ಪೂರೈಸುವುದಿಲ್ಲ.
ಪುರಾಣ: ಹೆಸರುಗಳು ಪರಿಹರಿಸುತ್ತವೆ, ಆದ್ದರಿಂದ DNS ಮುಗಿದಿದೆ
ಸಾರ್ವಜನಿಕ ಸೈಟ್ ಪರಿಹರಿಸುವುದು ಯಾವುದೋ ರಿಸಾಲ್ವರ್ ಸಾರ್ವಜನಿಕ ವಲಯದಲ್ಲಿನ ಹೆಸರಿಗೆ ಒಂದು A ಅಥವಾ AAAA ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸಿದೆ ಎಂದು ಮಾತ್ರ ಹೇಳುತ್ತದೆ. Active Directory ಅದೇ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಬೇರೆ ಪ್ರಶ್ನೆಗೆ ಬಳಸುತ್ತದೆ: ಡೊಮೇನ್ನ ಸೇವೆಗಳು ಎಲ್ಲಿವೆ, ಮತ್ತು ಈ ಕ್ಲೈಂಟ್ ಯಾವ ನಿಯಂತ್ರಕವನ್ನು ಬಳಸಬೇಕು. ಪ್ರಶ್ನೆಯನ್ನು ಡೊಮೇನ್ ಹೆಸರಿನ ವಲಯದ ಅಡಿಯಲ್ಲಿ SRV ದಾಖಲೆಗಳಾಗಿ ವ್ಯಕ್ತಪಡಿಸಲಾಗುತ್ತದೆ, ಮತ್ತು ಪುನರಾವರ್ತಿತ ಸಾರ್ವಜನಿಕ ರಿಸಾಲ್ವರ್ಗೆ ಅವನ್ನು ಇಟ್ಟುಕೊಳ್ಳಲು ಯಾವುದೇ ಕಾರಣವಿಲ್ಲ.
ದಾಖಲೆ ಇಲ್ಲದಿದ್ದಾಗ ರಿಸಾಲ್ವರ್ ಋಣಾತ್ಮಕ ಉತ್ತರ ನೀಡುತ್ತದೆ, ಅದು ಅಡಚಣೆ ಅಲ್ಲ, ಮಾನ್ಯ DNS ಉತ್ತರ. ನಂತರ ಕ್ಲೈಂಟ್ ನಿಯಂತ್ರಕದ ಕ್ಯಾಶ್ ಮಾಹಿತಿ ಇದ್ದರೆ ಅದಕ್ಕೆ ಹಿಂತಿರುಗುತ್ತದೆ, ಮತ್ತು ಅದೇ ಕಾರಣಕ್ಕೆ ಡೆಸ್ಕ್ಟಾಪ್ ಗಂಟೆಗಟ್ಟಲೆ ಸರಿಯಾಗಿ ಕಾಣಿಸಬಹುದು ಮತ್ತು ರೀಬೂಟ್ ಅಥವಾ ಪಾಸ್ವರ್ಡ್ ಬದಲಾವಣೆಯ ನಂತರ ವಿಫಲವಾಗಬಹುದು.
ಡೊಮೇನ್ ಕ್ಲೈಂಟ್ ನಿಜವಾಗಿ ಏನನ್ನು ಕೇಳುತ್ತದೆ, ಕ್ರಮದಲ್ಲಿ
corp.example ನಂತಹ ಡೊಮೇನ್ಗೆ ಸಾಮಾನ್ಯ ಲೊಕೇಟರ್ ಪ್ರಶ್ನೆ _ldap._tcp.dc._msdcs.corp.example. SRV ಉತ್ತರಗಳು ಅಭ್ಯರ್ಥಿ ನಿಯಂತ್ರಕಗಳನ್ನು ಮತ್ತು ಅವುಗಳ ಪೋರ್ಟ್ಗಳನ್ನು ಹೆಸರಿಸುತ್ತವೆ, ನಂತರ ಸಂಪರ್ಕ ತೆರೆಯುವ ಮೊದಲು ಕ್ಲೈಂಟ್ಗೆ ಆ ಹೋಸ್ಟ್ ಹೆಸರುಗಳಿಗೆ ವಿಳಾಸ ದಾಖಲೆಗಳು ಬೇಕು. ಸೈಟ್-ಅರಿವಿನ ಶೋಧ ಸೈಟ್ ಉಪಡೊಮೇನ್ ಅಡಿಯಲ್ಲಿ ಪ್ರಶ್ನೆಗಳನ್ನು ಸೇರಿಸುತ್ತದೆ, ಮತ್ತು ಉತ್ತರಗಳು ಯಾವ ನಿಯಂತ್ರಕಗಳು ಆದ್ಯತೆಯವು ಎಂದು ನಿರ್ಧರಿಸುತ್ತವೆ, ಯಾವುದು ಕಡ್ಡಾಯ ಎಂದಲ್ಲ.
nltest /dsgetdc:corp.example
Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.corp.exampleಈ ಕ್ರಮದಲ್ಲಿ ಸರಪಳಿಯನ್ನು ಅನುಸರಿಸಿ, ಸಮಸ್ಯೆ ಉಂಟಾಗುವ ನೆಟ್ವರ್ಕ್ನಿಂದ. ತಲುಪಲಾಗದ ವಿಳಾಸಕ್ಕೆ ಪರಿಹರಿಸುವ ಹೋಸ್ಟ್ ಹೆಸರು ಮಾರ್ಗನಿರ್ದೇಶನ ವೈಫಲ್ಯ, DNS ವೈಫಲ್ಯವಲ್ಲ. ಲೊಕೇಟರ್ ದಾಖಲೆಗಳು ಇಲ್ಲದ ತಲುಪಬಹುದಾದ ನಿಯಂತ್ರಕ DNS ವೈಫಲ್ಯ, ಮಾರ್ಗನಿರ್ದೇಶನ ವೈಫಲ್ಯವಲ್ಲ. ಎರಡೂ ಸಮಾನ ಬಳಕೆದಾರ ದೂರುಗಳನ್ನು ಮತ್ತು ಸಂಪೂರ್ಣ ಭಿನ್ನ ರಿಪೇರಿಗಳನ್ನು ಉಂಟುಮಾಡುತ್ತವೆ.
ಸಾರ್ವಜನಿಕ ರಿಸಾಲ್ವರ್ ಉತ್ತರಿಸಿದರೂ ಸೈನ್-ಇನ್ ಏಕೆ ಮುರಿಯುತ್ತದೆ
ಅಡಾಪ್ಟರ್ ಕ್ಲೈಂಟ್ಗೆ ಸಾರ್ವಜನಿಕ ರಿಸಾಲ್ವರ್ ನೀಡಿದರೆ, ಸಾರ್ವಜನಿಕ ಹೆಸರುಗಳು ಕೆಲಸ ಮಾಡುತ್ತವೆ ಮತ್ತು ಆಂತರಿಕ ಹೆಸರಿನ ಜಾಗ ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ. ಎರಡನೇ ಸಾರ್ವಜನಿಕ ರಿಸಾಲ್ವರ್ ಸೇರಿಸಿದರೂ ಪ್ರಯೋಜನವಿಲ್ಲ, ಏಕೆಂದರೆ ಎರಡೂ ವಲಯವನ್ನು ಹೊಂದಿಲ್ಲ. “ಮೊದಲು ಆಂತರಿಕ, ನಂತರ ಸಾರ್ವಜನಿಕ” ಎಂಬ ಸಾಮಾನ್ಯ ಪಟ್ಟಿಯೂ ಪ್ರತಿ ಡೊಮೇನ್ನ ನಿಯಮದಂತೆ ವರ್ತಿಸುವುದಿಲ್ಲ: ಮೊದಲ ಸರ್ವರ್ನ ಋಣಾತ್ಮಕ ಉತ್ತರ ಕಾನೂನುಬದ್ಧ ಉತ್ತರ, ಮತ್ತು ಉತ್ತರ ಖಾಲಿ ಇತ್ತು ಎಂಬ ಕಾರಣಕ್ಕೆ ಮಾತ್ರ ಕ್ಲೈಂಟ್ ಎರಡನೇ ಸರ್ವರ್ ಅನ್ನು ಮತ್ತೆ ಪ್ರಯತ್ನಿಸುವುದಿಲ್ಲ.
ಎರಡೂ ಆಂತರಿಕ ರಿಸಾಲ್ವರ್ಗಳು, ನೀವು ಎರಡನ್ನು ನಡೆಸುತ್ತಿದ್ದರೆ, AD ಹೆಸರಿನ ಜಾಗವನ್ನು ಹೊಂದಿರಬೇಕು ಮತ್ತು ಕ್ಲೈಂಟ್ನ ಪ್ರಸ್ತುತ ನೆಟ್ವರ್ಕ್ನಿಂದ ತಲುಪಬಹುದಾಗಿರಬೇಕು. ಸ್ಪ್ಲಿಟ್-ಟನಲ್ ವಿನ್ಯಾಸಗಳು ಮುರಿಯುವುದು ಇದನ್ನೇ: VPN ಟನಲ್ ಉಪಜಾಲವನ್ನು ಸಾಗಿಸಬಹುದು, ಆದರೆ ಆಂತರಿಕ ರಿಸಾಲ್ವರ್ ಟನಲ್ ಮಾರ್ಗನಿರ್ದೇಶಿಸದ ಪ್ರಿಫಿಕ್ಸ್ನಲ್ಲಿದ್ದರೆ, ಪ್ರಶ್ನೆ ಉತ್ತರಿಸಲಾಗದ ರಿಸಾಲ್ವರ್ಗೆ ಹೋಗುತ್ತದೆ.
Windows ನಿರ್ದಿಷ್ಟ ಹೆಸರಿನ ಜಾಗಗಳನ್ನು ನಿರ್ದಿಷ್ಟ ಸರ್ವರ್ಗಳಿಗೆ ನಿರ್ದೇಶಿಸಬಲ್ಲ ಹೆಸರು ಪರಿಹಾರ ನೀತಿಯನ್ನೂ ಅನ್ವಯಿಸುತ್ತದೆ, ಮತ್ತು ಅಡಾಪ್ಟರ್ ತೋರಿಸುವ DNS ವಿಳಾಸಗಳು ಇಡೀ ಕಥೆಯಲ್ಲ. ಆ ನೀತಿಯನ್ನು ಬದಲಿಸದೆ ಅಡಾಪ್ಟರ್ ಪಟ್ಟಿ ಬದಲಿಸುವುದು ಪರಿಣಾಮಕಾರಿ ಸಂರಚನೆಯನ್ನು ಮುಟ್ಟದೆ ಬಿಡಬಹುದು, ಮತ್ತು ಅದಕ್ಕಾಗಿಯೇ ಅನ್ವಯಿಸಿದಂತೆ ಕಾಣುವ ಸುಧಾರಣೆ ಯಾವುದೇ ಪರಿಣಾಮ ಬೀರುವುದಿಲ್ಲ.
ಟನಲ್ನ DNS ಮತ್ತು ಅದರ ಮಾರ್ಗಗಳನ್ನು ಸಮನ್ವಯದಲ್ಲಿಡಿ
ರಿಸಾಲ್ವರ್ ಕಳುಹಿಸಿ ಅದನ್ನು ಒಳಗೊಂಡ ಪ್ರಿಫಿಕ್ಸ್ ಕಳುಹಿಸದ VPN ಪ್ರೊಫೈಲ್ ಕ್ಲೈಂಟ್ ತಲುಪಲಾಗದ ರಿಸಾಲ್ವರ್ ಸೃಷ್ಟಿಸುತ್ತದೆ; ಪ್ರಿಫಿಕ್ಸ್ ಕಳುಹಿಸಿ ರಿಸಾಲ್ವರ್ ಕಳುಹಿಸದ ಪ್ರೊಫೈಲ್ ಕ್ಲೈಂಟ್ ಅನ್ನು ಸ್ಥಳೀಯ ರಿಸಾಲ್ವರ್ ಕೇಳಲು ಬಿಡುತ್ತದೆ. ಜೋಡಿಯನ್ನು ಒಂದೇ ಸಂರಚನಾ ಅಂಶವೆಂದು ಪರಿಗಣಿಸಿ ಪ್ರತಿ ಪ್ರೊಫೈಲ್ ಬದಲಾವಣೆಯ ನಂತರ ಎರಡನ್ನೂ ಪರಿಶೀಲಿಸಿ, ಏಕೆಂದರೆ ಮರುಜೋಡಣೆಗೊಂಡ ಪುಶ್ ಅಥವಾ ಹೊಸ ಸ್ಪ್ಲಿಟ್-ಟನಲ್ ನೀತಿ ಅವನ್ನು ಪ್ರತ್ಯೇಕಿಸಬಹುದು.
ಕ್ಲೈಂಟ್ ಪುಶ್ ಮಾಡಿದ ಸೆಟ್ಟಿಂಗ್ನೊಂದಿಗೆ ಏನು ಮಾಡುತ್ತದೆ ಎಂಬುದನ್ನೂ ಪರಿಶೀಲಿಸಿ. ಕೆಲವು ಕ್ಲೈಂಟ್ಗಳು DNS ಸರ್ವರ್ ಅನ್ನು ಟನಲ್ ಇಂಟರ್ಫೇಸ್ಗೆ ಮಾತ್ರ ಅನ್ವಯಿಸಿ ಭೌತಿಕ ಅಡಾಪ್ಟರ್ನ ರಿಸಾಲ್ವರ್ ಅನ್ನು ಅಲ್ಲಿಯೇ ಬಿಡುತ್ತವೆ, ಆದ್ದರಿಂದ ಯಾವುದು ಗೆಲ್ಲುತ್ತದೆ ಎಂಬುದು ಇಂಟರ್ಫೇಸ್ ಮೆಟ್ರಿಕ್ ಮತ್ತು ಕೇಳುವ ಹೆಸರನ್ನು ಅವಲಂಬಿಸಿದೆ. ಭೌತಿಕ ಅಡಾಪ್ಟರ್ ನಿಷ್ಕ್ರಿಯವಾಗಿದ್ದಾಗ ಮಾತ್ರ ಆಂತರಿಕ ಉತ್ತರ ಬಂದರೆ, ಸರಿಪಡಿಸಬೇಕಾದ ಕಾರ್ಯವಿಧಾನ ಅದೇ, ಡೊಮೇನ್ ದಾಖಲೆಗಳಲ್ಲ.
ಶೋಧ ಕರೆ ಮತ್ತು ಒಂದು ಜೀವಂತ ಕಾರ್ಯಾಚರಣೆಯಿಂದ ಸ್ವೀಕರಿಸಿ
ಉಪಯುಕ್ತ ಸ್ವೀಕೃತಿ ಪರೀಕ್ಷೆ ಲೊಕೇಟರ್ ಪ್ರಶ್ನೆ ನಡೆಸಿ ನಂತರ ಒಂದು ನಿಜವಾದ ದೃಢೀಕೃತ ಕಾರ್ಯಾಚರಣೆ ಮಾಡುತ್ತದೆ, ಉದಾಹರಣೆಗೆ ಡೈರೆಕ್ಟರಿ-ಬೆಂಬಲಿತ ಹಂಚಿಕೆ ತೆರೆಯುವುದು ಅಥವಾ ಟಿಕೆಟ್ ಕೇಳುವುದು. VPN ಬದಲಾವಣೆಯ ಮೊದಲು ಮತ್ತು ನಂತರ ಮತ್ತೆ, ಅದೇ ಯಂತ್ರದಲ್ಲಿ, ಮಧ್ಯೆ ರೀಬೂಟ್ ಇಲ್ಲದೆ ಮಾಡಿ. ಕ್ಯಾಶ್ ಆದ ರುಜುವಾತುಗಳು ಮತ್ತು ಈಗಾಗಲೇ ತೆರೆದ ಸೆಷನ್ಗಳು ಮುರಿದ ಮಾರ್ಗವನ್ನು ಸಂತೋಷದಿಂದ ಆರೋಗ್ಯಕರವಾಗಿ ತೋರಿಸುತ್ತವೆ, ಆದ್ದರಿಂದ ಯಶಸ್ವಿ ಡೆಸ್ಕ್ಟಾಪ್ ಲಾಗಿನ್ ಪರೀಕ್ಷೆಯಲ್ಲ.
Microsoft ನ DNS ಕ್ಲೈಂಟ್ಗಾಗಿ ಶಿಫಾರಸುಗಳು ಆಂತರಿಕ ಹೆಸರಿನ ಜಾಗವನ್ನು ಪರಿಹರಿಸುವುದಕ್ಕೂ ಸಾರ್ವಜನಿಕ ಪ್ರಶ್ನೆಗಳನ್ನು ಮೇಲಕ್ಕೆ ಮುಂದುವರಿಸುವುದಕ್ಕೂ ನಡುವೆ ಅದೇ ಗೆರೆ ಎಳೆಯುತ್ತವೆ, ಮತ್ತು VPN ಪರಿಚಯಿಸಿದಾಗ ಕಾಪಾಡಬೇಕಾದ ಜೋಡಣೆ ಅದೇ.
ವೈಫಲ್ಯ ಕೇವಲ ನಿಧಾನವಾಗಿದ್ದರೆ, ವಿಫಲವಲ್ಲದಿದ್ದರೆ, ವಿಳಂಬವನ್ನು ರೋಗನಿರ್ಣಯದಿಂದ ಪ್ರತ್ಯೇಕವಾಗಿಡಿ. ಶೋಧದ ಸಮಯದಲ್ಲಿ ಸಮಯ ಮೀರುವಿಕೆ ತಲುಪಲಾಗದ ನಿಯಂತ್ರಕ, ತಡೆಹಿಡಿದ ಪೋರ್ಟ್ ಅಥವಾ ತಡವಾಗಿ ಉತ್ತರಿಸುವ ರಿಸಾಲ್ವರ್ನಿಂದ ಬರಬಹುದು, ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಯಾವುದೂ ಕೇವಲ ಕಾಯುವಿಕೆಯಿಂದ ಸಾಬೀತಾಗುವುದಿಲ್ಲ. ರಿಸಾಲ್ವರ್ ಸೆಟ್ಟಿಂಗ್ ಬದಲಿಸುವ ಮೊದಲು ನಿಜವಾದ ಪ್ರಶ್ನೆ, ಅದರ ಉತ್ತರ ಮತ್ತು ಸಂಪರ್ಕ ಪ್ರಯತ್ನವನ್ನು ದಾಖಲಿಸಿ.