ವಿಭಜಿತ DNS ಮತ್ತು VPN: ಡೊಮೇನ್ ನಿಯಮಗಳು IP ರೂಟ್‌ಗಳಲ್ಲ
ವಿಭಜಿತ DNS ಹೆಸರಿನ ಆಧಾರದ ಮೇಲೆ ರಿಸಾಲ್ವರ್ ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಉತ್ತರಕ್ಕೆ ಇನ್ನೂ ಮಾರ್ಗ ಬೇಕು. ಡೊಮೇನ್ ನಿಯಮ ಮತ್ತು ಮಾರ್ಗವನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ, ನೀವು ನಿಜವಾಗಿ ಚಲಾಯಿಸುವ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ನಲ್ಲಿ ಪರೀಕ್ಷಿಸಿ.
ನಿಮ್ಮ ಲ್ಯಾಪ್‌ಟಾಪ್ intranet.corp ಅನ್ನು ಟನೆಲ್ ಮೂಲಕ ಪರಿಹರಿಸುತ್ತದೆ, ಆದರೆ gitlab.com ಸೇವಾ ಪೂರೈಕೆದಾರರ ರಿಸಾಲ್ವರ್ಗೆ ಹೋಗುತ್ತಲೇ ಇರುತ್ತದೆ, ಮತ್ತು ಇದು ವಿನ್ಯಾಸದಂತೆ ಕೆಲಸ ಮಾಡುವ ವ್ಯವಸ್ಥೆ. ಎರಡು ಪ್ರತ್ಯೇಕ ನಿರ್ಧಾರಗಳು ಇದನ್ನು ಸೃಷ್ಟಿಸಿದವು: ಹೆಸರು ಹೊಂದಾಣಿಕೆ ನಿಯಮ ರಿಸಾಲ್ವರ್ ಆಯ್ಕೆ ಮಾಡಿತು, ಮತ್ತು ರೂಟ್ ಉತ್ತರವನ್ನು ಮರಳಿ ತಂದಿತು. ಯಾವುದನ್ನಾದರೂ ಮುರಿದರೆ ಬ್ರೌಸರ್ ಹೊರಗಿನಿಂದ ಒಂದೇ ರೀತಿ ಕಾಣುವ ವೈಫಲ್ಯ ತೋರಿಸುತ್ತದೆ. ವಿಭಜಿತ DNS ನ ಬಹುಪಾಲು ವರದಿಗಳು ಎರಡನೇ ವೈಫಲ್ಯವನ್ನು ವಿವರಿಸುತ್ತಾ ಮೊದಲನೆಯ ಬಗ್ಗೆ ಸಾಕ್ಷ್ಯ ಉಲ್ಲೇಖಿಸುತ್ತವೆ.
ಎರಡು ಅರ್ಧಗಳು ಬೇರೆ ಬೇರೆ ಸ್ಥಳಗಳಲ್ಲಿ ಇರುತ್ತವೆ ಮತ್ತು ಸಾಮಾನ್ಯವಾಗಿ ಬೇರೆ ಜನರು ಅವುಗಳನ್ನು ಸಂಪಾದಿಸುತ್ತಾರೆ. ಒಂದು VPN ಪ್ರೊಫೈಲ್‌ಗೆ ಜೋಡಿಸಿದ DNS ನೀತಿ, ಇನ್ನೊಂದು ಟನೆಲ್ ಸ್ಥಾಪಿಸುವ ಅಥವಾ ತಡೆಹಿಡಿಯುವ ರೂಟ್. ಯಾವ ಅರ್ಧ ನಿಜವಾಗಿ ಚಲಿಸಿತು ಎಂದು ಯಾರೂ ನಿರ್ಧರಿಸದಿದ್ದಾಗ ಡೀಬಗ್ಗಿಂಗ್ ನಿಲ್ಲುತ್ತದೆ.
ಒಂದೇ ವಿನಂತಿಯಲ್ಲಿ ಅಡಗಿರುವ ಎರಡು ನಿರ್ಧಾರಗಳು
ಹೆಸರಿನ ಅರ್ಧ ನೀತಿ ವಸ್ತುವೇ ಹೊರತು ರೂಟ್ ಅಲ್ಲ. Windows ನಲ್ಲಿ ಇದು VPN ಪ್ರೊಫೈಲ್‌ನಲ್ಲಿ ಹೆಸರು ಪರಿಹಾರ ನೀತಿ; Apple ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗಳಲ್ಲಿ DNS ಸೆಟ್ಟಿಂಗ್ಸ್ ವಸ್ತುವಿನ ಮೇಲೆ ಹೊಂದಿಕೆಯಾಗುವ ಡೊಮೇನ್‌ಗಳ ಗುಂಪು; Linux ನಲ್ಲಿ ರೂಟಿಂಗ್ ಡೊಮೇನ್, ವಿಭಜಿತ ರಿಸಾಲ್ವರ್ ಸಾಲು ಅಥವಾ ಹೆಸರು ಸೇವಾ ಸ್ವಿಚ್‌ನ ಕ್ರಮ. ಮಾರ್ಗದ ಅರ್ಧ ಸಾಮಾನ್ಯ ರೂಟಿಂಗ್, ಟನೆಲ್ ಅಥವಾ ಕೈಯಿಂದ ಸ್ಥಾಪಿಸಲ್ಪಟ್ಟದ್ದು, ಮತ್ತು ಹೋಸ್ಟ್‌ನಾಮ್ ಎಂದರೇನು ಎಂದು ಅದಕ್ಕೆ ತಿಳಿದಿಲ್ಲ. ಪ್ರತ್ಯಯವನ್ನು ಅನುಮತಿಸುವ ಪ್ರೊಫೈಲ್ ಯಾರು ಉತ್ತರಿಸುತ್ತಾರೆ ಎಂಬುದನ್ನು ಮಾತ್ರ ನಿರ್ಧರಿಸುತ್ತದೆ; ಅದು ಉತ್ತರವನ್ನು ಎಂದಿಗೂ ತಲುಪಬಹುದಾದದ್ದಾಗಿಸುವುದಿಲ್ಲ.
ತ್ವರಿತ ಲಕ್ಷಣ ಪರೀಕ್ಷೆ ಅವುಗಳನ್ನು ಬೇರ್ಪಡಿಸುತ್ತದೆ: ಹೆಸರಿನ ಜಾಗದಲ್ಲಿ ವಿಳಾಸ ಹಾಕಿ. ವಿಳಾಸ ಕೆಲಸ ಮಾಡಿದರೆ ಮಾರ್ಗ ಸರಿಯಾಗಿದೆ ಮತ್ತು ನಿಯಮ ತಪ್ಪಾಗಿದೆ. ವಿಳಾಸವೂ ವಿಫಲವಾದರೆ ನಿಯಮ ಸರಿಯಾಗಿರಬಹುದು ಮತ್ತು ಮಾರ್ಗ ಕಾಣೆಯಾಗಿರಬಹುದು.
ಪ್ರತಿ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಒಂದೇ ಹೆಸರು ನಿಯಮವನ್ನು ಹೇಗೆ ವ್ಯಕ್ತಪಡಿಸುತ್ತದೆ
ಉದ್ದೇಶ ಒಂದೇ ಮತ್ತು ಕ್ಷೇತ್ರಗಳ ಹೆಸರುಗಳು ಅಲ್ಲ. ಒಂದು ಕ್ಲೈಂಟ್‌ನಿಂದ ಇನ್ನೊಂದಕ್ಕೆ ನಕಲಿಸಿದ ಉದಾಹರಣೆ ಸ್ವಚ್ಛವಾಗಿ ಪಾರ್ಸ್ ಆಗುತ್ತದೆ ಮತ್ತು ಎಂದಿಗೂ ಹೊಂದಿಕೆಯಾಗುವುದಿಲ್ಲ. ಮೂರು ರೂಪಗಳು ಹೀಗೆ ಕಾಣುತ್ತವೆ:
| Platform | Where the rule lives | What usually breaks |
|---|---|---|
| Windows | name-resolution policy on the VPN profile | precedence against the interface suffix list |
| Apple platforms | match domains on the DNS settings object | domains attached to the wrong extension |
| Linux | routing domain, split resolver, nsswitch order | the suffix written the wrong way round |
ಹೊಂದಾಣಿಕೆ ಅಥವಾ ರೂಟಿಂಗ್ ಡೊಮೇನ್ ಪ್ರತ್ಯಯ ಪರೀಕ್ಷೆ, ಆದ್ದರಿಂದ intranet.corp git.intranet.corp ಅನ್ನು ಒಳಗೊಳ್ಳುತ್ತದೆ ಮತ್ತು corp.intranet ಅನ್ನು ಒಳಗೊಳ್ಳುವುದಿಲ್ಲ, ಮತ್ತು ಅದನ್ನು ತಿರುಗಿಸುವುದು ಇಡೀ ಸೆಟಪ್‌ನಲ್ಲಿ ಅತ್ಯಂತ ಸಾಮಾನ್ಯ ತಪ್ಪು. Windows ಮ್ಯಾಪಿಂಗ್ ಅನ್ನು ಪ್ರೊಫೈಲ್‌ಗೆ ಜೋಡಿಸಿದ ಹೆಸರು ಪರಿಹಾರ ನೀತಿಯಾಗಿ ಒಯ್ಯುತ್ತದೆ, ಇಂಟರ್‌ಫೇಸ್ ಈಗಾಗಲೇ ಹೊಂದಿದ್ದ ಯಾವುದೇ ಪ್ರತ್ಯಯ ಪಟ್ಟಿಗೆ ಎದುರಾಗಿ ತನ್ನದೇ ಆದ ಆದ್ಯತಾ ಕ್ರಮದೊಂದಿಗೆ. Apple ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗಳು ಹೊಂದಿಕೆಯಾಗುವ ಡೊಮೇನ್‌ಗಳನ್ನು ನೆಟ್‌ವರ್ಕ್ ವಿಸ್ತರಣೆಯ DNS ಸೆಟ್ಟಿಂಗ್ಸ್ ವಸ್ತುವಿಗೆ ಜೋಡಿಸುತ್ತವೆ, ಮತ್ತು ಸಿಸ್ಟಮ್ ಅವುಗಳನ್ನು ಪ್ರತಿ ವ್ಯಾಪ್ತಿಯ ರಿಸಾಲ್ವರ್ಗೆ ಅನ್ವಯಿಸುತ್ತದೆ. ಈ ರೂಪಗಳಲ್ಲಿ ಯಾವುದೂ ರೂಟ್ ಅಲ್ಲ, ಮತ್ತು ಯಾವುದೂ ತಲುಪಲಾಗದ ವಿಳಾಸವನ್ನು ತಲುಪಬಹುದಾದದ್ದಾಗಿಸಲಾರದು. Windows ಹೆಸರು ಪರಿಹಾರ ನೀತಿ ಉಲ್ಲೇಖವು ಆ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ನ ಕ್ಷೇತ್ರ ಹೆಸರುಗಳು ಮತ್ತು ಆದ್ಯತಾ ನಿಯಮಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಅವು Apple ಅಥವಾ systemd ದಾಖಲೆಗಳು ಬಳಸುವ ನಿಯಮಗಳಲ್ಲ.
ಸರಿಯಾದ ಉತ್ತರಕ್ಕೂ ಮಾರ್ಗ ಬೇಕು
ರಿಸಾಲ್ವರ್‌ನ ಉತ್ತರ ಕೇವಲ ವಿಳಾಸ, ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಇನ್ನೂ ಅಲ್ಲಿಗೆ ತಲುಪಬೇಕು. ವಿಭಜಿತ ಟನೆಲ್ ವಿನ್ಯಾಸ ಸಾಮಾನ್ಯವಾಗಿ 10.20.0.0/16 ಅನ್ನು ತಳ್ಳುತ್ತದೆ ಮತ್ತು ಡೀಫಾಲ್ಟ್ ರೂಟ್ ಅನ್ನು ತಡೆಹಿಡಿಯುತ್ತದೆ, ಆದ್ದರಿಂದ ಒಳಗಿನ ಹೆಸರು ಪರಿಹಾರವಾಗಿ ನಂತರ ಸಂಪರ್ಕ ನೇತಾಡುತ್ತದೆ. ವಿರುದ್ಧ ಸಂದರ್ಭವೂ ಸಮಾನವಾಗಿ ಸಾಮಾನ್ಯ: ರೂಟ್ ಇದೆ, ಸಾರ್ವಜನಿಕ ರಿಸಾಲ್ವರ್ ಖಾಸಗಿ ಹೆಸರಿಗೆ NXDOMAIN ಉತ್ತರಿಸುತ್ತದೆ, ಮತ್ತು ವೈಫಲ್ಯ ರೂಟಿಂಗ್ ಸಮಸ್ಯೆ ಎಂದು ದಾಖಲಾಗುತ್ತದೆ. ಮೊದಲು ಮಾರ್ಗ ಪರೀಕ್ಷಿಸಿದರೆ ಎಂದಿಗೂ ಪರಿಹಾರವಾಗದ ಹೆಸರಿನ ರೂಟ್‌ಗಳನ್ನು ನೋಡುತ್ತೀರಿ.
ಯಾವ ಅರ್ಧವೂ ಆವರಿಸದ ಮೂರನೇ ದ್ವಾರವೂ ಇದೆ. ಗೇಟ್‌ವೇಯಲ್ಲಿನ ACL, ಫೈರ್‌ವಾಲ್ ನಿಯಮ ಅಥವಾ ಕ್ಲೈಂಟ್ ಬದಿಯ ನೀತಿ ಎರಡೂ ನಿರ್ಧಾರಗಳು ಸರಿಯಾದ ನಂತರವೂ ಸಂಪರ್ಕವನ್ನು ಬೀಳಿಸಬಹುದು. ಹೆಸರು ಪರಿಹಾರವಾದಾಗ, ರೂಟ್ ಇದ್ದು, ಸಂಪರ್ಕ ಇನ್ನೂ ಸಮಯ ಮೀರಿದರೆ, DNS ಪರೀಕ್ಷಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿ.
ನಿಗದಿತ ಕ್ರಮದಲ್ಲಿ ಹೆಸರುಗಳು ಮತ್ತು ಮಾರ್ಗಗಳನ್ನು ಪರೀಕ್ಷಿಸುವುದು
ಒಂದು ಕ್ರಮ ಆಯ್ಕೆ ಮಾಡಿ ಮತ್ತು ಅದನ್ನು ಪಾಲಿಸಿ, ಇಲ್ಲದಿದ್ದರೆ ಕೊನೆಯದಾಗಿ ವಿಫಲವಾದ ಹಂತವನ್ನು ಹಿಂದಟ್ಟುತ್ತೀರಿ. ದಾಖಲಿತ ಪೂರ್ಣ ಒಳಗಿನ ಹೆಸರನ್ನು ಪರಿಹರಿಸಿ, ಉತ್ತರವು ರೂಟ್ ಕೋಷ್ಟಕ ಹೊತ್ತುಕೊಳ್ಳಬಲ್ಲ ವಿಳಾಸ ಎಂದು ಖಚಿತಪಡಿಸಿ, ನಂತರ ಸಾರ್ವಜನಿಕ ಹೆಸರಿನೊಂದಿಗೆ ಪುನರಾವರ್ತಿಸಿ ಟನೆಲ್ ಎಲ್ಲವನ್ನೂ ಹಿಡಿದಿಲ್ಲ ಎಂದು ಸಾಬೀತುಪಡಿಸಿ. systemd ಹೋಸ್ಟ್‌ನಲ್ಲಿ ಪ್ರಶ್ನೆ ಮತ್ತು ರಿಸಾಲ್ವರ್‌ನ ರೂಟಿಂಗ್ ಡೊಮೇನ್ ಒಂದು ಆಜ್ಞೆಯ ಅಂತರದಲ್ಲಿವೆ:
resolvectl query intranet.corp
resolvectl domain
ip route get 10.20.5.10Windows ಕ್ಲೈಂಟ್ ಅದೇ ಎರಡು ಪ್ರಶ್ನೆಗಳನ್ನು ಬೇರೆ cmdlet ಗಳೊಂದಿಗೆ ಕೇಳುತ್ತದೆ. ಎರಡನೆಯದು ಸಿಸ್ಟಮ್ ನಿಜವಾಗಿ ಬಳಸುವ ಇಂಟರ್‌ಫೇಸ್ ಅನ್ನು ವರದಿ ಮಾಡುತ್ತದೆ:
Resolve-DnsName intranet.corp -Type A
Find-NetRoute -RemoteIPAddress 10.20.5.10ಹುಡುಕಾಟ ವಿಳಾಸವನ್ನು ಹಿಂತಿರುಗಿಸಿದರೆ ಮತ್ತು ಮಾರ್ಗ ಪರಿಶೀಲನೆ ಭೌತಿಕ ಇಂಟರ್‌ಫೇಸ್ ಅನ್ನು ಹೆಸರಿಸಿದರೆ, ಹೆಸರು ನಿಯಮ ಕೆಲಸ ಮಾಡಿತು ಮತ್ತು ರೂಟ್ ಮಾಡಲಿಲ್ಲ. ಚಿಕ್ಕ ಹೆಸರು ವಿಫಲವಾಗಿ ಪೂರ್ಣ ಹೆಸರು ಪರಿಹಾರವಾದರೆ, ಪ್ರತ್ಯಯ ಪಟ್ಟಿ ತಪ್ಪಾಗಿದೆ, ರಿಸಾಲ್ವರ್ ಅಲ್ಲ.
ಹೋಲಿಕೆ ಸಾಮಾನ್ಯವಾಗಿ ಎಲ್ಲಿ ತಪ್ಪಾಗುತ್ತದೆ
ಮೊದಲ ತಪ್ಪು ಸಂಬಂಧವಿಲ್ಲದ ಸಾರ್ವಜನಿಕ ರಿಸಾಲ್ವರ್‌ನ್ನು ಖಾಸಗಿ ಹೆಸರಿನ ಬಗ್ಗೆ ಕೇಳುವುದು ಮತ್ತು ನಿರಾಕರಣೆಯನ್ನು VPN ಬಗ್ಗೆ ಸಾಕ್ಷ್ಯವಾಗಿ ಓದುವುದು. ಎರಡನೆಯದು ಕೆಲಸ ಮಾಡುವ ಸಾರ್ವಜನಿಕ ಹುಡುಕಾಟ ಟನೆಲ್‌ನ ರಿಸಾಲ್ವರ್ ಮಾರ್ಗವನ್ನು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ ಎಂದು ಭಾವಿಸುವುದು. ಮೂರನೆಯದು ವಿಭಜಿತ ಟನೆಲಿಂಗ್ ಮತ್ತು ವಿಭಜಿತ DNS ಅನ್ನು ಒಂದೇ ವಿನ್ಯಾಸ ನಿರ್ಧಾರವೆಂದು ಪರಿಗಣಿಸುವುದು, ಆದರೆ ನಿಯೋಜನೆ ಒಂದರಲ್ಲಿ ಸರಿಯಾಗಿ ಇನ್ನೊಂದರಲ್ಲಿ ಮುರಿದಿರಬಹುದು. ಪ್ರತಿ ತಪ್ಪೂ ಆರೋಪಿಸಿದ ಭಾಗವನ್ನು ಎಂದಿಗೂ ಅಭ್ಯಾಸ ಮಾಡದ ಪರೀಕ್ಷೆಯಿಂದ ಆತ್ಮವಿಶ್ವಾಸದ ತೀರ್ಮಾನಗಳನ್ನು ನೀಡುತ್ತದೆ.
ತನ್ನದೇ ಸುರಕ್ಷಿತ DNS ಹೊಂದಿರುವ ಬ್ರೌಸರ್ ಕೂಡ ಸಿಸ್ಟಮ್ ನಿಯಮವನ್ನು ಬೈಪಾಸ್ ಮಾಡಬಹುದು, ಆದ್ದರಿಂದ ಒಂದು ಬ್ರೌಸರ್ ವಿಫಲವಾಗಿ ಇನ್ನೊಂದು ಯಶಸ್ವಿಯಾಗುವುದು ವಿರೋಧಾಭಾಸವಲ್ಲ. ಉತ್ತರಿಸಿದ ರಿಸಾಲ್ವರ್‌ನ್ನು ಹೋಲಿಸಿ, ದೂರು ನೀಡಿದ ಬ್ರೌಸರ್‌ನ್ನಲ್ಲ.
ಎರಡೂ ಅರ್ಧಗಳು ಕಾಣಿಸಿಕೊಂಡಾಗ, ಉಳಿದ ಪ್ರಶ್ನೆ ತಾಂತ್ರಿಕವಲ್ಲ, ನೀತಿಯ ಪ್ರಶ್ನೆ: ಯಾವ ಹೆಸರಿನ ಸ್ಥಳಗಳು ಸಂಸ್ಥೆಗೆ ಸೇರಿವೆ, ಪ್ರತಿ ಉತ್ತರದ ಮಾಲೀಕರು ಯಾರು, ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಯಾವುವು ಯಂತ್ರವನ್ನು ಬಿಡಬೇಕು. ಅದನ್ನು ಪ್ರೊಫೈಲ್‌ನ ಪಕ್ಕದಲ್ಲಿ ಬರೆಯಿರಿ, ಏಕೆಂದರೆ ನಿಯಮವನ್ನು ಮುಟ್ಟುವ ಮುಂದಿನ ವ್ಯಕ್ತಿಗೆ ಅದು ಬೇಕಾಗುತ್ತದೆ.