ಭೌಗೋಳಿಕ DNS ಮತ್ತು ಎನಿಕಾಸ್ಟ್: ನೀವು ಪಡೆಯುವ VPN ಪ್ರವೇಶದ ಪರಿಶೀಲನೆ

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

ರಿಜಾಲ್ವರ್ ವಾಸ್ತವವಾಗಿ ಯಾರ ಸ್ಥಳವನ್ನು ವರದಿ ಮಾಡುತ್ತದೆ ಎಂದು ಪರಿಶೀಲಿಸಿ

ಟೋಪಾಲಜಿಗೆ ಸೂಕ್ಷ್ಮವಾದ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುವ ಅಧಿಕೃತ ಸರ್ವರ್ ಸಾಮಾನ್ಯವಾಗಿ ಕೇಳಿದ ಪುನರಾವರ್ತಕ ರಿಜಾಲ್ವರ್‍ನ ವಿಳಾಸವನ್ನು ನೋಡುತ್ತದೆ, ಹೆಸರನ್ನು ಟೈಪ್ ಮಾಡಿದ ವ್ಯಕ್ತಿಯ ವಿಳಾಸವನ್ನಲ್ಲ. ಕೇಂದ್ರೀಕೃತ ರಿಜಾಲ್ವರ್ ತಾನು ಸೇವೆ ಸಲ್ಲಿಸುವ ಕ್ಲೈಂಟ್‍ಗಳಿಂದ ದೂರವಿರಬಹುದು, ಮತ್ತು ಉತ್ತರ ಅವರ ಬದಲು ರಿಜಾಲ್ವರ್ ಅನ್ನು ಪ್ರತಿಬಿಂಬಿಸುತ್ತದೆ. ಇದು ದೋಷವಲ್ಲ; ಹೆಚ್ಚುವರಿ ಮಾಹಿತಿ ನೀಡದಿದ್ದರೆ ಪ್ರೋಟೋಕಾಲ್ ಹೀಗೆಯೇ ವರ್ತಿಸುತ್ತದೆ. EDNS ಕ್ಲೈಂಟ್ ಸಬ್‍ನೆಟ್ ವಿಶೇಷಣೆ ಮಿತಿ ಮತ್ತು ಐಚ್ಛಿಕ ಪರಿಹಾರ ಎರಡನ್ನೂ ವಿವರಿಸುತ್ತದೆ.

EDNS ಕ್ಲೈಂಟ್ ಸಬ್‍ನೆಟ್ ಮೂಲ ನೆಟ್‍ವರ್ಕ್ ಮಾಹಿತಿಯನ್ನು ಒಯ್ಯಬಹುದು, ಪ್ರತಿ ಭಾಗವಹಿಸುವವರೂ ಅದನ್ನು ಬೆಂಬಲಿಸಿ ಸಕ್ರಿಯಗೊಳಿಸಿದಾಗ. ಇದು ಐಚ್ಛಿಕ, ಇದಕ್ಕೆ ಗೋಪ್ಯತೆ ಮತ್ತು ಕ್ಯಾಶ್ ಪರಿಣಾಮಗಳಿವೆ, ಮತ್ತು ಯಾವುದೇ ಸಾರ್ವಜನಿಕ ರಿಜಾಲ್ವರ್ ನಿಖರವಾದ ಬಳಕೆದಾರ ಸ್ಥಳವನ್ನು ವರದಿ ಮಾಡುತ್ತದೆ ಎಂದು ಊಹಿಸಲು ಇದು ಅನುಮತಿಯಲ್ಲ. ಅದರ ಸುತ್ತ ವಿನ್ಯಾಸ ಮಾಡುವ ಮೊದಲು ರಿಜಾಲ್ವರ್ ನಿರ್ವಾಹಕರನ್ನು ಕೇಳಿ.

dig +short vpn.example.com @1.1.1.1
dig +short vpn.example.com @9.9.9.9
dig +subnet=203.0.113.0/24 +short vpn.example.com

ಎನಿಕಾಸ್ಟ್ ಮಾರ್ಗನಿರ್ದೇಶನ ಏನನ್ನು ನಿರ್ಧರಿಸಿತು ಎಂದು ಪರಿಶೀಲಿಸಿ

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

ಸೇವಾ ಸ್ಥಳವನ್ನು ಸೇವಾ ಬದಿಯಿಂದ, ಅಥವಾ ಅದನ್ನು ಹೆಸರಿಸುವ ಉತ್ತರದಿಂದ ದೃಢೀಕರಿಸಿ, ಕೇವಲ DNS ಉತ್ತರದಿಂದ ಅಲ್ಲ. traceroute -n 198.51.100.20 ನೀವು ತೆಗೆದುಕೊಂಡ ಮಾರ್ಗವನ್ನು ತೋರಿಸುತ್ತದೆ ಮತ್ತು ಅದರ ಕೊನೆಯಲ್ಲಿನ ಹೋಸ್ಟ್ ಅನ್ನು ಇನ್ನೂ ಹೆಸರಿಸುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಅದನ್ನು ಉತ್ತರವಲ್ಲ, ಮಾರ್ಗವಾಗಿ ಓದಿ.

ಸೆಷನ್ ನೋಡ್ ಬದಲಾವಣೆಯನ್ನು ತಡೆದುಕೊಳ್ಳುತ್ತದೆ ಎಂದು ಪರಿಶೀಲಿಸಿ

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

