ಹೋಸ್ಟ್ VPN ಅನ್ನು ನಿರ್ಲಕ್ಷಿಸುವ Docker ಮತ್ತು WSL ಸಂಚಾರವನ್ನು ಸರಿಪಡಿಸಿ

ಕಂಟೇನರ್‌ಗಳು ಮತ್ತು WSL ತಮ್ಮದೇ ಮಾರ್ಗಗಳು, ರೆಸಾಲ್ವರ್ ಮತ್ತು ಫಾರ್ವರ್ಡ್ ಮಾರ್ಗವನ್ನು ಇಟ್ಟುಕೊಳ್ಳುತ್ತವೆ, ಆದ್ದರಿಂದ ಕೆಲಸ ಮಾಡುವ ಹೋಸ್ಟ್ ಟನೆಲ್ ಅವುಗಳನ್ನು ಹಳೆಯ DNS ಅಥವಾ ನಿರ್ಗಮನವಿಲ್ಲದೆ ಬಿಡುತ್ತದೆ. ಪ್ರತಿ ಪದರವನ್ನು ಸರಿಪಡಿಸಿ.

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

ನಿಯಮವನ್ನು ಬದಲಿಸುವ ಮೊದಲು ಮೂರು ಮಾರ್ಗ ಕೋಷ್ಟಕಗಳನ್ನು ಹೋಲಿಸಿ

Docker ನ ಡೀಫಾಲ್ಟ್ ಬ್ರಿಡ್ಜ್‌ನಲ್ಲಿರುವ ಕಂಟೇನರ್‌ಗೆ docker0 ಗೇಟ್‌ವೇಗೆ ತೋರುವ ಒಂದು ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗವಿದೆ, ಮತ್ತು tun0 ಇದೆ ಎಂಬುದು ಅದಕ್ಕೆ ಗೊತ್ತಿಲ್ಲ. ಹೋಸ್ಟ್‌ಗೆ tun0, VPN ದೂಡಿದ ಮಾರ್ಗಗಳು, ಮತ್ತು ನೀವು ನಿರೀಕ್ಷಿಸುವುದಕ್ಕಿಂತ ಬೇರೆ ಇಂಟರ್‌ಫೇಸ್ ಮೂಲಕ ಪರೀಕ್ಷಾ ಸಂಚಾರವನ್ನು ಕಳುಹಿಸುವ ನೀತಿ ನಿಯಮವೂ ಇರಬಹುದು. WSL ತನ್ನದೇ ವರ್ಚುಯಲ್ ಅಡಾಪ್ಟರ್‌ನ ಹಿಂದೆ ಮೂರನೇ ಕೋಷ್ಟಕವನ್ನು ಸೇರಿಸುತ್ತದೆ. ಯಾವುದನ್ನೂ ಸಂಪಾದಿಸುವ ಮೊದಲು ಮೂರನ್ನೂ ಮುದ್ರಿಸಿ.

ContextCommandWhat a wrong answer looks like
Hostip route get 10.8.0.20Leaves a physical interface instead of tun0
Containerip routeOnly 172.17.0.0/16 via 172.17.0.1
Container DNScat /etc/resolv.confA public resolver, or an upstream the tunnel never pushed
WSLip addr; ip routeOnly the WSL subnet, no Windows VPN adapter

ಕಂಟೇನರ್‌ನ ಏಕೈಕ ಮಾರ್ಗ ಬ್ರಿಡ್ಜ್ ಆಗಿದ್ದು, ಅದರ ಹೆಸರಿನ ಜಾಗದಲ್ಲಿ tun0 ಎಂದೂ ಕಾಣದಿದ್ದರೆ, ಕೆಳಗಿನ ಯಾವುದೂ ಸಹಾಯ ಮಾಡುವುದಿಲ್ಲ: ಯಾವುದೇ ನೇಮ್‌ಸರ್ವರ್ ಬದಲಾವಣೆ ಮಾರ್ಗವನ್ನು ಸೃಷ್ಟಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಯಾವುದೇ ಮಾರ್ಗವು ಪೀರ್ ಒಪ್ಪುವ ಟನೆಲ್ ಗುರುತನ್ನು ಸೃಷ್ಟಿಸುವುದಿಲ್ಲ. ಕ್ರಮ ಮುಖ್ಯ, ಏಕೆಂದರೆ DNS ವೈಫಲ್ಯ ಮತ್ತು ಮಾರ್ಗ ವೈಫಲ್ಯ ಶೆಲ್‌ನ ಒಳಗಿನಿಂದ ಒಂದೇ ರೀತಿ ಕಾಣುತ್ತವೆ.

