ಹೋಸ್ಟ್ ಸುರಂಗದ ಮೂಲಕ ಬ್ರೌಸ್ ಮಾಡುತ್ತದೆ, ಪಕ್ಕದ ಕಂಟೇನರ್ ಏನನ್ನೂ ತಲುಪುವುದಿಲ್ಲ. ತನ್ನದೇ VPN ಕ್ಲೈಂಟ್ ಚಲಾಯಿಸುವ ಕಂಟೇನರ್ನಿಂದ ಪೋರ್ಟ್ ಪ್ರಕಟಿಸುವುದು ಇನ್ನೂ ಕೆಟ್ಟದು: ವಿನಂತಿ ಬರುತ್ತದೆ ಮತ್ತು ಉತ್ತರ ಎಂದಿಗೂ ಹೊರಹೋಗುವುದಿಲ್ಲ. ಎರಡೂ ಹೋಸ್ಟ್ನಲ್ಲಿ ಮಾರ್ಗನಿರ್ಣಯದ ನಿರ್ಧಾರಗಳು, ಮತ್ತು Docker ಕೇವಲ ಸಂದೇಶವಾಹಕ.

ನೀವು ಎರಡರಲ್ಲಿ ಯಾವ ಸಂದರ್ಭ ನೋಡುತ್ತಿದ್ದೀರಿ ಎಂಬುದನ್ನು ಮೂರು ಪ್ರಶ್ನೆಗಳು ನಿರ್ಧರಿಸುತ್ತವೆ, ಮತ್ತು ಅದಕ್ಕೆ ಸುಮಾರು ಒಂದು ನಿಮಿಷ ಬೇಕು.

ಒಂದೇ ರೀತಿ ಕಾಣುವ ಎರಡು ವೈಫಲ್ಯಗಳು

ಮೊದಲನೆಯದು ಹಿಂತಿರುಗುವ ಮಾರ್ಗದ ಸಮಸ್ಯೆ. ಪ್ರಕಟಿತ ಪೋರ್ಟ್ ಕಂಟೇನರ್ಗೆ ಅನುವಾದಗೊಳ್ಳುತ್ತದೆ, ವಿನಂತಿ ಬರುತ್ತದೆ, ಮತ್ತು ಉತ್ತರವನ್ನು ಹೋಸ್ಟ್ನ ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗದ ಮೂಲಕ ಕಳುಹಿಸಲಾಗುತ್ತದೆ, ಅದನ್ನು OpenVPN ಕ್ಲೈಂಟ್ tun0 ಕಡೆಗೆ ತಿರುಗಿಸಿದೆ. ಉತ್ತರವು ದೂರದ ಪೀರ್ ನಿರೀಕ್ಷಿಸದ ವಿಳಾಸದಿಂದ ಹೊರಬರುತ್ತದೆ, ಮತ್ತು ಅದನ್ನು ಬಿಟ್ಟುಬಿಡಲಾಗುತ್ತದೆ. ಎರಡನೆಯದು ಪೂರ್ವಪದ ಘರ್ಷಣೆ: Docker ನ ಡೀಫಾಲ್ಟ್ ಸೇತುವೆ 172.17.0.0/16 ಹೊಂದಿದೆ ಮತ್ತು ಕಾರ್ಪೊರೇಟ್ ಸುರಂಗ ಅದೇ ಶ್ರೇಣಿಯನ್ನು ತಳ್ಳುತ್ತದೆ.

ಒಂದನ್ನು ಮಾರ್ಗ ಕೋಷ್ಟಕದಿಂದ ಸರಿಪಡಿಸಲಾಗುತ್ತದೆ, ಇನ್ನೊಂದನ್ನು ಸೇತುವೆಯನ್ನು ಮರುಸಂಖ್ಯೆ ಮಾಡುವ ಮೂಲಕ. ಯಾವುದು ಯಾವುದೆಂದು ತಿಳಿಯುವ ಮೊದಲು ಸಂಪಾದಿಸುವುದು ಕೆಲಸ ಮಾಡುತ್ತಿರುವ ಕಂಟೇನರ್ ಒಡೆಯುವ ದಾರಿ.

ಮೂರು ಪ್ರಶ್ನೆಗಳಿಂದ ನಿರ್ಧರಿಸಿ

ಪ್ರಶ್ನೆ ಒಂದು: VPN ನಿಲ್ಲಿಸಿದಾಗ ವೈಫಲ್ಯ ಮಾಯವಾಗುತ್ತದೆಯೇ? ಸುರಂಗ ಆಫ್ ಇರುವಾಗ ಎಲ್ಲವೂ ಕೆಲಸ ಮಾಡಿದರೆ, ಹಿಂತಿರುಗುವ ಮಾರ್ಗವನ್ನು ಸಂಶಯಿಸಿ. ಪ್ರಶ್ನೆ ಎರಡು: ip route show table all ಅದೇ ಪೂರ್ವಪದವನ್ನು ಎರಡು ಬಾರಿ ಪಟ್ಟಿ ಮಾಡುತ್ತದೆಯೇ, ಒಮ್ಮೆ ಸೇತುವೆಯಲ್ಲಿ ಮತ್ತು ಒಮ್ಮೆ tun0 ನಲ್ಲಿ? ಅದೇ ಘರ್ಷಣೆ. ಪ್ರಶ್ನೆ ಮೂರು: ಬಾಧಿತ ವಿಳಾಸ ಕಂಟೇನರ್, NAT ಅತಿಥಿ ಅಥವಾ ಸೇತುವೆ ಮಾಡಿದ ಅತಿಥಿ?

