Windows ಕಂಟೇನರ್ಗಳು ಮತ್ತು VPN: ಸ್ಥಳೀಯ ನೆಟ್ವರ್ಕಿಂಗ್ ಏಕೆ ಮುರಿಯುತ್ತದೆ
Windows ಕಂಟೇನರ್ ಹೋಸ್ಟ್ನ ಮಾರ್ಗ ಕೋಷ್ಟಕವನ್ನು ಬಳಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಸ್ಥಳೀಯ ಉಪಜಾಲವನ್ನು ತಡೆಯುವ VPN ಕಂಟೇನರ್ನ ಮುನ್ನಡಿಯನ್ನೂ ಒಯ್ಯುತ್ತದೆ. Linux ಮೋಡ್ ಬೇರೆ ದಾರಿ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ.
ಒಂದೇ ಲ್ಯಾಪ್ಟಾಪ್ನಲ್ಲಿ, ಒಂದು VPN ಕ್ಲೈಂಟ್ ಸಂಪರ್ಕಗೊಂಡಾಗ, Linux ಕಂಟೇನರ್ಗಳು ಪರಸ್ಪರ ಮಾತನಾಡುವುದನ್ನು ಮುಂದುವರಿಸುತ್ತವೆ ಮತ್ತು Windows ಕಂಟೇನರ್ಗಳು ನಿಲ್ಲುತ್ತವೆ. ಬದಲಾಗುವ ಅಂಶ ಚಿತ್ರವಲ್ಲ; ಪ್ಯಾಕೆಟ್ಗಳು ಹೋಸ್ಟ್ಗೆ ಹೋಗುವ ದಾರಿಯೇ. ಡೀಫಾಲ್ಟ್ ಜಾಲದಲ್ಲಿನ Windows ಕಂಟೇನರ್ಗಳು ಹೋಸ್ಟ್ನ ಮಾರ್ಗ ಕೋಷ್ಟಕ ಮತ್ತು ಅನುವಾದವನ್ನು ಎರವಲು ಪಡೆಯುತ್ತವೆ, ಆದ್ದರಿಂದ ಹೋಸ್ಟ್ನ ಮಾರ್ಗದರ್ಶನವನ್ನು ಬದಲಿಸುವ ನೀತಿ ಅವುಗಳನ್ನೂ ಬದಲಿಸುತ್ತದೆ. ಏನನ್ನಾದರೂ ಮರುಸ್ಥಾಪಿಸುವ ಮೊದಲು ಮಾರ್ಗ ಹುಡುಕಾಟದಿಂದ ಅದನ್ನು ದೃಢೀಕರಿಸಿ.
Windows ಕಂಟೇನರ್ನ ಪ್ಯಾಕೆಟ್ಗಳು ಹೋಸ್ಟ್ಗೆ ಎಲ್ಲಿ ಪ್ರವೇಶಿಸುತ್ತವೆ
ಡೀಫಾಲ್ಟ್ nat ಜಾಲದಲ್ಲಿನ ಕಂಟೇನರ್ Host Networking Service ಮುನ್ನಡಿಯಿಂದ ವಿಳಾಸ ಪಡೆಯುತ್ತದೆ, ಸಾಮಾನ್ಯವಾಗಿ 172.16.0.0/12 ಒಳಗೆ ಎಲ್ಲೋ, ಮತ್ತು ವರ್ಚುವಲ್ ಅಡಾಪ್ಟರ್ ಮೂಲಕ ಹೋಸ್ಟ್ ತಲುಪುತ್ತದೆ. ಆ ಮುನ್ನಡಿಯ ಮಾರ್ಗವನ್ನು ಹೋಸ್ಟ್ ಹೊಂದಿದೆ ಮತ್ತು ಸದ್ಯ ಸಕ್ರಿಯವಾಗಿರುವ ಅಡಾಪ್ಟರ್ನತ್ತ ಸಂಚಾರವನ್ನು ಅನುವಾದಿಸುತ್ತದೆ. ಆ ದಾರಿಯ ಮಧ್ಯದಲ್ಲಿ ಬೇರೆ ವರ್ಚುವಲ್ ಯಂತ್ರವಿಲ್ಲ.
ಈ ವಿನ್ಯಾಸವೇ ವೈಫಲ್ಯವನ್ನು ಯಾಂತ್ರಿಕವಾಗಿಸುತ್ತದೆ. ಕಂಟೇನರ್ ಪ್ಯಾಕೆಟ್ ಕಳುಹಿಸಿದಾಗ, ಹೋಸ್ಟ್ ಕಂಟೇನರ್ ಮುನ್ನಡಿಗಾಗಿ ಮಾರ್ಗ ಹುಡುಕಾಟ ಮಾಡುತ್ತದೆ. ಯಾವ ಮಾರ್ಗ ಗೆಲ್ಲುತ್ತದೆಯೋ ಅಲ್ಲಿಗೆ ಪ್ಯಾಕೆಟ್ ಹೋಗುತ್ತದೆ, ಮತ್ತು ಕಂಟೇನರ್ಗೆ ಅದರ ಬಗ್ಗೆ ಅಭಿಪ್ರಾಯವಿಲ್ಲ.
VPN ಕ್ಲೈಂಟ್ ಆ ದಾರಿಯಲ್ಲಿ ಏನನ್ನು ಬದಲಿಸುತ್ತದೆ
ಸಾಂಸ್ಥಿಕ ಕ್ಲೈಂಟ್ ಸಾಮಾನ್ಯವಾಗಿ ಅನೇಕ ಮಾರ್ಗಗಳ ಗುಂಪನ್ನು ಮತ್ತು ಸುರಂಗ ಸಕ್ರಿಯವಾಗಿರುವಾಗ ಸ್ಥಳೀಯ ಉಪಜಾಲಕ್ಕೆ ಪ್ರವೇಶವನ್ನು ನಿರಾಕರಿಸುವ ಫಿಲ್ಟರ್ ಅನ್ನು ಸ್ಥಾಪಿಸುತ್ತದೆ. ಉದ್ದೇಶ ರಕ್ಷಣಾತ್ಮಕ: ಹಾನಿಗೊಳಗಾದ ಸ್ಥಳೀಯ ಜಾಲವು ರಕ್ಷಿತ ಯಂತ್ರವನ್ನು ತಲುಪಬಾರದು. ಅಡ್ಡ ಪರಿಣಾಮವೆಂದರೆ ಹೋಸ್ಟ್ನ ಮಾರ್ಗ ಕಂಟೇನರ್ ಮುನ್ನಡಿಯವರೆಗೆ ಇನ್ನು ಸ್ಥಳೀಯ NAT ಜಾಲವಲ್ಲ.
ಬದಲಾಗಿ ಹುಡುಕಾಟ ಸುರಂಗಕ್ಕೆ ಹೊಂದುತ್ತದೆ ಮತ್ತು ಪ್ಯಾಕೆಟ್ ಆ ಕಂಟೇನರ್ ವಿಳಾಸವನ್ನು ಎಂದೂ ಕೇಳದ ಗೇಟ್ವೇಗೆ ನೀಡಲಾಗುತ್ತದೆ. Ping ವಿಫಲವಾಗುತ್ತದೆ, ಅಪ್ಲಿಕೇಶನ್ ಸಮಯ ಮೀರುತ್ತದೆ, ಮತ್ತು VPN ಐಕಾನ್ ಹೊಳೆಯುತ್ತಿರುವಾಗ ಕಂಟೇನರ್ ಮುರಿದಂತೆ ಕಾಣುತ್ತದೆ. ಸಂಪರ್ಕದಲ್ಲಿರುವಾಗ ಹೋಸ್ಟ್ನ ಕೋಷ್ಟಕ ನೋಡಿ, ಸ್ಪರ್ಧಿ ಮಾರ್ಗ ಕಾಣುತ್ತದೆ.
| Container mode | Outbound path | Typical result behind the VPN |
|---|---|---|
| Windows, default nat | Host routes and translates container traffic | Container prefix follows the tunnel and fails |
| Windows, transparent | Container sits on the physical link | Depends on the local subnet being allowed |
| Linux engine on Docker Desktop | VM egress proxied by a host process | Often keeps working |
Linux ಕಂಟೇನರ್ಗಳು ಏಕೆ ಬೇರೆ ರೀತಿ ವರ್ತಿಸುತ್ತವೆ
Linux ಎಂಜಿನ್ ಕಂಟೇನರ್ಗಳನ್ನು ಹಗುರ ವರ್ಚುವಲ್ ಯಂತ್ರದ ಒಳಗೆ ನಡೆಸುತ್ತದೆ, ಮತ್ತು ಆ ಯಂತ್ರದಿಂದ ಹೊರಹೋಗುವ ಸಂಪರ್ಕಗಳನ್ನು ಕಂಟೇನರ್ನ ಪರವಾಗಿ ಹೋಸ್ಟ್ ಬದಿಯ ಪ್ರಾಕ್ಸಿ ತೆರೆಯುತ್ತದೆ. ಸಾಕೆಟ್ ಅನ್ನು ಹೋಸ್ಟ್ ಪ್ರಾರಂಭಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಕಂಟೇನರ್ ಮುನ್ನಡಿ ಬಗ್ಗೆ VPN ನಿಯಮ ಅದಕ್ಕೆ ಅದೇ ರೀತಿ ಅನ್ವಯಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಕೆಲಸದ ಹೊರೆ ಜಾಲವನ್ನು ತಲುಪುತ್ತಲೇ ಇರುತ್ತದೆ.
ಈ ವ್ಯತ್ಯಾಸವೇ Linux ಪಾಕವಿಧಾನಗಳು ವರ್ಗಾವಣೆಯಾಗದಿರುವುದಕ್ಕೂ ಕಾರಣ. ತನ್ನದೇ ಸುರಂಗ ಬೇಕಾದ Linux ಕಂಟೇನರ್ಗೆ TUN ಸಾಧನ ಮತ್ತು NET_ADMIN ಸಾಮರ್ಥ್ಯ ನೀಡಲಾಗುತ್ತದೆ. Windows ಕಂಟೇನರ್ಗಳು ಯಾವ ಇಂಟರ್ಫೇಸನ್ನೂ ಸಾಧನವಾಗಿ ಒಡ್ಡುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಆ ಮಾದರಿಗೆ ಆ ಬದಿಯಲ್ಲಿ ಸಮಾನವಿಲ್ಲ.
ಮಾರ್ಗವನ್ನು ಸಾಬೀತುಪಡಿಸಿ, ನಂತರ ವಿನ್ಯಾಸ ಆಯ್ಕೆಮಾಡಿ
ಸಾಕ್ಷ್ಯವನ್ನು ಹೋಸ್ಟ್ನಿಂದ ಸಂಗ್ರಹಿಸಿ, ಕಂಟೇನರ್ನಿಂದ ಅಲ್ಲ, ಏಕೆಂದರೆ ಹುಡುಕಾಟವನ್ನು ಹೋಸ್ಟ್ ಮಾಡುತ್ತದೆ:
docker network inspect nat --format "{{range .IPAM.Config}}{{.Subnet}}{{end}}"
route print -4
Get-NetRoute -AddressFamily IPv4 | Where-Object DestinationPrefix -like "172.16.*"VPN ಸಂಪರ್ಕಗೊಳ್ಳುವ ಮೊದಲು ಒಮ್ಮೆ ಮತ್ತು ನಂತರ ಒಮ್ಮೆ ಮಾರ್ಗ ಔಟ್ಪುಟ್ ಚಲಾಯಿಸಿ. ಎರಡನೇ ಔಟ್ಪುಟ್ನಲ್ಲಿ ಕಂಟೇನರ್ ಮುನ್ನಡಿ ಸುರಂಗ ಅಡಾಪ್ಟರ್ನತ್ತ ತೋರಿಸಿದರೆ, ರೋಗನಿರ್ಣಯ ಪೂರ್ಣಗೊಂಡಿದೆ ಮತ್ತು ಕಂಟೇನರ್ಗಳನ್ನು ಮರುಪ್ರಾರಂಭಿಸುವುದರಿಂದ ಪ್ರಯೋಜನವಿಲ್ಲ.
ಮೊದಲ ಆಯ್ಕೆ ನೀತಿಯ ನಿರ್ಧಾರ: ಈ ಸಾಧನಕ್ಕೆ ಸ್ಥಳೀಯ LAN ಪ್ರವೇಶವನ್ನು ಅನುಮತಿಸಬಹುದೇ ಎಂದು ಜಾಲದ ಮಾಲೀಕರನ್ನು ಕೇಳಿ. ಹಲವು ಸಾಂಸ್ಥಿಕ ಕ್ಲೈಂಟ್ಗಳು ಅದನ್ನು ಸೆಟ್ಟಿಂಗ್ ಆಗಿ ಒದಗಿಸುತ್ತವೆ, ಆದರೆ ಅದು ಉದ್ದೇಶಪೂರ್ವಕ ಗಡಿಯನ್ನು ದುರ್ಬಲಗೊಳಿಸುತ್ತದೆ. ಮಾಲೀಕ ಮತ್ತು ಪರಿಶೀಲನಾ ದಿನಾಂಕದೊಂದಿಗೆ ದಾಖಲಿತ ವಿನಾಯಿತಿಯಾಗಿ ಕೇಳಿ. ಯಾರೂ ಮತ್ತೆ ನೋಡದ ಪ್ರತಿ ಸಾಧನದ ಟೋಗಲ್ ರಕ್ಷಣಾತ್ಮಕ ನೀತಿ ಮೌನವಾಗಿ ಮಾಯವಾಗುವ ದಾರಿ.
ನೀತಿ ಉಳಿಯಬೇಕಾದಲ್ಲಿ, ಮಾರ್ಗದೊಂದಿಗೆ ಹೋರಾಡುವ ಬದಲು ಕೆಲಸದ ಹೊರೆಯನ್ನು ಸರಿಸಿ. ಸ್ಪಷ್ಟ ಉಪಜಾಲ ಮತ್ತು ಗೇಟ್ವೇ ಇರುವ ಪಾರದರ್ಶಕ ಜಾಲವು ಕಂಟೇನರ್ಗಳನ್ನು ಸ್ಥಳೀಯ ಕೊಂಡಿಗೆ ಇಡುತ್ತದೆ, Linux ಕೆಲಸದ ಹೊರೆ VM ಪ್ರಾಕ್ಸಿಯ ಹಿಂದೆ ಚಲಿಸುತ್ತದೆ, ಮತ್ತು ತನ್ನದೇ ಕ್ಲೈಂಟ್ ಇರುವ ಪ್ರತ್ಯೇಕ ವರ್ಚುವಲ್ ಯಂತ್ರ ತನ್ನದೇ ನೀತಿಯನ್ನು ಉಳಿಸಿಕೊಳ್ಳುತ್ತದೆ. ಒಂದನ್ನು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಆಯ್ಕೆಮಾಡಿ ಮತ್ತು ಕಂಟೇನರ್ನ ಒಳಗಿನಿಂದ ಪರೀಕ್ಷಿಸಿ, ಏಕೆಂದರೆ ಬಳಕೆದಾರರ ವಿನಂತಿ ಅಲ್ಲಿಯೇ ಹುಟ್ಟುತ್ತದೆ.