VPN ನಲ್ಲಿ ಆಂತರಿಕ ಹೆಸರುಗಳು ವಿಫಲವಾಗುತ್ತವೆ, ಆದರೆ ಸಾರ್ವಜನಿಕ ಸೈಟ್ಗಳು ಸರಿಯಾಗಿ ತೆರೆಯುತ್ತವೆ

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

ಒಂದೇ ದೋಷವಲ್ಲದ ಎರಡು ಲಕ್ಷಣಗಳು

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

ಬಲೆ ಎಂದರೆ ಕಚೇರಿ ರೆಸಾಲ್ವರ್ ಅನ್ನು ಎಲ್ಲೆಡೆ ಸೇರಿಸುವುದು ಮೊದಲನೆಯನ್ನು ಸರಿಪಡಿಸುತ್ತದೆ ಮತ್ತು ಎರಡನೆಯನ್ನು ಖಾತರಿಪಡಿಸುತ್ತದೆ. ಸಾರ್ವಜನಿಕ ರೆಸಾಲ್ವರ್ ಅನ್ನು ಎಲ್ಲೆಡೆ ಸೇರಿಸುವುದು ವಿರುದ್ಧವಾಗಿ ಮಾಡುತ್ತದೆ.

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

ಯಾವ ಅಡಾಪ್ಟರ್ನ ರೆಸಾಲ್ವರ್ ಪ್ರಶ್ನೆಯನ್ನು ಪಡೆಯುತ್ತದೆ

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

ಬೈಂಡಿಂಗ್ ಕ್ರಮ ಕೇವಲ ಮೊದಲಾರ್ಧ. ಯಾವ ಹೆಸರುಗಳು ಆ ಅಡಾಪ್ಟರ್ಗೆ ಸೇರಿವೆ ಎಂದು ಕ್ಲೈಂಟ್ ತಿಳಿಯಬೇಕು, ಮತ್ತು ಅದು ಕ್ರಮದ ಪ್ರಶ್ನೆಯಲ್ಲ, ಪ್ರತ್ಯಯದ ಪ್ರಶ್ನೆ.

ಕೆಲಸ ಮಾಡುತ್ತಿರುವ ಯಂತ್ರದ ipconfig /all ಅನ್ನು ಸುರಂಗ ಮೇಲಿರುವಾಗ ತೆಗೆದ ಲ್ಯಾಪ್ಟಾಪ್ನದರ ಪಕ್ಕದಲ್ಲಿ ಇರಿಸಿ. ಕೆಲಸ ಮಾಡುತ್ತಿರುವ ಯಂತ್ರವು ತನ್ನ ಕಚೇರಿ ಅಡಾಪ್ಟರ್ನಲ್ಲಿ ಸಂಪರ್ಕ-ನಿರ್ದಿಷ್ಟ DNS ಪ್ರತ್ಯಯವನ್ನು ತೋರಿಸುತ್ತದೆ, ಮತ್ತು ಲ್ಯಾಪ್ಟಾಪ್ ಸುರಂಗದಲ್ಲಿ ಯಾವುದನ್ನೂ ತೋರಿಸದಿರಬಹುದು. ಈ ವ್ಯತ್ಯಾಸವು «ಸರ್ವರ್ ಇಲ್ಲಿಯೇ ಇದೆ ಮತ್ತು ಹೆಸರು ಇನ್ನೂ ವಿಫಲವಾಗುತ್ತದೆ» ಎಂಬ ವರದಿಗಳ ಇಡೀ ವರ್ಗವನ್ನು ವಿವರಿಸುತ್ತದೆ, ಏಕೆಂದರೆ ಪ್ರತ್ಯಯವಿಲ್ಲದೆ ಸಣ್ಣ ಹೆಸರು ಕಚೇರಿ ರೆಸಾಲ್ವರ್ ಸೇವೆ ನೀಡುವ ವಲಯಕ್ಕೆ ಎಂದಿಗೂ ಪೂರ್ಣಗೊಳ್ಳುವುದಿಲ್ಲ.