ಮೂರನೆಯ ಪ್ರಶ್ನೆ ಮುಖ್ಯ ಏಕೆಂದರೆ ಪ್ರತಿಯೊಂದಕ್ಕೂ ಬೇರೆ ಸರಿಯಾದ ಪರಿಹಾರ ಇದೆ, ಮತ್ತು ಕಂಟೇನರ್ ಪರಿಹಾರವನ್ನು libvirt ಅತಿಥಿಗೆ ಅನ್ವಯಿಸುವುದು ಒಂದು ಸಂಜೆ ವ್ಯರ್ಥ ಮಾಡುತ್ತದೆ.

ip route
ip route show table all | grep -E '172\.1[7-9]|10\.8'
docker network inspect bridge --format '{{.IPAM.Config}}'

ಹಿಂತಿರುಗುವ ಮಾರ್ಗ: ಒಂದು ಮೂಲ ವಿಳಾಸಕ್ಕೆ ಕೋಷ್ಟಕ

ಕಂಟೇನರ್ನ ಸಂಚಾರ ಭೌತಿಕ ಇಂಟರ್ಫೇಸ್ ಮೂಲಕ ಹೊರಹೋಗಬೇಕಾದರೆ ಮತ್ತು ಹೋಸ್ಟ್ ಸ್ವತಃ ಸುರಂಗ ಬಳಸುತ್ತಿದ್ದರೆ, ಮೂಲ ಆಧಾರಿತ ಮಾರ್ಗನಿರ್ಣಯ ಅತ್ಯಂತ ಚಿಕ್ಕ ಬದಲಾವಣೆ. ಕಂಟೇನರ್ ವಿಳಾಸಕ್ಕೆ ಹೊಂದುವ ನಿಯಮ ಸೇರಿಸಿ ಮತ್ತು ಅದನ್ನು ಮೀಸಲಾದ ಕೋಷ್ಟಕಕ್ಕೆ ಕಳುಹಿಸಿ. ಹೋಸ್ಟ್ನಲ್ಲಿ ಬೇರೆ ಏನೂ ಚಲಿಸುವುದಿಲ್ಲ.

ip rule add from 172.22.0.3 lookup 10
ip route add default via 172.22.0.1 table 10

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

ಇದರಿಂದ ಪರಿಶೀಲಿಸಿ: ip route get 1.1.1.1 from 172.22.0.3. ಉತ್ತರದಲ್ಲಿ ಸೇತುವೆಯ ಇಂಟರ್ಫೇಸ್ ಇರಬೇಕು, tun0 ಅಲ್ಲ. ಈ ರೀತಿ ಸೇರಿಸಿದ ನಿಯಮಗಳು ರೀಬೂಟ್ನಲ್ಲಿ ಮಾಯವಾಗುತ್ತವೆ, ಆದ್ದರಿಂದ ಅವನ್ನು ಕಂಟೇನರ್ ಹೊಂದಿರುವ unit ಅಥವಾ ನೆಟ್ವರ್ಕ್ ಹುಕ್ನಲ್ಲಿ ಇರಿಸಿ.

ಅದೇ ಮಾದರಿ WireGuard ಕಂಟೇನರ್ಗೂ ಕೆಲಸ ಮಾಡುತ್ತದೆ, ಅಲ್ಲಿ ಉತ್ತರದ ಮಾರ್ಗಕ್ಕೂ ಸ್ಪಷ್ಟ ನಿಯಮ ಬೇಕು.

ಪೂರ್ವಪದ ಘರ್ಷಣೆ: ಸೇತುವೆಯನ್ನು ಮರುಸಂಖ್ಯೆ ಮಾಡಿ

ಮಾರ್ಗ ಕೋಷ್ಟಕ ಒಂದು ಪೂರ್ವಪದವನ್ನು ಒಂದೇ ಸ್ಥಳಕ್ಕೆ ಕಳುಹಿಸುತ್ತದೆ. VPN 172.17.0.0/16 ತಳ್ಳುತ್ತಿದ್ದರೆ ಮತ್ತು Docker ನ ಸೇತುವೆ ಈಗಾಗಲೇ ಅಲ್ಲಿದ್ದರೆ, ಕಡಿಮೆ ಮೆಟ್ರಿಕ್ ಗೆಲ್ಲುತ್ತದೆ: Docker ತನ್ನ ಸಂಪರ್ಕಿತ ಮಾರ್ಗವನ್ನು ಮೆಟ್ರಿಕ್ 0 ನಲ್ಲಿ ಇಡುತ್ತದೆ, ಮತ್ತು ತಳ್ಳಲಾದ ಮಾರ್ಗ 50 ನಲ್ಲಿ ಬರುತ್ತದೆ. ಆಗ Docker ಕೆಲಸ ಮಾಡುತ್ತಿರುವಾಗಲೇ ಸುರಂಗ ಮುರಿದಂತೆ ಕಾಣುತ್ತದೆ, ಅಥವಾ ವಿರುದ್ಧವಾಗಿ, ಸ್ಥಾಪನೆ ಕ್ರಮವನ್ನು ಅವಲಂಬಿಸಿ. ಮೆಟ್ರಿಕ್ನೊಂದಿಗೆ ಹೋರಾಡುವ ಬದಲು ಸೇತುವೆಯನ್ನು ಮರುಸಂಖ್ಯೆ ಮಾಡಿ.