ರೆಸಾಲ್ವರ್ ಅನ್ನು ಸಾರ್ವಜನಿಕದ ಬದಲು ಟನೆಲ್‌ಗೆ ತೋರಿಸಿ

ಹೋಸ್ಟ್‌ನಲ್ಲಿ, resolvectl status ಪ್ರತಿ ಲಿಂಕ್‌ಗೆ DNS ಸರ್ವರ್‌ಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ, ಮತ್ತು readlink -f /etc/resolv.conf ಫೈಲ್ systemd ಸ್ಟಬ್, NetworkManager ಫೈಲ್, ಅಥವಾ ವೆಂಡರ್ ಕ್ಲೈಂಟ್ ಮರುಬರೆದ ಯಾವುದೋ ಎಂದು ಹೇಳುತ್ತದೆ. ಬಳಕೆದಾರ ನಿರ್ಧರಿಸಿದ ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿರುವ ಕಂಟೇನರ್ ಒಳಗೆ, /etc/resolv.conf ಹೆಸರಿಸುತ್ತದೆ 127.0.0.11, Docker ನ ಒಳಗೊಂಡ ರೆಸಾಲ್ವರ್, ಅದು ಡೀಮನ್ ಸಂರಚಿಸಲಾದ upstream ಗೆ ಫಾರ್ವರ್ಡ್ ಮಾಡುತ್ತದೆ. ಡೀಫಾಲ್ಟ್ ಬ್ರಿಡ್ಜ್‌ನ ಕಂಟೇನರ್ ಬದಲಿಗೆ ರಚಿಸಿದಾಗ ಹೋಸ್ಟ್ ಫೈಲ್‌ನ ಪ್ರತಿಯನ್ನು ಪಡೆದು ಅದನ್ನು ಇಟ್ಟುಕೊಳ್ಳುತ್ತದೆ.

ಆ ಪ್ರತಿಯೇ ಕಂಟೇನರ್ ಪ್ರಾರಂಭವಾದ ನಂತರ ಏಳುವ ಟನೆಲ್ ಕಂಟೇನರ್ ಅನ್ನು ಹಳೆಯ upstream ಅನ್ನು ಕೇಳುತ್ತಿರುವಂತೆ ಬಿಡುವ ಕಾರಣ. ಒಂದೋ VPN ರೆಸಾಲ್ವರ್ ಅನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಇದರೊಂದಿಗೆ ರವಾನಿಸಿ docker run --dns 10.8.0.53, ಅಥವಾ "dns": ["10.8.0.53"] ನಲ್ಲಿ /etc/docker/daemon.json ಹೊಂದಿಸಿ ಡೀಮನ್ ಮರುಪ್ರಾರಂಭಿಸಿ, ಅಥವಾ ಟನೆಲ್ ಏರಿದ ನಂತರ ಕಂಟೇನರ್ ಅನ್ನು ಮತ್ತೆ ರಚಿಸಿ. ಮತ್ತೆ ರಚಿಸುವುದು ಸಾಮಾನ್ಯವಾಗಿ ಒಂದು ಗಂಟೆ ಮೊದಲು ಸರಿಯಾಗಿದ್ದ ರೆಸಾಲ್ವರ್ ಅನ್ನು ಡೀಬಗ್ ಮಾಡುವುದಕ್ಕಿಂತ ಅಗ್ಗ.

