ಖಾಸಗಿ DNS ಹೆಸರೋ ಅಥವಾ ಕೇವಲ IP ಯೋ? ಹಂಚಿಕೊಳ್ಳುವ ಮೊದಲು ನಿರ್ಧರಿಸಿ

ಖಾಸಗಿ ಸೇವೆಯನ್ನು ದೂರದ ಬಳಕೆದಾರರಿಗೆ ತೆರೆದಾಗ ಎರಡು ಪ್ರಶ್ನೆಗಳು ಬೆರೆತುಹೋಗುತ್ತವೆ. ಮೊದಲನೆಯದು ಗ್ರಾಹಕರು ಯಾವ ಹೆಸರು ಬಳಸಬೇಕು; ಎರಡನೆಯದು ಸೇವೆ ಯಾವ ಮೂಲಗಳನ್ನು ಸ್ವೀಕರಿಸಬೇಕು. ಅವುಗಳಿಗೆ ಈ ಕ್ರಮದಲ್ಲಿ ಉತ್ತರಿಸಿ, ಏಕೆಂದರೆ ತಪ್ಪಾದ ಪ್ರವೇಶ ನಿಯಮದ ಹಿಂದಿನ ಸರಿಯಾದ ಹೆಸರೂ ವಿಫಲವಾಗುತ್ತದೆ, ಮತ್ತು ಪರಿಹಾರವಾಗದ ಹೆಸರಿನ ಹಿಂದಿನ ಸರಿಯಾದ ನಿಯಮ ಎಂದಿಗೂ ಪರೀಕ್ಷಿಸಲ್ಪಡುವುದಿಲ್ಲ.

ಮೊದಲ ಷರತ್ತು: ಗ್ರಾಹಕರಿಗೆ ಯಾವ resolver ಮಾರ್ಗ ಇದೆ?

ಖಾಸಗಿ ಹೆಸರು ಗ್ರಾಹಕರ resolver ಅದಕ್ಕೆ ಉತ್ತರಿಸಬಲ್ಲಾಗ ಮಾತ್ರ ಕೆಲಸ ಮಾಡುತ್ತದೆ. ಅಂದರೆ ಅಧಿಕೃತ ದೂರದ ಗ್ರಾಹಕನು ವಲಯವನ್ನು ಹೊಂದಿರುವ DNS ಸರ್ವರ್ ತಲುಪಬೇಕು, ಟನೆಲ್ ಮೂಲಕವೋ ಸಂಸ್ಥೆ ಈಗಾಗಲೇ ದೂರದ ಬಳಕೆದಾರರಿಗೆ ನಡೆಸುತ್ತಿರುವ resolver ಮೂಲಕವೋ. ಟನೆಲ್ ಒಂದು ಸಾಗಣೆ, ಕೋಶವಲ್ಲ. ಅದು ಗ್ರಾಹಕನಿಗೆ resolver ಗೆ ಮಾರ್ಗ ನೀಡುತ್ತದೆ, ಮತ್ತು ಯಾವ ವಲಯವನ್ನು ಕೇಳಬೇಕೆಂದು ಹೇಳುವುದಿಲ್ಲ.

resolvectl query files.corp.example
dig @10.20.30.10 +short files.corp.example

ಲ್ಯಾಪ್ಟಾಪ್ VPN ಗೆ ಸಂಪರ್ಕಗೊಂಡಿದೆ ಎಂಬ ಕಾರಣಕ್ಕೆ ಸಾರ್ವಜನಿಕ resolver ಖಾಸಗಿ ವಲಯವನ್ನು ಕಲಿಯುವುದಿಲ್ಲ.

ಪ್ರತ್ಯಯವೂ ಅಷ್ಟೇ ಗಮನಕ್ಕೆ ಅರ್ಹವಾಗಿದೆ. ಸಂಸ್ಥೆ ನಿಯಂತ್ರಿಸುವ ಡೊಮೇನಿನ ಉಪಡೊಮೇನ್ ಬಳಸಿ, ಮಾಲೀಕತ್ವ ಮತ್ತು ಪ್ರಮಾಣಪತ್ರ ಯೋಜನೆ ಸ್ಪಷ್ಟವಾಗಿರಲಿ. .local ತಪ್ಪಿಸಿ: ಮಲ್ಟಿಕಾಸ್ಟ್ DNS ವಿವರಣೆ ಆ ಪ್ರತ್ಯಯವನ್ನು ಲಿಂಕ್-ಲೋಕಲ್ ಪರಿಹಾರಕ್ಕೆ ಬಿಗಿಯುತ್ತದೆ, ಮತ್ತು ಮಾರ್ಗನಿರ್ದೇಶಿತ ಟನೆಲ್ ಆ ವರ್ತನೆಯನ್ನು ನಿಮಗಾಗಿ ಪುನರುತ್ಪಾದಿಸುವುದಿಲ್ಲ.

ಎರಡನೇ ಷರತ್ತು: ಸೇವೆ ಯಾವ ಮೂಲವನ್ನು ಪಡೆಯುತ್ತದೆ?

