ಟನೆಲ್ ಆನ್ ಆಗಿದೆ, ಹಾಗಾದರೆ ಖಾಸಗಿ ಹೆಸರು ಏಕೆ ಇನ್ನೂ ವಿಫಲವಾಗುತ್ತದೆ?
ಕೆಲಸ ಮಾಡುವ ಟನೆಲ್ ಎಂದರೆ ಕ್ಲೈಂಟ್ ಸರಿಯಾದ ರಿಸಾಲ್ವರ್ ಅನ್ನು ಕೇಳಿದೆ ಎಂದಲ್ಲ. ಯಾರು ಉತ್ತರಿಸಿದರು ಎಂದು ಪರಿಶೀಲಿಸಿ, ನಂತರ ನಿಜವಾಗಿ ಅಗತ್ಯವಿರುವ ವಲಯವನ್ನು ಮಾತ್ರ ಮುಂದಕ್ಕೆ ಕಳುಹಿಸಿ.
ಸಂಪರ್ಕದ ಎಲ್ಲವೂ ಸರಿಯಾಗಿ ಕಾಣುತ್ತದೆ: ಟನೆಲ್ ಆನ್ ಆಗಿದೆ ಮತ್ತು ಕನ್ಸೋಲ್ ಖಾಸಗಿ ಎಂಡ್‌ಪಾಯಿಂಟ್ ತೋರಿಸುತ್ತದೆ, ಆದರೂ ಪ್ರತಿ ವಿನಂತಿಯೂ ಹೆಸರಿನ ವಿಭೇದನದಲ್ಲಿ ವಿಫಲವಾಗುತ್ತದೆ. ಸಹಜ ಹೆಜ್ಜೆ ಟನೆಲ್‌ಗೆ ದೋಷ ಹೇರುವುದು, ಅದು ಸಾಮಾನ್ಯವಾಗಿ ನಿರ್ದೋಷಿ ಎಂದು ತಿಳಿಯುತ್ತದೆ. ವಿನಂತಿಯನ್ನು ಖಾಸಗಿ ವಲಯದ ಬಗ್ಗೆ ಏನೂ ತಿಳಿಯದ ಸರ್ವರ್‌ಗೆ ಕಳುಹಿಸಲಾಗುತ್ತಿದೆ. ಯಾವುದೇ ರೂಟಿಂಗ್ ಬದಲಾವಣೆ ಆ ಉತ್ತರವನ್ನು ಬದಲಿಸುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಸಮಸ್ಯೆ ಯಾರನ್ನು ಕೇಳಲಾಗಿದೆ ಎಂಬುದು.
ವಿನಂತಿ ಯಾವ ರಿಸಾಲ್ವರ್‌ಗೆ ತಲುಪಿತು?
ಟನೆಲ್ ಅನ್ನು ನೋಡುವ ಮೊದಲೇ ಪ್ರತಿ ಲಿಂಕ್‌ಗೆ ಜೋಡಿಸಿದ ರಿಸಾಲ್ವರ್ ಅನ್ನು ಹುಡುಕಿ. Linux ರಿಸಾಲ್ವರ್ ಸ್ಥಿತಿ ಆದೇಶದ ಮೂಲಕ ಪ್ರತಿ ಲಿಂಕ್‌ನ ಸರ್ವರ್‌ಗಳನ್ನು ತೋರಿಸುತ್ತದೆ, ಮತ್ತು macOS ತನ್ನ DNS ಸಂರಚನಾ ಡಂಪ್‌ನಲ್ಲಿ ವ್ಯಾಪ್ತಿಯ ರಿಸಾಲ್ವರ್‌ಗಳನ್ನು ತೋರಿಸುತ್ತದೆ. ಉತ್ತರವು ಇನ್ನೂ ಮನೆಯ ರೌಟರ್‌ನಿಂದ ಬಂದರೆ, ಟನೆಲ್ ಲಿಂಕ್ ಎಂದಿಗೂ ಸಂಪರ್ಕಿಸಲ್ಪಟ್ಟಿಲ್ಲ.
resolvectl status
scutil --dns | head -40
dig +short internal.example.comಇಲ್ಲಿ ಎರಡು ಹಂತಗಳು ಬೆರೆಯುತ್ತವೆ: ರಿಸಾಲ್ವರ್ ವಿಳಾಸವನ್ನು ತಳ್ಳುವ ಸರ್ವರ್, ಮತ್ತು ಅದನ್ನು ಸಕ್ರಿಯ ಲಿಂಕ್‌ಗೆ ಅಳವಡಿಸುವ ಕ್ಲೈಂಟ್. ಪ್ರೊಫೈಲ್‌ನಲ್ಲಿ ಆಯ್ಕೆ ಇರಬಹುದು, ಮತ್ತು ಲಾಗ್ ಅದು ಬರುತ್ತಿರುವುದನ್ನು ತೋರಿಸಬಹುದು, ಆದರೆ ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ ಹಳೆಯ ಸರ್ವರ್ ಅನ್ನು ಬಳಸುತ್ತಲೇ ಇರುತ್ತದೆ. ಲಾಗ್ ಅನ್ನು ಲಿಂಕ್ ವರದಿ ಮಾಡುವುದರೊಂದಿಗೆ ಹೋಲಿಸಿ, ಮತ್ತು ಲಿಂಕ್ ಅನ್ನು ನಂಬಿ.
ಕ್ಲೌಡ್ ನೆಟ್‌ವರ್ಕ್ ನಿಜವಾಗಿ ಉತ್ತರಿಸುವ ವಿಳಾಸವನ್ನು ಬಳಸಿ
ಕ್ಲೌಡ್ ನೆಟ್‌ವರ್ಕ್‌ಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಶ್ರೇಣಿಯ ಮೂಲದಿಂದ ಎರಡು ಮುಂದಿರುವ ಕಾಯ್ದಿರಿಸಿದ ವಿಳಾಸದ ಮೂಲಕ ಖಾಸಗಿ ಹೆಸರುಗಳಿಗೆ ಉತ್ತರಿಸುತ್ತವೆ, ಆದ್ದರಿಂದ 10.0.0.0 ರಿಂದ ಪ್ರಾರಂಭವಾಗುವ ನೆಟ್‌ವರ್ಕ್ 10.0.0.2 ನಲ್ಲಿ ಉತ್ತರಿಸುತ್ತದೆ. ಕೆಲವು ಪೂರೈಕೆದಾರರು ಶ್ರೇಣಿ ತಿಳಿಯದೆ ಕೆಲಸ ಮಾಡುವ ಲಿಂಕ್-ಸ್ಥಳೀಯ ರಿಸಾಲ್ವರ್ ಅನ್ನೂ ಪ್ರಕಟಿಸುತ್ತಾರೆ, ಇದು ನೆಟ್‌ವರ್ಕ್ ಅನ್ನು ಬೇರೆಯವರು ನಿರ್ಮಿಸಿದಾಗ ಸಹಾಯ ಮಾಡುತ್ತದೆ. ಅಭ್ಯರ್ಥಿ ವಿಳಾಸವನ್ನು ಯಾರಿಗೂ ತಳ್ಳುವ ಮೊದಲು ನೇರವಾಗಿ ಕೇಳಿ. ರಿಸಾಲ್ವರ್ ಅಲ್ಲದ ವಿಳಾಸವು ಫೈರ್‌ವಾಲ್ ಡ್ರಾಪ್‌ನಂತೆಯೇ ಕಾಣುತ್ತದೆ, ಏಕೆಂದರೆ ವಿನಂತಿ ಎಂದಿಗೂ ಉತ್ತರವನ್ನು ಪಡೆಯುವುದಿಲ್ಲ.
ನೇರ ವಿನಂತಿ ನೆಟ್‌ವರ್ಕ್ ಒಳಗಿನಿಂದ ಉತ್ತರಿಸಿದರೆ ಆದರೆ ಟನೆಲ್ ಮೂಲಕ ಅಲ್ಲದಿದ್ದರೆ, ರಿಸಾಲ್ವರ್ ಸರಿಯಾಗಿದೆ ಮತ್ತು ಎರಡು ಬಿಂದುಗಳ ನಡುವಿನ ಮಾರ್ಗ ಸರಿಯಿಲ್ಲ. ಆ ಫಲಿತಾಂಶವು ತನಿಖೆಯನ್ನು ಕ್ಲೈಂಟ್ ಪ್ರೊಫೈಲ್‌ಗೆ ಬದಲಾಗಿ ರೂಟ್‌ಗಳು, ಮುಂದೂಡಿಕೆ ಮತ್ತು ಪ್ರವೇಶ ನಿಯಮಗಳಿಗೆ ಸರಿಸುತ್ತದೆ.
ಟನೆಲ್ ಹೆಸರಿನ ಜಾಗವನ್ನು ಸಾಗಿಸುವುದಿಲ್ಲ
ಪ್ಯಾಕೆಟ್‌ಗಳು ದಾಟುತ್ತವೆ; ಹೆಸರುಗಳು ದಾಟುವುದಿಲ್ಲ. ಪ್ರತಿ ಬದಿಗೂ ಯಾವ ಹೆಸರಿನ ಜಾಗ ಇನ್ನೊಂದಕ್ಕೆ ಸೇರಿದೆ ಎಂದು ಹೇಳಬೇಕು, ಮತ್ತು ಅದು ವಲಯವನ್ನು ಹೊಂದಿರುವವರ ಒಡೆತನದ ಪ್ರತ್ಯೇಕ ವಸ್ತು. ಸಾಮಾನ್ಯ ರೂಪವೆಂದರೆ ಒಂದು ಹೆಸರಿನ ಜಾಗಕ್ಕಾಗಿ ಮುಂದೂಡಿಕೆ, ಟನೆಲ್ ಮೂಲಕ ತಲುಪಬಹುದಾದ ರಿಸಾಲ್ವರ್‌ಗೆ ಗುರಿಯಾಗಿಸಲಾಗಿದೆ.
ವಾಸ್ತವದಲ್ಲಿ ಪ್ರತಿ ದಿಕ್ಕಿಗೂ ತನ್ನದೇ ನಿಯಮ ಬೇಕು, ಏಕೆಂದರೆ ವಲಯವನ್ನು ಹೊಂದಿರುವ ಬದಿಯೇ ವಿನಂತಿಯನ್ನು ಮುಂದಕ್ಕೆ ಕಳುಹಿಸಬೇಕು. ಎರಡೂ ದಿಕ್ಕುಗಳಿಗೂ ವಿನಂತಿಯ ಮೂಲವನ್ನು ರೂಟ್ ಮಾಡಿ ಅನುಮತಿಸಬೇಕು, ಮತ್ತು ಉತ್ತರಿಸುವ ಬದಿ ಉತ್ತರಗಳನ್ನು ಇಂಟರ್ನೆಟ್‌ಗೆ ಅಲ್ಲ, ಟನೆಲ್ ಮೂಲಕ ಹಿಂತಿರುಗಿಸಬೇಕು. ಮುಂದೂಡಿಕೆಯನ್ನು ಸಣ್ಣದಾಗಿ ಇರಿಸಿ, ಖಾಸಗಿ ಹೆಸರಿನ ಜಾಗ ಮಾತ್ರ ಲಿಂಕ್ ಅನ್ನು ಅವಲಂಬಿಸಿರುವಂತೆ. ಪ್ರತಿ ವಿನಂತಿಯನ್ನು ಅದರ ಮೂಲಕ ಕಳುಹಿಸುವುದು ಸಣ್ಣ ಅವಲಂಬನೆಯನ್ನು ಟನೆಲ್ ಬೀಳುವ ಕ್ಷಣದಲ್ಲಿ ಸಂಪೂರ್ಣ ಅಡಚಣೆಯಾಗಿ ಬದಲಿಸುತ್ತದೆ.
ಗಡಿಗಳನ್ನು ಕ್ರಮವಾಗಿ ದಾಟಿ
ಸಕ್ರಿಯ ಲಿಂಕ್‌ನಲ್ಲಿ ಅಳವಡಿಸಿದ ರಿಸಾಲ್ವರ್, ನಂತರ ಆ ರಿಸಾಲ್ವರ್‌ಗೆ ನೇರ ವಿನಂತಿ, ನಂತರ ದೂರದ ಬದಿಯಿಂದ ಅದೇ ವಿನಂತಿ, ಮತ್ತು ಕೊನೆಗೆ ಅದೇ ಹೆಸರನ್ನು ಬಳಸುವ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಪರೀಕ್ಷಿಸಿ. ಪ್ರತಿ ಹೆಜ್ಜೆ ಒಂದು ಗಡಿಯನ್ನು ಪ್ರತ್ಯೇಕಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ವಿಫಲತೆ ತನಿಖೆಯನ್ನು ಮತ್ತೆ ಪ್ರಾರಂಭಿಸುವ ಬದಲು ಎಲ್ಲಿ ನೋಡಬೇಕು ಎಂದು ಹೇಳುತ್ತದೆ. ಅಪ್ಲಿಕೇಶನ್ ವಿಫಲವಾಗುವಾಗ ಕೆಲಸ ಮಾಡುವ ಉತ್ತರವು DNS ಬದಲು ಪ್ರಮಾಣಪತ್ರದ ವಿಶ್ವಾಸ ಅಥವಾ API ನೀತಿಯನ್ನು ಸೂಚಿಸುತ್ತದೆ. ಆ ದೋಷಗಳು ನಿಜವಾದವು, ಮತ್ತು ಯಾವುದೇ ರಿಸಾಲ್ವರ್ ಬದಲಾವಣೆ ಅವುಗಳನ್ನು ಸರಿಪಡಿಸುವುದಿಲ್ಲ.
ಯಾವ ಹೆಜ್ಜೆ ವಿಫಲವಾಯಿತು ಎಂದು ಬರೆಯಿರಿ. ಆ ಒಂದೇ ಸಾಲು ಮುಂದಿನ ವ್ಯಕ್ತಿಗೆ ಅಗತ್ಯವಾದುದು, ಮತ್ತು ಅದನ್ನು ದಾಖಲಿಸಲು ಹತ್ತು ಸೆಕೆಂಡುಗಳು ಸಾಕು.
ಮುಂದಿನ ವ್ಯಕ್ತಿ ಕಂಡುಕೊಳ್ಳಬಹುದಾದ ಸ್ಥಳದಲ್ಲಿ ಸರಪಳಿಯನ್ನು ಇರಿಸಿ
ತಳ್ಳಲಾದ ರಿಸಾಲ್ವರ್, ಮುಂದೂಡಿಕೆ ನಿಯಮ, ಅನುಮತಿಸಿದ ವಿನಂತಿ ಮೂಲ ಮತ್ತು ಉತ್ತರಿಸುವ ಎಂಡ್‌ಪಾಯಿಂಟ್ ಅನ್ನು ಒಂದೇ ಸ್ಥಳದಲ್ಲಿ ದಾಖಲಿಸಿ. ಖಾಸಗಿ ಹೆಸರು ಮತ್ತೆ ವಿಫಲವಾದಾಗ, ದಾಖಲೆ ಟನೆಲ್ ಸರಿದಿದೆಯೇ, ರಿಸಾಲ್ವರ್ ವಿಳಾಸ ಬದಲಾಗಿದೆಯೇ ಅಥವಾ ನಿಯಮ ಸಂಕುಚಿತಗೊಂಡಿದೆಯೇ ಎಂದು ತೋರಿಸುತ್ತದೆ. ಅದಿಲ್ಲದೆ ಪ್ರತಿ ಘಟನೆಯೂ ಶೂನ್ಯದಿಂದ ಪ್ರಾರಂಭವಾಗಿ ಅದೇ ಮೂರು ಊಹೆಗಳೊಂದಿಗೆ ಕೊನೆಗೊಳ್ಳುತ್ತದೆ.
ದಾಖಲೆಯನ್ನು ನಿಖರವಾಗಿ ಉಳಿಯಲು ಸಾಕಷ್ಟು ಚಿಕ್ಕದಾಗಿ ಇರಿಸಿ: ನಾಲ್ಕು ಸಾಲು, ಒಂದು ದಿನಾಂಕ, ಮತ್ತು ಪ್ರತಿ ಭಾಗದ ಮಾಲೀಕರ ಹೆಸರು. ಹಳೆಯ ದಾಖಲೆ ಇಲ್ಲದಿರುವುದಕ್ಕಿಂತ ಕೆಟ್ಟದು, ಏಕೆಂದರೆ ಅದು ತಪ್ಪಾಗಿದ್ದರೂ ಅಧಿಕೃತವಾಗಿ ಕಾಣುತ್ತದೆ.