ಸಾರ್ವಜನಿಕ ರೆಸಾಲ್ವರ್ ಹಾಕುವುದು ಲಕ್ಷಣವನ್ನು ಉಳಿಸುವ ರಿಪೇರಿ. ಅದು ಇಂಟರ್ನೆಟ್ ಅನ್ನು ಪರಿಹರಿಸುತ್ತದೆ ಮತ್ತು ಪ್ರತಿ ಖಾಸಗಿ ವಲಯದಲ್ಲಿ ವಿಫಲವಾಗುತ್ತದೆ, ಮತ್ತು ಟನೆಲ್ ಇರುವ ಉದ್ದೇಶವಾದ ಫಿಲ್ಟರಿಂಗ್ ಅನ್ನು ಸದ್ದಿಲ್ಲದೆ ಬೈಪಾಸ್ ಮಾಡಬಹುದು. ಚಾಲನೆಯಲ್ಲಿರುವ ಕಂಟೇನರ್‌ನ /etc/resolv.conf ಒಳಗೆ ಬರೆಯಲು ಪ್ರಯತ್ನಿಸಿದರೆ, ನಿರೀಕ್ಷಿಸಿ Device or resource busy: Docker ಆ ಫೈಲ್ ಅನ್ನು bind-mount ಮಾಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಸಂಪಾದನೆಗೆ ಮೊದಲು ಅನ್‌ಮೌಂಟ್ ಬೇಕು. --dns ರಚನೆಯ ಸಮಯದಲ್ಲಿ ಹೊಂದಿಸುವುದು ಮರುಪ್ರಾರಂಭವನ್ನು ತಾಳುವ ಕ್ರಮ.

ಕಂಟೇನರ್‌ಗಳು ಟನೆಲ್ ಎರವಲು ಪಡೆದಾಗ ಫಾರ್ವರ್ಡ್ ಮಾಡಿ ಮತ್ತು ಅನುವಾದಿಸಿ

ಡೀಫಾಲ್ಟ್ ಬ್ರಿಡ್ಜ್‌ನೊಂದಿಗೆ, ಹೋಸ್ಟ್ docker0 ಮತ್ತು tun0 ನಡುವಿನ ರೂಟರ್, ಮತ್ತು ಡೀಫಾಲ್ಟ್ ಆಗಿ ಅದು ಎರಡೂ ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ. ಫಾರ್ವರ್ಡಿಂಗ್ ಆನ್ ಮಾಡಿ ಮತ್ತು ಮೂಲ ವಿಳಾಸವನ್ನು ಅನುವಾದಿಸಿ, ಇದರಿಂದ ಪೀರ್ ಹಿಂತಿರುಗುವ ಮಾರ್ಗವಿಲ್ಲದ ವಿಳಾಸದ ಬದಲು ಹೋಸ್ಟ್‌ನ ಟನೆಲ್ ವಿಳಾಸವನ್ನು ನೋಡುತ್ತದೆ (tun0 ಅನ್ನು ನಿಮ್ಮ ಕ್ಲೈಂಟ್ ಇಂಟರ್‌ಫೇಸ್‌ಗೆ ಕೊಡುವ ಹೆಸರಿನಿಂದ ಬದಲಿಸಿ):

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE
iptables -A FORWARD -i docker0 -o tun0 -j ACCEPT
iptables -A FORWARD -i tun0 -o docker0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

FORWARD ನಿಯಮಗಳು ಫಾರ್ವರ್ಡ್ ನೀತಿ DROP ಇರುವ ಹೋಸ್ಟ್‌ಗಳಲ್ಲಿ ಮುಖ್ಯ. Docker ತನ್ನದೇ ಸರಪಣಿಗಳನ್ನು ಸೇರಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಓದುವ ಬದಲು ಪ್ಯಾಕೆಟ್‌ನಿಂದ ಪರೀಕ್ಷಿಸಿ iptables -S: ಕಂಟೇನರ್‌ನಿಂದ, ip route get 10.8.0.20 ಬ್ರಿಡ್ಜ್ ಗೇಟ್‌ವೇ ಹೆಸರಿಸಬೇಕು, ಮತ್ತು nc -vz 10.8.0.20 443 ರೆಸಾಲ್ವರ್‌ನಲ್ಲಿ ಅಲ್ಲ, ಟನೆಲ್‌ನಲ್ಲಿ ಸಂಪರ್ಕವಾಗಬೇಕು ಅಥವಾ ಸಮಯ ಮೀರಬೇಕು.