ಸಣ್ಣ ಹೆಸರಿಗೆ ಮಾರ್ಗಕ್ಕಿಂತ ಮೊದಲು ಪ್ರತ್ಯಯ ಬೇಕು

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

ಕೆಲಸ ಮಾಡುತ್ತಿರುವ ಯಂತ್ರದ ಪ್ರತ್ಯಯವನ್ನು DNS ಟ್ಯಾಬ್ನಲ್ಲಿ VPN ಅಡಾಪ್ಟರ್ನ IPv4 ಗುಣಲಕ್ಷಣಗಳಿಗೆ ನಕಲಿಸಿ, ನಂತರ ಮತ್ತೆ ಸಂಪರ್ಕಿಸಿ. Linux ನಲ್ಲಿ ಸಮಾನವಾದದ್ದು ಸುರಂಗ ಕೊಂಡಿಯಲ್ಲಿನ ಹುಡುಕಾಟ ಡೊಮೇನ್, ಅದನ್ನು systemd-resolved ಜಾಗತಿಕವಾಗಿ ಅಲ್ಲ, ಕೊಂಡಿಯ ಪ್ರಕಾರ ಬಹಿರಂಗಪಡಿಸುತ್ತದೆ.

ಎರಡು ಸೆಟ್ಟಿಂಗ್ಗಳನ್ನು ನಿಮ್ಮ ಟಿಪ್ಪಣಿಗಳಲ್ಲಿ ಪ್ರತ್ಯೇಕವಾಗಿ ಇರಿಸಿ. ಪ್ರತ್ಯಯ ಏನನ್ನು ಕೇಳಲಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ಬದಲಿಸುತ್ತದೆ; ರೆಸಾಲ್ವರ್ ವಿಳಾಸ ಯಾರನ್ನು ಕೇಳಲಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ಬದಲಿಸುತ್ತದೆ. ಒಂದನ್ನು ಸರಿಪಡಿಸುವಾಗ ಇನ್ನೊಂದು ತಪ್ಪಾಗಿದ್ದರೆ ಫಲಿತಾಂಶ ಯದೃಚ್ಛಿಕವಾಗಿ ಕಾಣುತ್ತದೆ.

ರೆಸಾಲ್ವರ್ ಅನ್ನು ನೇರವಾಗಿ ಕೇಳಿ, ನಂತರ ಹೆಸರನ್ನು

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

nslookup intranet.corp.example 10.20.0.53
nslookup intranet
resolvectl status

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

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

Linux ನಲ್ಲಿ /etc/resolv.conf ಅನ್ನು ಮತ್ತೆ ಬರೆಯುವ VPN ಕ್ಲೈಂಟ್ ಸ್ಥಳೀಯ ರೆಸಾಲ್ವರ್ಗಳನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಬದಲಿಸುತ್ತದೆ. vpnc ಅದನ್ನು ನಿಲ್ಲಿಸಲು DNSUpdate no ಅನ್ನು ಒದಗಿಸುತ್ತದೆ, ಮತ್ತು systemd-resolved ಪಟ್ಟಿ ಮಾಡಿದ ಡೊಮೇನ್ಗಳನ್ನು ಮಾತ್ರ ಸುರಂಗ ಕೊಂಡಿಗೆ ಮಾರ್ಗದರ್ಶನ ಮಾಡಬಹುದು. ಎರಡೂ ವಿಧಾನಗಳು ಸಾರ್ವಜನಿಕ ಹೆಸರುಗಳನ್ನು ಸ್ಥಳೀಯ ರೆಸಾಲ್ವರ್ನಲ್ಲಿ ಉಳಿಸಿಕೊಂಡು ಆಂತರಿಕ ಹೆಸರುಗಳನ್ನು ಕಚೇರಿಗೆ ಕಳುಹಿಸುತ್ತವೆ.

ಸೋರಿಕೆಗಳು ಚೆಕ್ಬಾಕ್ಸ್ ಅಲ್ಲ, ನಿಯಮ

