VPN ಸಂಪರ್ಕವಾದ ನಂತರ WSL2 DNS ಕಳೆದುಕೊಂಡಿತು? ಎರಡು ಕಾರಣಗಳು

ಹಳೆಯ resolver ಕಡತ ಮತ್ತು ಸ್ಪರ್ಧಾತ್ಮಕ ಮಾರ್ಗ ಮೆಟ್ರಿಕ್ WSL2 ಒಳಗೆ ಒಂದೇ ಲಕ್ಷಣವನ್ನು ಉಂಟುಮಾಡುತ್ತವೆ. ಎರಡೂ ಬದಿಗಳನ್ನು ದಾಖಲಿಸಿ, ನಂತರ ನಿಜವಾಗಿ ಮುರಿದದ್ದನ್ನು ಸರಿಪಡಿಸಿ.

ವಿಳಾಸದ ಮೂಲಕ ping ಡಿಸ್ಟ್ರಿಬ್ಯೂಶನ್ ಒಳಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ, ಪ್ಯಾಕೇಜ್ ಸ್ಥಾಪನೆಗಳು ಮತ್ತು git ಎಳೆತಗಳು ಮಾಡುವುದಿಲ್ಲ, ಮತ್ತು ವೈಫಲ್ಯ ಟನೆಲ್ ಮೇಲೆದ್ದ ನಂತರ ತಕ್ಷಣ ಕಾಣಿಸಿತು. ಹೆಸರುಗಳು ಮಾತ್ರ ಬಿಡಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿದವು, ಇದು DNS ಕಡೆಗೆ ಸೂಚಿಸುತ್ತದೆ, ಸಂಪರ್ಕದ ಕಡೆಗಲ್ಲ. ಪ್ಯಾಕೇಜ್‌ಗಳನ್ನು ಮತ್ತೆ ಸ್ಥಾಪಿಸುವುದು ಇಲ್ಲಿ ಅತ್ಯಂತ ಜನಪ್ರಿಯ ತಪ್ಪಾದ ಮೊದಲ ಹೆಜ್ಜೆ. WSL2 ಗೆ ನಿಖರವಾಗಿ ಅದೇ ಲಕ್ಷಣವನ್ನು ಉಂಟುಮಾಡುವ ಎರಡು ಸ್ವತಂತ್ರ ದಾರಿಗಳಿವೆ, ಮತ್ತು ಎರಡೂ ಬೇರೆ ಬೇರೆ ದುರಸ್ತಿ ಬೇಕು.

ಡಿಸ್ಟ್ರಿಬ್ಯೂಶನ್ ತನ್ನದೇ resolver ಅನ್ನು ಏಕೆ ಇಟ್ಟುಕೊಳ್ಳುತ್ತದೆ

Windows ನ DNS ಕ್ಲೈಂಟ್ ಡಿಸ್ಟ್ರಿಬ್ಯೂಶನ್ ಒಳಗೆ ಬಳಕೆಯಾಗುವುದಿಲ್ಲ. WSL2 ಪ್ರಾರಂಭದಲ್ಲಿ ತನ್ನದೇ resolver ಕಡತವನ್ನು ನಿರ್ಮಿಸುತ್ತದೆ, ಅದು Windows ಸಹಾಯಕ ವರ್ಚುವಲ್ ಮೆಷಿನ್‌ಗಾಗಿ ವರ್ಚುವಲ್ ಸ್ವಿಚ್‌ನಲ್ಲಿ ಪ್ರಕಟಿಸುವ stub ವಿಳಾಸಕ್ಕೆ ತೋರಿಸುತ್ತದೆ.

ಸಾಮಾನ್ಯ ನೆಟ್‌ವರ್ಕ್ ಬದಲಾವಣೆಗಳಲ್ಲಿ ಈ ವ್ಯವಸ್ಥೆ ಸ್ಥಿರವಾಗಿರುತ್ತದೆ ಏಕೆಂದರೆ ಅದು ಒಮ್ಮೆ ಬರೆದು ಮತ್ತೆ ಬಳಸಲ್ಪಡುತ್ತದೆ. ಸಹಾಯಕ ವರ್ಚುವಲ್ ಮೆಷಿನ್ ಈಗಾಗಲೇ ಪ್ರಾರಂಭವಾದ ನಂತರ ಟನೆಲ್ ಕ್ಲೈಂಟ್ ಹೋಸ್ಟ್‌ನ ಅಡಾಪ್ಟರ್ ಪಟ್ಟಿಯನ್ನು ಮತ್ತೆ ಬರೆದಾಗ ಈ ವ್ಯವಸ್ಥೆ ಸರಿಯಾಗಿರುವುದಿಲ್ಲ.

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