MASQUERADE ಇಲ್ಲದೆ ಪೀರ್‌ಗೆ 172.17.0.0/16 ಗೆ ಹಿಂತಿರುಗುವ ಮಾರ್ಗ ಬೇಕು, ಅದನ್ನು ಬಹುಪಾಲು ರಿಮೋಟ್-ಆಕ್ಸೆಸ್ VPN ದೂಡುವುದಿಲ್ಲ. ಇಲ್ಲಿಯೇ ನೀತಿ ಆಧಾರಿತ ಕ್ಲೈಂಟ್ ಯೋಜನೆಯನ್ನು ಮುರಿಯುತ್ತದೆ: ಅದು ನಿರ್ದಿಷ್ಟ UID ಅಥವಾ cgroups ಸಂಚಾರವನ್ನು ಮಾತ್ರ ಹಿಡಿದರೆ, ನಿಮ್ಮ ಫಾರ್ವರ್ಡ್ ನಿಯಮಗಳು ಟನೆಲ್ ಒಳಗಿನ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಎಂದೂ ನೋಡುವುದಿಲ್ಲ, ಮತ್ತು ಸರಿಪಡಿಸುವಿಕೆ iptables ನಲ್ಲಲ್ಲ, ಕ್ಲೈಂಟ್‌ನ ರೂಟಿಂಗ್ ನೀತಿಯಲ್ಲಿ. ಕೈಯಿಂದ ಸೇರಿಸಿದ ನಿಯಮಗಳು ರೀಬೂಟ್‌ನಲ್ಲಿ ಮಾಯವಾಗುತ್ತವೆ, ಆದ್ದರಿಂದ ಅವುಗಳನ್ನು systemd ಯುನಿಟ್ ಅಥವಾ netfilter-persistent ಕೋಷ್ಟಕದಲ್ಲಿ ಇರಿಸಿ ಮತ್ತು ರೀಬೂಟ್ ನಂತರ ಮತ್ತೆ ಪರೀಕ್ಷಿಸಿ, ಏಕೆಂದರೆ ತಡವಾಗಿ ಏರುವ ಟನೆಲ್ ಅವನ್ನು ಕೊಚ್ಚಿ ಹಾಕಬಹುದು.

ಗುರಿ ಪ್ರತ್ಯೇಕತೆಯಾದಾಗ ಟನೆಲ್ ಅನ್ನು ಕಂಟೇನರ್ ಒಳಗೆ ಇರಿಸಿ

ಒಂದು ಕಂಟೇನರ್ ನಿರ್ದಿಷ್ಟ ನೋಡ್ ಮೂಲಕ ಹೊರಹೋಗಬೇಕಿದ್ದರೆ, ಆ ಕಂಟೇನರ್‌ನಲ್ಲಿ ಕ್ಲೈಂಟ್ ಚಲಾಯಿಸಿ. ಅದಕ್ಕೆ --cap-add NET_ADMIN ಮತ್ತು --device /dev/net/tun ಬೇಕು, ಮತ್ತು ಆಗ ಅದು ತನ್ನದೇ tun0, ಮಾರ್ಗಗಳು ಮತ್ತು ಫೈರ್‌ವಾಲ್ ಹೊಂದಿರುತ್ತದೆ. ಇತರ ಕಂಟೇನರ್‌ಗಳು ಅದರ ಮೂಲಕ ಹೋದರೆ, ಅದಕ್ಕೆ ಕಂಟೇನರ್ ಒಳಗೆ ಫಾರ್ವರ್ಡಿಂಗ್ ಮತ್ತು MASQUERADE ನಿಯಮವೂ ಬೇಕು, ಮತ್ತು ಆ ಪೀರ್‌ಗಳಿಗೆ ಅದರ ಕಡೆಗೆ ತೋರುವ ಸ್ಪಷ್ಟ ಮಾರ್ಗ ಅಥವಾ ಪ್ರಾಕ್ಸಿ ಬೇಕು; Docker ನ ಡೀಫಾಲ್ಟ್ ಬ್ರಿಡ್ಜ್ ಆ ಮಾರ್ಗವನ್ನು ನಿಮಗಾಗಿ ಸೇರಿಸುವುದಿಲ್ಲ.