{
  "bip": "10.200.0.1/24",
  "default-address-pools": [{"base": "10.201.0.0/16", "size": 24}]
}

ಬದಲಾವಣೆಯ ನಂತರ Docker ಅನ್ನು ಮರುಪ್ರಾರಂಭಿಸಿ ಮತ್ತು ಹಳೆಯ ಪೂಲ್ನಿಂದ ನಿರ್ಮಿಸಿದ ನೆಟ್ವರ್ಕ್ಗಳನ್ನು ಮತ್ತೆ ರಚಿಸಿ. ಬದಲಿಗೆ ಮೆಟ್ರಿಕ್ ಬದಲಾಯಿಸುವುದು ಘರ್ಷಣೆಯನ್ನು ಮುಂದಿನ ಬೂಟ್ಗೆ ಸರಿಸುತ್ತದೆ ಮಾತ್ರ.

VM ಗಳಿಗೆ ಮತ್ತೆ ಬೇರೆ ಉತ್ತರ ಬೇಕು

ಡೀಫಾಲ್ಟ್ NAT ನೆಟ್ವರ್ಕ್ನಲ್ಲಿರುವ libvirt ಅತಿಥಿ ಹೋಸ್ಟ್ನ ಮಾರ್ಗನಿರ್ಣಯವನ್ನು ಆನುವಂಶಿಕವಾಗಿ ಪಡೆಯುತ್ತದೆ ಮತ್ತು ಹೋಸ್ಟ್ನ ಸುರಂಗ ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗವನ್ನು ಹೊಂದಿದ ಕ್ಷಣ ಹೊರಗೆ ತಲುಪುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ. ಅತಿಥಿಯನ್ನು ಸೇತುವೆ ಅಥವಾ macvtap ಸಾಧನಕ್ಕೆ ಸರಿಸುವುದು ಅದಕ್ಕೆ ಭೌತಿಕ ನೆಟ್ವರ್ಕ್ನಲ್ಲಿ ತನ್ನದೇ ದಾರಿ ನೀಡುತ್ತದೆ. virt-manager ನಲ್ಲಿ ಹಾರ್ಡ್ವೇರ್ ಸೇರಿಸಿ, Network ಆಯ್ಕೆಮಾಡಿ, ಮೂಲವನ್ನು macvtap ಹೋಸ್ಟ್ ಸಾಧನಕ್ಕೆ ಹೊಂದಿಸಿ, ಮಾದರಿಯಾಗಿ virtio ಇಟ್ಟುಕೊಳ್ಳಿ, ನಂತರ ಹಳೆಯ NAT ಇಂಟರ್ಫೇಸ್ ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಿ.

macvtap ಅತಿಥಿ ಸಾಮಾನ್ಯವಾಗಿ ತನ್ನದೇ ಹೋಸ್ಟ್ ತಲುಪಲಾರದು. ಅದು ದೋಷವಲ್ಲ, ನಿರೀಕ್ಷಿತ ವರ್ತನೆ, ಮತ್ತು ಅದು ನೀವು ಬಿಡುವ ಟಿಪ್ಪಣಿಯಲ್ಲಿ ಇರಬೇಕು.

ಹೋಸ್ಟ್ನ LAN ಮಾತ್ರ ಬೇಕಾದ ಅತಿಥಿಗೆ, ಮಾರಾಟಗಾರನ ಕ್ಲೈಂಟ್ನಲ್ಲಿ ಕಾಣೆಯಾದ ಸ್ವಿಚ್ ಇರಬಹುದು: Mullvad ನೊಂದಿಗೆ mullvad lan set allow libvirt ಮುಟ್ಟದೆ ಸ್ಥಳೀಯ ತಲುಪುವಿಕೆಯನ್ನು ಮರುಸ್ಥಾಪಿಸುತ್ತದೆ. ಮತ್ತು ಕಂಟೇನರ್ ಸುರಂಗದ ಮೂಲಕ ಮಾತ್ರ ತಲುಪಬಹುದಾದರೆ, ಪ್ರಕಟಿತ ಪೋರ್ಟ್ ಅನ್ನು ಸುರಂಗ ವಿಳಾಸಕ್ಕೆ ಬಂಧಿಸಿ, -p 10.8.0.5:8080:8080, ಪ್ರತಿ ವಿಳಾಸದಲ್ಲಿ ಪ್ರಕಟಿಸುವ ಬದಲು.

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