macvlan ಕಂಟೇನರ್ VPN ಕ್ಲೈಂಟ್‌ಗೆ ಉತ್ತರಿಸಲು ಸಾಧ್ಯವಿಲ್ಲದಿರುವುದು ಏಕೆ

VPN ಅನ್ನು ಕೊನೆಗೊಳಿಸುವ ಮತ್ತು ಅದೇ ಸಮಯದಲ್ಲಿ macvlan ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿ ಕಂಟೇನರ್ ಚಲಾಯಿಸುವ Linux ಹೋಸ್ಟ್ ಅನ್ನು ಊಹಿಸಿ. LAN 192.168.60.0/24 ಆಗಿದೆ, ಕಂಟೇನರ್‌ನಲ್ಲಿ 192.168.60.210 ಇದೆ, ಮತ್ತು VPN ಕ್ಲೈಂಟ್‌ಗಳು 10.95.0.0/24 ರಿಂದ ಬರುತ್ತವೆ. ಕ್ಲೈಂಟ್ ಸೇವೆಯನ್ನು ತಲುಪುತ್ತದೆ, ಉತ್ತರ ಎಂದಿಗೂ ಹಿಂತಿರುಗುವುದಿಲ್ಲ, ಮತ್ತು ಹೋಸ್ಟ್‌ನಲ್ಲಿನ ಪ್ರತಿಯೊಂದು ಫೈರ್‌ವಾಲ್ ನಿಯಮವೂ ಸರಿಯಾಗಿ ಕಾಣುತ್ತದೆ. ಎರಡು ಪ್ರತ್ಯೇಕ ನಿರ್ಬಂಧಗಳು ಈ ಲಕ್ಷಣವನ್ನು ಉಂಟುಮಾಡುತ್ತವೆ, ಮತ್ತು ಒಂದನ್ನು ಸರಿಪಡಿಸಿದರೆ ಇನ್ನೊಂದು ತನ್ನ ಸ್ಥಳದಲ್ಲೇ ಉಳಿಯುತ್ತದೆ.

ಎರಡು ನಿರ್ಬಂಧಗಳು, ಒಂದು ಲಕ್ಷಣ

ಮೊದಲ ನಿರ್ಬಂಧ ಪ್ರತ್ಯೇಕತೆ: Docker ನ macvlan ಡ್ರೈವರ್ ಕಂಟೇನರ್‌ಗೆ ಪೋಷಕ ಇಂಟರ್‌ಫೇಸ್ ಮೂಲಕ ತನ್ನದೇ ಹೋಸ್ಟ್‌ನೊಂದಿಗೆ ಮಾತನಾಡಲು ಅನುಮತಿಸುವುದಿಲ್ಲ. ಹೋಸ್ಟ್ ಸ್ಟ್ಯಾಕ್ ಮತ್ತು ಕಂಟೇನರ್ ನಡುವಿನ ಸಂಚಾರಕ್ಕೆ ಯಾವುದೇ ದಾರಿ ಇಲ್ಲ, ಹೋಸ್ಟ್‌ನಲ್ಲಿನ ಮಾರ್ಗಗಳನ್ನು ಹೇಗೆ ಬರೆದರೂ.

ಎರಡನೇ ನಿರ್ಬಂಧ ಹಿಂತಿರುಗುವ ದಾರಿ. ಕಂಟೇನರ್‌ನ ಡಿಫಾಲ್ಟ್ ಗೇಟ್‌ವೇ ಸಾಮಾನ್ಯವಾಗಿ LAN ರೌಟರ್ ಆಗಿರುತ್ತದೆ, ಆದ್ದರಿಂದ VPN ಕ್ಲೈಂಟ್‌ಗೆ ಉದ್ದೇಶಿಸಿದ ಉತ್ತರ ಆ ರೌಟರ್ ಮೂಲಕ ಹೊರಹೋಗುತ್ತದೆ. ರೌಟರ್‌ಗೆ VPN ಪೂಲ್‌ಗೆ ಹಿಂತಿರುಗುವ ಮಾರ್ಗವಿಲ್ಲದಿದ್ದರೆ, ಉತ್ತರವು ನಡುವೆ ಎಲ್ಲೋ ಬಿಡಲ್ಪಡುತ್ತದೆ.