ಪ್ರವೇಶ ನಿಯಮಗಳು ವಿಳಾಸಗಳ ವಿರುದ್ಧ ಬರೆಯಲ್ಪಡುತ್ತವೆ, ಆದ್ದರಿಂದ ಉಪಯುಕ್ತ ಪ್ರಶ್ನೆ ಎಂದರೆ ಮಾರ್ಗನಿರ್ದೇಶನ ಮತ್ತು ಅನುವಾದದ ನಂತರ ಸೇವೆ ಯಾವ ವಿಳಾಸವನ್ನು ನೋಡುತ್ತದೆ. 10.20.30.40 ನಲ್ಲಿನ ಉದಾಹರಣೆ ಸೇವೆಗೆ, ಕಚೇರಿ ಗ್ರಾಹಕರು 10.20.30.0/24 ನಿಂದ ಬರುತ್ತಾರೆ ಮತ್ತು ದೂರದ ಗ್ರಾಹಕರು 10.99.0.0/24 ನಂತಹ ಪ್ರತ್ಯೇಕ ಪೂಲಿನಿಂದ ಬರುತ್ತಾರೆ.

ಗೇಟ್ ವೇ ದೂರದ ಪೂಲ್ ಅನ್ನು ಅನುವಾದಿಸಿದರೆ, ಸೇವೆ ಅನುವಾದಕನನ್ನು ನೋಡುತ್ತದೆ, ಮತ್ತು 10.99.0.0/24 ಗಾಗಿ ಬರೆದ ನಿಯಮ ಹೊಂದಿಕೆಯಾಗುವುದಿಲ್ಲ.

ಇದನ್ನು ಗ್ರಾಹಕರ ಬದಿಯಿಂದ ಅಲ್ಲ, ಸೇವೆಯ ಬದಿಯಿಂದ ಓದಿ. ಸೇವೆಯ ಹೋಸ್ಟ್ ಮೇಲಿನ ಶ್ರೋತೃ ಲಾಗ್ ಅಥವಾ ಪ್ಯಾಕೆಟ್ ಸೆರೆಹಿಡಿಯುವಿಕೆ ನಿಜವಾಗಿ ಬಂದ ಮೂಲವನ್ನು ತೋರಿಸುತ್ತದೆ; ಗ್ರಾಹಕರ ಸ್ವಂತ ವಿಳಾಸವು ಮಾರ್ಗದಲ್ಲಿ ಉಳಿದದ್ದರ ಬಗ್ಗೆ ಒಂದು ಊಹೆ ಮಾತ್ರ.

ಮೂರನೇ ಷರತ್ತು: ಹೆಸರು ಸೇವೆಗೆ ಬದ್ಧವೋ ಹೋಸ್ಟಿಗೋ?

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

ಒಂದೇ ಆಂತರಿಕ ಸೇವೆಗೆ, ನೇರ ದಾಖಲೆ ಸಾಮಾನ್ಯವಾಗಿ ಸರಿಯಾಗಿದೆ ಮತ್ತು ಯೋಚಿಸಲು ಸುಲಭ.

ಬದಲಾಯಿಸಲ್ಪಡುವ, ಮರುನಿರ್ಮಿಸಲ್ಪಡುವ ಅಥವಾ ಹಿಗ್ಗಿಸಲ್ಪಡುವ ಯಾವುದಕ್ಕೂ, ಸ್ಥಿರ ಮುಂಭಾಗ ಹೆಚ್ಚುವರಿ ಸಂರಚನೆಗೆ ಅರ್ಹವಾಗಿದೆ. ಪರೀಕ್ಷೆ ಸರಳ: ಬಳಕೆದಾರರಿಗೆ ಹೇಳದೆ ನೀವು ಬ್ಯಾಕೆಂಡ್ ಬದಲಾಯಿಸಬಹುದಾದರೆ, ಹೆಸರು ಸೇವೆಗೆ ಬದ್ಧವಾಗಿದೆ; ಬದಲಾಯಿಸಲಾಗದಿದ್ದರೆ, ಅದು ಹೋಸ್ಟಿಗೆ ಬದ್ಧವಾಗಿದೆ.

ಎರಡು ನಿರ್ಧಾರಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಪರೀಕ್ಷಿಸಿ

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

curl -sv --max-time 5 https://files.corp.example/health

ನಂತರ ನಿಷೇಧಿತ ಮೂಲವನ್ನು ಒಮ್ಮೆ ಪರೀಕ್ಷಿಸಿ, ಮತ್ತು ಫಲಿತಾಂಶವನ್ನು ದಾಖಲಿಸಿ.

ನಿಮ್ಮ ದಾಖಲೆಗಳಲ್ಲಿ ಎರಡು ದಾಖಲೆಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಇರಿಸಿ: ಹೆಸರು ಮತ್ತು ಅದರ ವಲಯ, ಸ್ವೀಕೃತ ಮೂಲಗಳು ಮತ್ತು ನಿಯಮದ ಮಾಲೀಕ. ಒಂದು ಬದಲಾದಾಗ, ಇನ್ನೊಂದು ಬದಲಾಗಬೇಕಿಲ್ಲ.

ನಿರ್ಧಾರ ಸಾಮಾನ್ಯವಾಗಿ ಎಲ್ಲಿ ತಪ್ಪುತ್ತದೆ

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

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

ಸೇವೆ ಪ್ರಾರಂಭವಾಗುವ ಮೊದಲು ಎರಡನ್ನೂ ಬರೆಯಿರಿ, ಏಕೆಂದರೆ ಮುಂದಿನ ಬದಲಾವಣೆಯನ್ನು ಯೋಚಿಸುವುದು ಸುಲಭವಾಗುತ್ತದೆ. ದಾಖಲೆ ಚಿಕ್ಕದು: ಹೆಸರು ಮತ್ತು ಅದರ ವಲಯಕ್ಕೆ ಒಂದು ಸಾಲು, ಸ್ವೀಕೃತ ಮೂಲಗಳು ಮತ್ತು ನಿಯಮದ ಮಾಲೀಕರಿಗೆ ಒಂದು ಸಾಲು.