ಜರಿತವನ್ನು ಊಹಿಸುವ ಬದಲು ಗಮನಿಸಿ. sudo tcpdump -ni any -c 20 esp ಮಾರ್ಗ ಬದಲಾಗುತ್ತಿರುವಾಗ ಹೊರ ಪ್ಯಾಕೆಟ್‍ಗಳನ್ನು ತೋರಿಸುತ್ತದೆ, ಮತ್ತು ಸಹವರ್ತಿ ವಿಳಾಸದಲ್ಲಿ ಹಠಾತ್ ಬದಲಾವಣೆಯೇ ಆ ಜರಿತ. ನೀವು ಚಲಾಯಿಸುವ ಅನುಷ್ಠಾನಕ್ಕೆ ಉದ್ದೇಶಿತ ವರ್ತನೆಯನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ವ್ಯಾಖ್ಯಾನಿಸಿ, ನಂತರ ಮಾರ್ಗ ಬದಲಾವಣೆಯನ್ನು ಒತ್ತಾಯಿಸಿ ಅದನ್ನು ಪರೀಕ್ಷಿಸಿ. ವಿನ್ಯಾಸವು ಸೆಷನ್ ಪ್ರತಿಕೃತಿಯನ್ನು ಊಹಿಸಿದರೆ, ಕಾರ್ಯವಿಧಾನವನ್ನು ಹೆಸರಿಸಿ ಮತ್ತು ಅದು ಒಳಗೊಳ್ಳದ ವೈಫಲ್ಯವನ್ನು ಹೆಸರಿಸಿ.

ಗುರುತು ಇನ್ನೂ ಹೊಂದುತ್ತದೆ ಎಂದು ಪರಿಶೀಲಿಸಿ

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

ಅಸಾಮಾನ್ಯ ನೋಡ್‍ಗೆ ತಲುಪಿದ ಕ್ಲೈಂಟ್‍ನಿಂದ ಅದನ್ನು ಪರಿಶೀಲಿಸಿ, ಏಕೆಂದರೆ ಪ್ರತಿ-ನೋಡ್ ಪ್ರಮಾಣಪತ್ರ ಕಾಣಿಸಿಕೊಳ್ಳುವ ಸಂದರ್ಭ ಅದೇ. openssl s_client -connect vpn.example.com:443 -servername vpn.example.com ಸರಪಳಿ ಮತ್ತು ಹೆಸರುಗಳನ್ನು ಮುದ್ರಿಸುತ್ತದೆ, ಮತ್ತು ಕ್ಲೈಂಟ್ ಹೋಲಿಸುವುದು ನಿಖರವಾಗಿ ಅದನ್ನೇ. ನಂತರ ಪ್ರೊಫೈಲ್ ಸಂಕುಚಿತಗೊಳಿಸಬೇಕೇ ಅಥವಾ ಪ್ರಮಾಣಪತ್ರ ಮಾದರಿ ಬದಲಾಯಿಸಬೇಕೇ ಎಂದು ನಿರ್ಧರಿಸಿ.

ದಾಖಲೆಯನ್ನು ಪರಿಶೀಲಿಸಿ, ಕೇವಲ ಮೊದಲ ಉತ್ತರವನ್ನಲ್ಲ

ಮೂರು ಸನ್ನಿವೇಶಗಳನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡಿ ಮತ್ತು ಪ್ರತಿಯೊಂದಕ್ಕೂ ನಾಲ್ಕು ಸಂಗತಿಗಳನ್ನು ಬರೆಯಿರಿ: ಸಾಮಾನ್ಯ ಪ್ರವೇಶ, ಒಂದು ಸ್ಥಳ ಲಭ್ಯವಿಲ್ಲ, ಮತ್ತು ಒಪ್ಪಿದ ಚೇತರಿಕೆ ಪ್ರಕರಣ. ಆ ನಾಲ್ಕು ಸಂಗತಿಗಳೆಂದರೆ ಬಳಸಿದ ರಿಜಾಲ್ವರ್, ಹಿಂತಿರುಗಿಸಿದ ವಿಳಾಸ, ಸೇವೆ ಸಲ್ಲಿಸಿದ ಸ್ಥಳ, ಮತ್ತು ಹೊಸ ಅಪ್ಲಿಕೇಶನ್ ಫಲಿತಾಂಶ. ಆ ದಾಖಲೆ DNS ಆಯ್ಕೆಯ ಸಮಸ್ಯೆಯನ್ನು ಗೇಟ್‍ವೇ ಸಮಸ್ಯೆ, ಮಾರ್ಗನಿರ್ದೇಶನ ಸಮಸ್ಯೆ ಅಥವಾ ಸೆಷನ್ ಸ್ಥಿತಿ ಸಮಸ್ಯೆಯಿಂದ ಬೇರ್ಪಡಿಸುತ್ತದೆ. ಅದಿಲ್ಲದೆ, ನಾಲ್ಕೂ ಕ್ಲೈಂಟ್‍ನಿಂದ ಒಂದೇ ರೀತಿ ಕಾಣುತ್ತವೆ.

dig +short vpn.example.com
getent hosts vpn.example.com
curl -s -o /dev/null -w "%{http_code}
" https://vpn.example.com/health

ಸನ್ನಿವೇಶಗಳನ್ನು ಕಚೇರಿಯಿಂದ ಮಾತ್ರವಲ್ಲ, ಪ್ರತಿನಿಧಿ ಪ್ರವೇಶ ಜಾಲಗಳಿಂದ ಚಲಾಯಿಸಿ, ಏಕೆಂದರೆ ಇಡೀ ಪ್ರಶ್ನೆ ಬೇರೆ ಬೇರೆ ಕ್ಲೈಂಟ್‍ಗಳು ವಾಸ್ತವವಾಗಿ ಯಾವ ಪ್ರವೇಶ ಬಿಂದುವನ್ನು ತಲುಪುತ್ತವೆ ಎಂಬುದರ ಬಗ್ಗೆ. ಒಂದು ಜಾಲವು ಒಂದರ ಮಾದರಿ.