ಈ ಎರಡು ವೈಫಲ್ಯಗಳು ಕ್ಲೈಂಟ್‌ನ ದೃಷ್ಟಿಯಿಂದ ಒಂದೇ ರೀತಿ ಕಾಣುತ್ತವೆ: ಬಂದ ವಿನಂತಿ ಮತ್ತು ಎಂದಿಗೂ ಬಾರದ ಉತ್ತರ. ಅವು ಬೇರೆ ಬೇರೆ ದುರಸ್ತಿ ಬೇಕು, ಮತ್ತು ವಿಶಾಲ masquerade ನಿಯಮವು ಯಾವುದು ಇನ್ನೂ ಮುರಿದಿದೆ ಎಂಬುದನ್ನು ಮರೆಮಾಡಬಹುದು. ಆದ್ದರಿಂದ ಮೊದಲ ಪರೀಕ್ಷೆ ಫೈರ್‌ವಾಲ್‌ನಲ್ಲಿ ಇನ್ನೊಂದು ಬದಲಾವಣೆ ಅಲ್ಲ, ಕಂಟೇನರ್ ಬದಿಯಲ್ಲಿ ಸೆರೆಹಿಡಿಯುವುದು. ವಿನಂತಿ ಅಲ್ಲಿ ಎಂದಿಗೂ ಕಾಣದಿದ್ದರೆ, ಪ್ರತ್ಯೇಕತೆಯ ನಿರ್ಬಂಧವೇ ಕೆಲಸ ಮಾಡುತ್ತಿದೆ.

ಹೋಸ್ಟ್ ಬದಿಯ shim ಅನ್ನು ಸಂಕುಚಿತವಾಗಿ ನಿರ್ಮಿಸಿ

ಅದೇ ಪೋಷಕಕ್ಕೆ ಸೇತುವೆ ಮೋಡ್‌ನಲ್ಲಿ ಜೋಡಿಸಿದ ಎರಡನೇ macvlan ಇಂಟರ್‌ಫೇಸ್ ಹೋಸ್ಟ್ ಸ್ಟ್ಯಾಕ್‌ಗೆ ಆ LAN ವಿಭಾಗದಲ್ಲಿ ತನ್ನದೇ ಗುರುತನ್ನು ನೀಡುತ್ತದೆ. ಅದಕ್ಕಾಗಿ DHCP ಪೂಲ್‌ನ ಹೊರಗೆ ಮತ್ತು ಕಂಟೇನರ್ ಶ್ರೇಣಿಯ ಹೊರಗೆ ವಿಳಾಸವನ್ನು ಕಾಯ್ದಿರಿಸಿ, ಮತ್ತು ಕಂಟೇನರ್ ಅನ್ನು ಮಾತ್ರ ಅದರ ಮೂಲಕ ರವಾನಿಸಿ.

ip link add macvlan-vpn link eth0 type macvlan mode bridge
ip address add 192.168.60.250/32 dev macvlan-vpn
ip link set macvlan-vpn up
ip route add 192.168.60.210/32 dev macvlan-vpn src 192.168.60.250

ಮೊದಲ ಆದೇಶ ಇಂಟರ್‌ಫೇಸ್ ಅನ್ನು ಸೇತುವೆ ಮೋಡ್‌ನಲ್ಲಿ ರಚಿಸುತ್ತದೆ, ಇದು ಈ ಡ್ರೈವರ್‌ಗೆ ದಾಖಲಿತ ಡಿಫಾಲ್ಟ್ ಮತ್ತು ಹೋಸ್ಟ್-ಕಂಟೇನರ್ ಸಂಚಾರಕ್ಕೆ ನೀವು ಬಯಸುವ ಮೋಡ್. ಎರಡನೆಯದು /32 ನೀಡುತ್ತದೆ, ವಿಳಾಸ LAN ಪೂರ್ವಪ್ರತ್ಯಯದೊಂದಿಗೆ ಘರ್ಷಿಸದಂತೆ, ಮತ್ತು ನಾಲ್ಕನೆಯದು shim ಮೂಲಕ ಕಂಟೇನರ್‌ನ ವಿಳಾಸವನ್ನು ಮಾತ್ರ ಕಳುಹಿಸುತ್ತದೆ.

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