ಮೊದಲು ಎರಡೂ ಬದಿಗಳಲ್ಲಿ ಸಾಕ್ಷ್ಯ ಸಂಗ್ರಹಿಸಿ

ಯಾವುದನ್ನೂ ಬದಲಿಸುವ ಮೊದಲು ಡಿಸ್ಟ್ರಿಬ್ಯೂಶನ್ ಏನು ನೋಡುತ್ತದೆ, ನಂತರ Windows ಏನು ನೋಡುತ್ತದೆ ಎಂದು ದಾಖಲಿಸಿ. ಎರಡೂ ದೃಶ್ಯಗಳು ಒಟ್ಟಿಗೆ ಇರುವುದೇ ವೈಫಲ್ಯದ ವಿಧಾನಗಳನ್ನು ಬೇರ್ಪಡಿಸುತ್ತದೆ.

ಡಿಸ್ಟ್ರಿಬ್ಯೂಶನ್ ಒಳಗೆ, resolver ಕಡತ, ಮಾರ್ಗ ಕೋಷ್ಟಕ ಮತ್ತು ಒಂದು ಒಳಾಂಗಣ ಹಾಗೂ ಒಂದು ಸಾರ್ವಜನಿಕ lookup ಮುದ್ರಿಸಿ:

ip -4 route
cat /etc/resolv.conf
getent hosts intranet.corp.example
getent hosts example.com

Windows ನಲ್ಲಿ, ಪ್ರತಿ ಅಡಾಪ್ಟರ್‌ನ DNS ಸರ್ವರ್‌ಗಳನ್ನು ಮತ್ತು ಮೆಟ್ರಿಕ್‌ಗಳೊಂದಿಗೆ IPv4 ಕೋಷ್ಟಕವನ್ನು ಪಟ್ಟಿ ಮಾಡಿ. VPN ಕ್ಲೈಂಟ್ ಸಾಮಾನ್ಯವಾಗಿ WSL2 ಸಬ್‌ನೆಟ್‌ಗೆ ಮಾರ್ಗವನ್ನು ಸ್ಥಾಪಿಸುತ್ತದೆ, ಮತ್ತು ಅದರ ಮೆಟ್ರಿಕ್ ಆ ಸಂಚಾರ ಟನೆಲ್ ಮೂಲಕ ಹೊರಡುತ್ತದೆಯೇ ಅಥವಾ ಸ್ಥಳೀಯವಾಗಿ ಉಳಿಯುತ್ತದೆಯೇ ಎಂದು ನಿರ್ಧರಿಸುತ್ತದೆ.

Get-NetAdapter | Get-DnsClientServerAddress
route print -4

ಮಾರ್ಗ ಮೆಟ್ರಿಕ್ ಅಥವಾ ಹಳೆಯ ಕಡತ

ಮೊದಲ ವೈಫಲ್ಯ ಹಳೆಯ ಕಡತ. resolver ಪ್ರಾರಂಭದ ಸಮಯದ ಅಡಾಪ್ಟರ್ ಸ್ಥಿತಿಗೆ ಬರೆಯಲಾಗಿತ್ತು, ಮತ್ತು ಟನೆಲ್ ಆ ಸ್ಥಿತಿಯನ್ನು ಬದಲಿಸಿತು. ಅದರ stub ವಿಳಾಸ ಈಗ ತಲುಪಲಾಗದಂತಿರಬಹುದು, ಅಥವಾ ಒಳಾಂಗಣ ವಲಯದ ಬಗ್ಗೆ ಏನೂ ತಿಳಿಯದ ಸರ್ವರ್ ಅನ್ನು ಹೆಸರಿಸಬಹುದು.

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

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

ಮಾರ್ಗದ ಸಂದರ್ಭಕ್ಕೆ, ಟನೆಲ್ ಅಡಾಪ್ಟರ್‌ನ ಸ್ವಯಂಚಾಲಿತ ಮೆಟ್ರಿಕ್ ತೆಗೆದುಹಾಕಿ ಮತ್ತು WSL2 ಲಿಂಕ್ ಮಾರ್ಗಕ್ಕಿಂತ ಮೇಲಿನ ಸಂಖ್ಯೆ ನೀಡಿ:

Get-NetAdapter | Where-Object InterfaceDescription -Match VPN | Set-NetIPInterface -InterfaceMetric 5500
wsl.exe --shutdown

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

ಕಡತವನ್ನು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ವಹಿಸಿಕೊಳ್ಳಿ

ಮಾರ್ಗ ಸರಿಯಾಗಿದ್ದು ಒಳಾಂಗಣ ಹೆಸರುಗಳು ಮಾತ್ರ ವಿಫಲವಾದರೆ, resolver ದೋಷಿಯಾಗಿದೆ ಮತ್ತು ನೀವು ಜನರೇಟರ್ ನಿಲ್ಲಿಸಬಹುದು. ಇದು ನಿರ್ವಹಣಾ ವೆಚ್ಚವಿರುವ ಉದ್ದೇಶಪೂರ್ವಕ ಬದಲಾವಣೆ, ಅಲಕ್ಷ್ಯದಿಂದ ಅನ್ವಯಿಸುವ ಪರಿಹಾರವಲ್ಲ.

ಡಿಸ್ಟ್ರಿಬ್ಯೂಶನ್ ಒಳಗೆ ಉತ್ಪಾದನೆಯನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುವ ನೆಟ್‌ವರ್ಕ್ ವಿಭಾಗದೊಂದಿಗೆ /etc/wsl.conf ರಚಿಸಿ, ನಂತರ resolver ಕಡತವನ್ನು ನೀವೇ ಬರೆಯಿರಿ, ಮೊದಲು ಕಾರ್ಪೊರೇಟ್ ಸರ್ವರ್ ಮತ್ತು ನಂತರ ಸಾರ್ವಜನಿಕ ಬದಲಿ:

[network]
generateResolvConf = false
search corp.example
nameserver 10.88.4.53
nameserver 9.9.9.9

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

ಮೊದಲು ಹೆಸರುಗಳನ್ನು, ನಂತರ ಪ್ಯಾಕೇಜ್‌ಗಳನ್ನು ಪರಿಶೀಲಿಸಿ

ಸಿಸ್ಟಮ್ resolver ನೊಂದಿಗೆ ಒಂದು ಒಳಾಂಗಣ ಮತ್ತು ಒಂದು ಸಾರ್ವಜನಿಕ ಹೆಸರನ್ನು ಪರಿಶೀಲಿಸಿ, ನಂತರ ವಿಫಲವಾದ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಪುನರಾವರ್ತಿಸಿ. ಪ್ಯಾಕೇಜ್ ನಿರ್ವಾಹಕರು ಕೆಲವೊಮ್ಮೆ ತಮ್ಮದೇ resolver ಬಳಸುತ್ತಾರೆ, ಆದ್ದರಿಂದ ಕೆಲಸ ಮಾಡುವ getent ಮುರಿದ ಸ್ಥಾಪನೆಯೊಂದಿಗೂ ಇರಬಹುದು.

ಮತ್ತೆ ಬರೆಯುವುದನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಿದರೆ, ಅದನ್ನು ಒಂದೇ ಫಲಿತಾಂಶ ಕೊಡುವಂತೆ ಮಾಡಿ: ಟನೆಲ್ ಇಲ್ಲದಿದ್ದಾಗ ಖಾಲಿ ಸರ್ವರ್ ಪಟ್ಟಿ ಬರೆಯುವ ಬದಲು ಈಗಾಗಲೇ ಇರುವ ಕಡತವನ್ನು ಇಡಿ.

getent hosts intranet.corp.example
resolvectl status | head -20
getent hosts example.com

ಡಿಸ್ಟ್ರಿಬ್ಯೂಶನ್ ಒಳಗಿನಿಂದ ಕೆಲಸ ಮಾಡುವ ಒಳಾಂಗಣ lookup ಮತ್ತು ಕೆಲಸ ಮಾಡುವ ಸಾರ್ವಜನಿಕ lookup ಇವೇ ದಾಖಲಿಸಲು ಯೋಗ್ಯವಾದ ಫಲಿತಾಂಶ. ಹೋಸ್ಟ್‌ನಲ್ಲಿ ಹಸಿರು VPN ಚಿಹ್ನೆ ಎರಡನ್ನೂ ಸಾಬೀತು ಮಾಡುವುದಿಲ್ಲ.

ಸಂಬಂಧಿತ ಲೇಖನಗಳು