ಹೋಸ್ಟ್ ನೆಟ್‌ವರ್ಕಿಂಗ್, docker run --network host, ಅಗ್ಗದ ಆವೃತ್ತಿ: ಕಂಟೇನರ್ ಹೋಸ್ಟ್‌ನ ಹೆಸರಿನ ಜಾಗವನ್ನು ಸೇರುತ್ತದೆ ಮತ್ತು ಟನೆಲ್ ಮಾರ್ಗಗಳನ್ನು ನೇರವಾಗಿ ನೋಡುತ್ತದೆ. ಅದು ನೆಟ್‌ವರ್ಕ್ ಪ್ರತ್ಯೇಕತೆಯನ್ನೂ ಬಿಡುತ್ತದೆ, ಪೋರ್ಟ್ ಘರ್ಷಣೆಗಳನ್ನು ಆಹ್ವಾನಿಸುತ್ತದೆ, ಮತ್ತು ಪ್ರಾಯೋಗಿಕವಾಗಿ ಇದು Linux ಆಯ್ಕೆ. ಪ್ರಕಟಿತ ಪೋರ್ಟ್ ಅದರ ಬದಲಿಯಲ್ಲ. -p 8080:80 ಸೇವೆಯನ್ನು ಹೋಸ್ಟ್‌ನಿಂದ ತಲುಪಬಹುದಾಗಿಸುತ್ತದೆ; ಆಂತರಿಕ 10.x ವಿಳಾಸಗಳನ್ನು ಕಂಟೇನರ್ ಒಳಗಿನಿಂದ ತಲುಪಬಹುದಾಗಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಎರಡನ್ನೂ ಬೆರೆಸುವುದೇ ರೂಟಿಂಗ್ ಸಮಸ್ಯೆ ತೆರೆದ ಡೇಟಾಬೇಸ್ ಪೋರ್ಟ್ ಆಗುವ ದಾರಿ.

ಹೆಸರು ವೈಫಲ್ಯವನ್ನು ಅತಿಕ್ರಮಿಸುವ ಸಬ್‌ನೆಟ್‌ನಿಂದ ಬೇರ್ಪಡಿಸಿ

Docker ನ ಡೀಫಾಲ್ಟ್ ಬ್ರಿಡ್ಜ್ 172.17.0.0/16, ಮತ್ತು ಅನೇಕ ಕಾರ್ಪೊರೇಟ್ VPN ಪೂಲ್‌ಗಳು 172.16.0.0/12 ಒಳಗಿವೆ. ಟನೆಲ್ ಆ ವ್ಯಾಪ್ತಿಯನ್ನು ಹೊಂದಿದ ನಂತರ, ಕಂಟೇನರ್‌ಗೆ ಉದ್ದೇಶಿಸಿದ ಸಂಚಾರವು ಬದಲಿಗೆ ಟನೆಲ್‌ಗೆ ರೂಟ್ ಆಗಬಹುದು. ಹೆಸರುಗಳು ವಿಫಲವಾಗುತ್ತವೆ, ದೋಷ DNS ನಂತೆ ಕಾಣುತ್ತದೆ, ಮತ್ತು ಸಮಸ್ಯೆ ವಿಳಾಸಗಳಲ್ಲಿದೆ. ಗಮ್ಯಸ್ಥಾನವನ್ನು ಪರಿಶೀಲಿಸಿ, ರೆಸಾಲ್ವರ್ ಅನ್ನಲ್ಲ: ip route get 172.17.0.5 ಹೋಸ್ಟ್‌ನಲ್ಲಿ, ನಂತರ ಬ್ರಿಡ್ಜ್ ಪೂರ್ವಪ್ರತ್ಯಯವನ್ನು VPN ಪೂಲ್ ಮತ್ತು docker network inspect bridge --format '{{range .IPAM.Config}}{{.Subnet}}{{end}}' ಜೊತೆ ಹೋಲಿಸಿ.

ರಿಪೇರಿ ಎಂದರೆ ವ್ಯಾಪ್ತಿಗಳಲ್ಲಿ ಒಂದನ್ನು ಸರಿಸುವುದು: ಒಂದೋ Docker ಗಾಗಿ ಬೇರೆ ಡೀಫಾಲ್ಟ್ ವಿಳಾಸ ಪೂಲ್ daemon.json ನಲ್ಲಿ, ಅಥವಾ ಕಾನ್ಸಂಟ್ರೇಟರ್‌ನಲ್ಲಿ ಬೇರೆ ಪೂಲ್. ಇಲ್ಲಿ ಇನ್ನೊಂದು ನೇಮ್‌ಸರ್ವರ್ ಸೇರಿಸುವುದರಿಂದ ಏನೂ ಆಗುವುದಿಲ್ಲ, ಮತ್ತು ssh -b ಕೂಡಾ ಅಲ್ಲ: ಕ್ಲೈಂಟ್ ಅನ್ನು ಇಂಟರ್‌ಫೇಸ್‌ಗೆ ಬಂಧಿಸುವುದು ಮೂಲ ವಿಳಾಸವನ್ನು ಬದಲಿಸುತ್ತದೆ, ಟನೆಲ್ ಒಳಗೆ ತೋರುವ ಗಮ್ಯ ಮಾರ್ಗವನ್ನಲ್ಲ. ತ್ವರಿತ ಕೆಲಸದ ವಿಭಜನೆ: ಹೋಸ್ಟ್‌ನಲ್ಲಿ ಪರಿಹಾರವಾಗಿ ಕಂಟೇನರ್‌ನಲ್ಲಿ ಆಗದ ಹೆಸರು ರೆಸಾಲ್ವರ್ ಸಮಸ್ಯೆ, ಆದರೆ ಕಂಟೇನರ್‌ನಲ್ಲಿ ನೇತಾಡಿ ಹೋಸ್ಟ್‌ನಲ್ಲಿ ಕೆಲಸ ಮಾಡುವ ನೇರ IP ಸಂಪರ್ಕ ಮಾರ್ಗ ಅಥವಾ ಫಾರ್ವರ್ಡ್ ಸರಪಳಿ ಸಮಸ್ಯೆ.