ಈ ಆದೇಶಗಳು ಚಾಲನೆಯಲ್ಲಿರುವ ಹೋಸ್ಟ್‌ನ ನೆಟ್‌ವರ್ಕ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಬದಲಾಯಿಸುತ್ತವೆ. ಸಾಧನ ಅಥವಾ ನಿರ್ವಹಿತ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ನಲ್ಲಿ ಆ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಬೆಂಬಲಿಸುವ ಸಂರಚನಾ ವಿಧಾನವನ್ನು ಬಳಸಿ, ಏಕೆಂದರೆ root-shell ನಲ್ಲಿ ಮಾಡಿದ ಸಂವಾದಾತ್ಮಕ ಬದಲಾವಣೆ ನವೀಕರಣದ ನಂತರ ಉಳಿಯದೇ ಇರಬಹುದು.

ಮೂಲವನ್ನು ಹೇಗೆ ಸಂರಕ್ಷಿಸುವುದೆಂದು ನಿರ್ಧರಿಸಿ

shim ಇದ್ದಾಗ ಕಂಟೇನರ್ ಹೋಸ್ಟ್ ಅನ್ನು ತಲುಪಬಹುದು, ಮತ್ತು ಉತ್ತರ ಯಾವ ಮೂಲ ವಿಳಾಸವನ್ನು ಹೊತ್ತೊಯ್ಯುತ್ತದೆ ಎಂಬುದು ಪ್ರಶ್ನೆಯಾಗುತ್ತದೆ. ಮೂಲ VPN ಮೂಲವನ್ನು ಸಂರಕ್ಷಿಸುವುದು ಸ್ವಚ್ಛವಾದ ಮಾದರಿ: ಕಂಟೇನರ್ ಕ್ಲೈಂಟ್‌ನ ನಿಜವಾದ ವಿಳಾಸವನ್ನು ನೋಡುತ್ತದೆ, ಮತ್ತು ಸೇವೆಯ ಲಾಗ್‌ಗಳು ಹಾಗೂ ಪ್ರವೇಶ ನಿಯಮಗಳು ಅದನ್ನು ಬಳಸಬಹುದು.

ಅದು ಕೆಲಸ ಮಾಡಲು ಕಂಟೇನರ್‌ನ ನೆಟ್‌ವರ್ಕ್ ಸಂರಚನೆ ಈ ಮಾರ್ಗಕ್ಕಾಗಿ 10.95.0.0/24 ನ ಸಂಚಾರವನ್ನು 192.168.60.250 ಗೆ ತನ್ನ ಗೇಟ್‌ವೇ ಆಗಿ ಕಳುಹಿಸಬೇಕು. ಇದು ಕಂಟೇನರ್‌ನ ಸ್ವಂತ ಸಂರಚನೆಯೊಳಗಿನ ಬೆಂಬಲಿತ ಮಾರ್ಗ ಅಥವಾ ಗೇಟ್‌ವೇ ಸೆಟ್ಟಿಂಗ್, ಹೋಸ್ಟ್ ಬದಿಯ ಉಪಾಯವಲ್ಲ. ಸೆಟ್ಟಿಂಗ್ ಜಾರಿಗೆ ಬಂದಿದೆ ಎಂದು ಊಹಿಸುವ ಬದಲು ಕಂಟೇನರ್‌ನ ಒಳಗಿನಿಂದ ಅದನ್ನು ದೃಢೀಕರಿಸಿ. ಇನ್ನೂ LAN ರೌಟರ್ ಕಡೆಗೆ ತೋರಿಸುವ ಡಿಫಾಲ್ಟ್ ಗೇಟ್‌ವೇ ಉತ್ತರಗಳನ್ನು ಅದೇ ರಂಧ್ರಕ್ಕೆ ಕಳುಹಿಸುತ್ತಲೇ ಇರುತ್ತದೆ.

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