ಹೆಸರು ಪರಿಹಾರವು ಪೋರ್ಟ್ 53 ಗೆ UDP ವಿನಿಮಯ, ಆದ್ದರಿಂದ ವೆಬ್ ಸಂಚಾರವನ್ನು ಸಾಗಿಸಿ UDP ಅನ್ನು ಸಾಗಿಸದ ಸುರಂಗವು ಪ್ರಶ್ನೆಯನ್ನು ಭೌತಿಕ ಮಾರ್ಗದಲ್ಲಿ ಬಿಡುತ್ತದೆ. ಸಾರ್ವಜನಿಕ ಹೆಸರು ಪರಿಹರಿಸಲ್ಪಡುತ್ತಿರುವಾಗ ಭೌತಿಕ NIC ನಲ್ಲಿ ಸೆರೆಹಿಡಿದು ಸಾಬೀತು ಮಾಡಿ. ಆ ಇಂಟರ್ಫೇಸ್ನಲ್ಲಿ ಓದಬಹುದಾದ ರೂಪದಲ್ಲಿ ಕಾಣುವ ಪ್ರಶ್ನೆ ಎಂದರೆ ಸುರಂಗ ಅದನ್ನು ಸಾಗಿಸುತ್ತಿಲ್ಲ.

sudo tcpdump -ni eth0 -c 20 'udp port 53'
resolvectl query example.com

ಪ್ರಶ್ನೆ ಆ ಇಂಟರ್ಫೇಸ್ನಲ್ಲಿ ಓದಬಹುದಾದ ರೂಪದಲ್ಲಿ ಕಾಣಿಸಿಕೊಂಡರೆ, ಸುರಂಗ ಅದನ್ನು ಸಾಗಿಸುತ್ತಿಲ್ಲ. ದುರಸ್ತಿ ಎಂದರೆ VPN ಒದಗಿಸಿದ ರೆಸಾಲ್ವರ್ಗೆ ಮಾತ್ರ ಪೋರ್ಟ್ 53 ಅನ್ನು ಅನುಮತಿಸಿ ಇತರ ಗಮ್ಯಸ್ಥಾನಗಳನ್ನು ಬಿಡುವ ನಿಯಮ, ಜೊತೆಗೆ ಒದಗಿಸಿದ ಆಯ್ಕೆಯನ್ನು ಮೌನವಾಗಿ ತಿರಸ್ಕರಿಸದ ಕ್ಲೈಂಟ್ ಸಂರಚನೆ.

ಆ ಕೊನೆಯ ಭಾಗ ಕಾಣುವುದಕ್ಕಿಂತ ಹೆಚ್ಚು ಮುಖ್ಯ. OpenVPN ಅನ್ನು route-nopull ಜೊತೆಗೆ ಪ್ರಾರಂಭಿಸಿ ಮತ್ತು ಪುಲ್ ಫಿಲ್ಟರ್ ಅನ್ನು ಅದನ್ನು ಉಳಿಸಿಕೊಳ್ಳಲು ವಿಸ್ತರಿಸದ ಹೊರತು ಒದಗಿಸಿದ DNS ಆಯ್ಕೆ ಮಾರ್ಗಗಳೊಂದಿಗೆ ಮಾಯವಾಗುತ್ತದೆ. ಮತ್ತು dhcp-option DNS ಅನ್ನು ನಿರ್ಲಕ್ಷಿಸುವ ಕ್ಲೈಂಟ್ ಮೊದಲು ಇದ್ದದ್ದನ್ನು ಬಳಸುವುದನ್ನು ಮುಂದುವರಿಸುತ್ತದೆ. ಸರ್ವರ್ ಬದಿಯಲ್ಲಿ ಯಾವುದೇ ಬದಲಾವಣೆಗೆ ಹೊಸ ಸೆಷನ್ ಬೇಕು, ಏಕೆಂದರೆ ರೆಸಾಲ್ವರ್ಗಳ ಪಟ್ಟಿ ಸುರಂಗ ಮೇಲೆ ಬಂದಾಗ ತಲುಪಿಸಲ್ಪಡುತ್ತದೆ ಮತ್ತು ಹಳೆಯ ಸೆಷನ್ ಹಳೆಯ ಸ್ಥಿತಿಯನ್ನು ತೋರಿಸುತ್ತಲೇ ಇರುತ್ತದೆ.

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