WSL ಮತ್ತು Docker Desktop Linux ನಿಯಮಗಳನ್ನು ಪಾಲಿಸುವುದಿಲ್ಲ

ತನ್ನ ಡೀಫಾಲ್ಟ್ NAT ಮೋಡ್‌ನಲ್ಲಿ, WSL ತನ್ನದೇ ವರ್ಚುಯಲ್ ಅಡಾಪ್ಟರ್ ಹಿಂದೆ ಕುಳಿತು Windows VPN ನ ಆಂತರಿಕ ಮಾರ್ಗಗಳು ಅಥವಾ DNS ಪ್ರತ್ಯಯಗಳನ್ನು ಪಡೆಯುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಬ್ರೌಸರ್ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಮತ್ತು ping ಡಿಸ್ಟ್ರಿಬ್ಯೂಷನ್ ಒಳಗೆ ಮಾಡುವುದಿಲ್ಲ. ಇತ್ತೀಚಿನ Windows 11 ಬಿಲ್ಡ್‌ಗಳಲ್ಲಿ ಲಭ್ಯವಿರುವ ಮಿರರ್ ನೆಟ್‌ವರ್ಕಿಂಗ್ ಬದಲಿಗೆ ಹೋಸ್ಟ್ ಇಂಟರ್‌ಫೇಸ್‌ಗಳನ್ನು ಹಂಚುತ್ತದೆ, ಆದರೆ ಅದನ್ನು .wslconfig ನಲ್ಲಿ ಸಕ್ರಿಯಗೊಳಿಸಿ ಡಿಸ್ಟ್ರಿಬ್ಯೂಷನ್ ಅನ್ನು wsl --shutdown ನಿಂದ ಮರುಪ್ರಾರಂಭಿಸಬೇಕು. ಸಕ್ರಿಯ ಮೋಡ್ ಅನ್ನು wslinfo --networking-mode ನಿಂದ ದೃಢೀಕರಿಸಿ, ಸರಿಪಡಿಸುವಿಕೆ ಅನ್ವಯಿಸುವ ಮೊದಲು, ಏಕೆಂದರೆ NAT ಉತ್ತರ ಮಿರರ್ ಮೋಡ್‌ಗೆ ತಪ್ಪು ಮತ್ತು ಪ್ರತಿಯಾಗಿಯೂ.

Docker Desktop ಇನ್ನೊಂದು ಪದರ ಸೇರಿಸುತ್ತದೆ. Windows ನಲ್ಲಿ Linux ಕಂಟೇನರ್‌ಗಳು ಐತಿಹಾಸಿಕವಾಗಿ vpnkit ಎಂದು ಕರೆಯಲಾಗುವ NAT ಅನುಷ್ಠಾನದ ಹಿಂದೆ ಕುಳಿತಿವೆ, ಮತ್ತು ಅವುಗಳ ಮಾರ್ಗ ಸ್ಥಳೀಯ Linux ಹೋಸ್ಟ್‌ಗಿಂತ ಭಿನ್ನ. Windows ಕಂಟೇನರ್‌ಗಳು Hyper-V ವರ್ಚುಯಲ್ ಸ್ವಿಚ್ ಮೂಲಕ ಸಂಪರ್ಕಗೊಳ್ಳುತ್ತವೆ, ಮತ್ತು ಕಾರ್ಪೊರೇಟ್ ಕ್ಲೈಂಟ್ ಆ ಸ್ವಿಚ್‌ನಿಂದ ಬರುವ ಸಂಚಾರವನ್ನು ನಿರ್ಬಂಧಿಸಬಹುದು, ಆದ್ದರಿಂದ ಒಂದೇ ಯಂತ್ರದಲ್ಲಿರುವ Linux ಕಂಟೇನರ್‌ಗಳು ನೆಟ್‌ವರ್ಕ್ ತಲುಪಬಹುದು ಆದರೆ Windows ಕಂಟೇನರ್‌ಗಳಿಗೆ ಏನೂ ಇಲ್ಲ. ಭೌತಿಕ ಅಡಾಪ್ಟರ್‌ಗೆ ಬದ್ಧವಾದ ಬಾಹ್ಯ ಸ್ವಿಚ್ ಸಾಮಾನ್ಯ ಪರಿಹಾರ, ಮತ್ತು ಅದು ಕಂಟೇನರ್‌ನ ನೆಟ್‌ವರ್ಕ್ ಗುರುತನ್ನು ನೀತಿ ಅನುಮತಿಸದಿರಬಹುದಾದ ರೀತಿಯಲ್ಲಿ ಬದಲಿಸುತ್ತದೆ.