iptables -t nat -A POSTROUTING -s 10.95.0.0/24 -o macvlan-vpn -j SNAT --to-source 192.168.60.250

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

ಕ್ಲೈಂಟ್‌ನಿಂದ ಪರಿಶೀಲಿಸಿ, ಹೋಸ್ಟ್‌ನಿಂದ ಅಲ್ಲ

ಹೋಸ್ಟ್‌ನಿಂದಲೇ shim ವಿಳಾಸಕ್ಕೆ ಬದ್ಧವಾದ ವಿನಂತಿ shim ಕಂಟೇನರ್ ಅನ್ನು ತಲುಪಬಲ್ಲದು ಎಂದು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ. ಆದರೆ ಕಂಟೇನರ್ ಸಂರಕ್ಷಿತ 10.95.0.x ಮೂಲಕ್ಕೆ ಸಂಚಾರವನ್ನು ಹಿಂತಿರುಗಿಸಬಲ್ಲದು ಎಂದು ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಆ ಪರೀಕ್ಷೆಯಲ್ಲಿ ಮೂಲ ವಿಳಾಸ shim ನದೇ ಆಗಿದೆ.

curl -sS --interface 192.168.60.250 -o /dev/null -w '%{http_code}\n' http://192.168.60.210:8080/health
sudo tcpdump -ni macvlan-vpn host 192.168.60.210

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

ಹೋಸ್ಟ್‌ನಲ್ಲಿ ಮುಂದುಗಡೆ ರವಾನೆ ಸಕ್ರಿಯವಾಗಿರಬೇಕು, ಮತ್ತು ರವಾನೆ ಮಾರ್ಗಕ್ಕೆ ಸೇವಾ ಪೋರ್ಟ್‌ನಲ್ಲಿ VPN ಪೂಲ್‌ನಿಂದ shim ಕಡೆಗೆ ಅನುಮತಿ ಜೊತೆಗೆ ಸ್ಥಾಪಿತ ಉತ್ತರಗಳಿಗೆ ಅನುಮತಿ ಬೇಕು. ಹೋಸ್ಟ್‌ನ INPUT ನಿಯಮ ರವಾನೆಯಾದ ಸಂಚಾರವನ್ನು ಅಧಿಕೃತಗೊಳಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಮಾರ್ಗನಿರ್ದೇಶನ ಸರಿಯಾಗಿ ಕಂಡ ನಂತರ ಪ್ಯಾಕೆಟ್ ಬಿಡಲ್ಪಡುವುದಕ್ಕೆ ಇದು ಸಾಮಾನ್ಯ ಕಾರಣ.

ನಿಜವಾದ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ನಿಜವಾದ ರುಜುವಾತುಗಳೊಂದಿಗೆ ಚಲಾಯಿಸಿ, ನಂತರ ಅದೇ ಕಂಟೇನರ್‌ನಲ್ಲಿರುವ ಎರಡನೇ, ಸಂಬಂಧವಿಲ್ಲದ ಸೇವೆ ಇನ್ನೂ ನಿಮ್ಮನ್ನು ನಿರಾಕರಿಸುತ್ತದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ. ಅದನ್ನು ಕೆಲಸ ಮಾಡಿಸುವ ಏಕೈಕ ದಾರಿ ಎಲ್ಲಾ ರವಾನೆ ನಿಯಮಗಳನ್ನು ತೆರೆಯುವುದಾಗಿದ್ದರೆ, ವಿನ್ಯಾಸ ಪೂರ್ಣಗೊಂಡಿಲ್ಲ. ಸೇವೆ ಯಾವ ಮೂಲ ವಿಳಾಸವನ್ನು ದಾಖಲಿಸಿತು ಎಂಬುದನ್ನೂ ಗಮನಿಸಿ, ಏಕೆಂದರೆ ಇನ್ನು ಮುಂದೆ ಅದರ ಸ್ವಂತ ಪ್ರವೇಶ ನಿಯಮಗಳು ಅದನ್ನೇ ಬಳಸುತ್ತವೆ.