ಇನ್ನೊಂದು ನಿಯಮ ಬರೆಯುವ ಮೊದಲು ನಾಲ್ಕು ಪದರಗಳನ್ನು ಕ್ರಮವಾಗಿ ನಡೆದು ಯಾವುದು ತಪ್ಪಾಗಿದೆಯೋ ಅಲ್ಲೇ ನಿಲ್ಲಿಸಿ:

  • ಕಂಟೇನರ್ ಒಳಗೆ: ip route ಖಾಸಗಿ ಪೂರ್ವಪ್ರತ್ಯಯವನ್ನು ತಲುಪುತ್ತದೆಯೇ, ಮತ್ತು /etc/resolv.conf ಅದನ್ನು ಪರಿಹರಿಸುವ upstream ಅನ್ನು ಹೆಸರಿಸುತ್ತದೆಯೇ?
  • ಹೋಸ್ಟ್‌ನಲ್ಲಿ: ಫಾರ್ವರ್ಡಿಂಗ್ ಆನ್ ಇದೆಯೇ, NAT ಟನೆಲ್ ಇಂಟರ್‌ಫೇಸ್‌ಗೆ ಬದ್ಧವಾಗಿದೆಯೇ, ಮತ್ತು ಫಾರ್ವರ್ಡ್ ಸರಪಳಿ ಬ್ರಿಡ್ಜ್‌ನಿಂದ ಟನೆಲ್ ಸ್ವೀಕರಿಸುತ್ತದೆಯೇ?
  • ಪೀರ್‌ನಲ್ಲಿ: ಅದು ಹಿಂತಿರುಗುವ ಮಾರ್ಗ ತಿಳಿದಿದೆಯೇ, ಅಥವಾ ಕಂಟೇನರ್ ಸಬ್‌ನೆಟ್ ಮರೆಮಾಡಲು NAT ಮೇಲೆ ಅವಲಂಬಿಸಿದ್ದೀರಾ?
  • ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ನಲ್ಲಿ: WSL NAT ಅಥವಾ ಮಿರರ್ ಮೋಡ್‌ನಲ್ಲಿದೆಯೇ, ಮತ್ತು ಕಂಟೇನರ್ Linux ಅಥವಾ Windows?

ಪ್ರತಿ ಪರೀಕ್ಷೆಯನ್ನು ಹೊಸ ಕಂಟೇನರ್ ಅಥವಾ ಶೆಲ್‌ನಲ್ಲಿ ಮತ್ತೆ ಚಲಾಯಿಸಿ. ಕ್ಯಾಶ್ ಮಾಡಿದ ಉತ್ತರ ಅಥವಾ ಸ್ಥಾಪಿತ ಸಂಪರ್ಕವಿರುವ ದೀರ್ಘಕಾಲದ ಪ್ರಕ್ರಿಯೆ ಸಂರಚನೆ ಸರಿಯಾದ ನಂತರವೂ ವಿಫಲವಾಗುತ್ತಲೇ ಇರುತ್ತದೆ, ಮತ್ತು ಆ ವೈಫಲ್ಯ ಕೆಲಸ ಮಾಡದ ಸರಿಪಡಿಸುವಿಕೆಯಂತೆಯೇ ಕಾಣುತ್ತದೆ.

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