Kubernetes ನಲ್ಲಿ VPN ಕ್ಲೈಂಟ್ IP: ಅದನ್ನು ರಕ್ಷಿಸುವುದೋ ಅಥವಾ SNAT ಮಾಡುವುದೋ?
Kubernetes ನಲ್ಲಿ VPN ಕ್ಲೈಂಟ್‌ನ ನಿಜವಾದ ವಿಳಾಸ ಮತ್ತು ಮೂಲ NAT ನಡುವೆ ಮೂರು ಷರತ್ತುಗಳ ಆಧಾರದ ಮೇಲೆ ಆಯ್ಕೆಮಾಡಿ, ನಂತರ ಹಿಂತಿರುಗುವ ಮಾರ್ಗ ಮತ್ತು pod ಬದಲಾವಣೆಯನ್ನು ಪರಿಶೀಲಿಸಿ.
ಎಲ್ಲೋ ಸುರಂಗ ಮತ್ತು backend ನಡುವೆ ಕ್ಲೈಂಟ್ ವಿಳಾಸವು ಒಂದೋ ಉಳಿಯುತ್ತದೆ ಅಥವಾ ಬದಲಾಗುತ್ತದೆ, ಮತ್ತು ಎರಡೂ ಫಲಿತಾಂಶಗಳು ಸಮರ್ಥನೀಯ. ಆಯ್ಕೆ ಸ್ವೀಕರಿಸುವ ಸೇವೆಯ ಮಾಲೀಕರಿಗೆ ಸೇರಿದ್ದು, CNI ಸ್ಥಾಪಿಸಿದವರಿಗಲ್ಲ. ಪ್ರತಿ ಕ್ಲೈಂಟ್ ಅಧಿಕಾರ, ಕೋಟಾಗಳು ಅಥವಾ ಆಡಿಟ್ ದಾಖಲೆಗಳು ಮುಖ್ಯವಾದಾಗ, ವಿಳಾಸವು ಪ್ರತಿ ಹಾಪ್ ದಾಟಬೇಕು. ಹಂಚಿದ ಆರೋಪಣೆ ಸ್ವೀಕಾರಾರ್ಹವಾದಾಗ, ಮೂಲ NAT ನೀವು ಇಲ್ಲದಿದ್ದರೆ ಶಾಶ್ವತವಾಗಿ ನಿರ್ವಹಿಸಬೇಕಾದ ರೂಟಿಂಗ್ ಸಮಸ್ಯೆಯನ್ನು ತೆಗೆದುಹಾಕುತ್ತದೆ.
ವಿಳಾಸ ನಿಜವಾಗಿ ಎಲ್ಲಿ ಮಾಯವಾಗುತ್ತದೆ
ದೂರದ ಕ್ಲೈಂಟ್‌ನ ಪ್ಯಾಕೆಟ್ VPN pod ಗೆ ಸುರಂಗ ಶ್ರೇಣಿಯೊಳಗಿನ ಆಂತರಿಕ ಮೂಲದೊಂದಿಗೆ ತಲುಪುತ್ತದೆ, ಹೇಳಿಕೊಳ್ಳೋಣ 10.90.0.42. pod ಆ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ClusterIP ಅಥವಾ pod IP ಕಡೆಗೆ ಕಳುಹಿಸಿದಾಗ, ಮೂರು ವಿಭಿನ್ನ ಕಾರ್ಯವಿಧಾನಗಳು ಮೂಲವನ್ನು ಮತ್ತೆ ಬರೆಯಬಹುದು. node ನ CNI masquerade ನಿಯಮವು pod ಕ್ಲಸ್ಟರ್ CIDR ನ ಹೊರಗೆ ಕಳುಹಿಸುವ ಸಂಚಾರವನ್ನು ಆವರಿಸುತ್ತದೆ. ಗಮ್ಯಸ್ಥಾನ node ನಲ್ಲಿ kube-proxy ಯ conntrack ನಮೂದು ಸ್ವತಃ Service ಹಾಪ್ ಅನ್ನು ಆವರಿಸುತ್ತದೆ. ಸಂಪರ್ಕವನ್ನು ಕೊನೆಗೊಳಿಸುವ ಪ್ರಾಕ್ಸಿ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಕಳುಹಿಸುವುದೇ ಇಲ್ಲ, ಆದ್ದರಿಂದ ಕೊನೆಗೆ ನೀವು ನೋಡುವ ಮೂಲವು ಪ್ರಾಕ್ಸಿಗೆ ಸೇರಿದ್ದು.
ಅವುಗಳಲ್ಲಿ ಪ್ರತಿಯೊಂದೂ ಬೇರೆ ಪದರದಲ್ಲಿ ವಾಸಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಒಂದು Service ಕ್ಷೇತ್ರವು ಬಹುತೇಕ ಎಂದಿಗೂ ಇಡೀ ಮಾರ್ಗವನ್ನು ಸರಿಪಡಿಸುವುದಿಲ್ಲ.
VPN ನ ಸಾರ್ವಜನಿಕ Service ನಲ್ಲಿ externalTrafficPolicy ಬಾಹ್ಯ ಸಂಪರ್ಕದ ಬಗ್ಗೆ ಮಾತ್ರ ನಿರ್ಧರಿಸುತ್ತದೆ: Local ದೂರದ ವಿಳಾಸವನ್ನು ಅದನ್ನು ಸ್ವೀಕರಿಸಿದ node ನಲ್ಲಿ ಇಡುತ್ತದೆ, Cluster kube-proxy ಗೆ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಇನ್ನೊಂದು node ಗೆ ನೀಡಿ ಅಲ್ಲಿ masquerade ಮಾಡಲು ಅನುಮತಿಸುತ್ತದೆ. ಆ ಸೆಟ್ಟಿಂಗ್ ನಿಮ್ಮ ಕ್ಲೈಂಟ್‌ಗಳು ಸಂಪರ್ಕಿಸುವ listener ಅನ್ನು ನಿಯಂತ್ರಿಸುತ್ತದೆ. ನಿಮ್ಮ VPN ಪ್ರಕ್ರಿಯೆ ನಂತರ ಕ್ಲಸ್ಟರ್‌ಗೆ ಕಳುಹಿಸುವ ಡೀಕ್ರಿಪ್ಟ್ ಆದ ಪ್ಯಾಕೆಟ್ ಬಗ್ಗೆ ಅದು ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ.
ವಾದವನ್ನು ತೀರ್ಮಾನಿಸುವ ಮೂರು ಷರತ್ತುಗಳು
ಈ ವಿಷಯ ಬಂದಾಗಲೆಲ್ಲಾ ಅದೇ ಮೂರು ಪ್ರಶ್ನೆಗಳನ್ನು ಅದೇ ಕ್ರಮದಲ್ಲಿ ಕೇಳುತ್ತೇನೆ, ಏಕೆಂದರೆ ಮೊದಲನೆಯದು ಸಾಮಾನ್ಯವಾಗಿ ಚರ್ಚೆಯನ್ನು ಮುಗಿಸುತ್ತದೆ. ನಿರ್ದಿಷ್ಟ ಕೆಲಸದ ಭಾರಕ್ಕೆ ಉತ್ತರಿಸಿ, ಇಡೀ ಕ್ಲಸ್ಟರ್‌ಗೆ ಅಲ್ಲ. ಒಂದೇ ಕಂಪನಿಯೊಳಗಿನ ಎರಡು ಕ್ಲಸ್ಟರ್‌ಗಳು ವಿಭಿನ್ನ ಉತ್ತರಗಳನ್ನು ತಲುಪಬಹುದು ಮತ್ತು ಎರಡೂ ಸರಿಯಾಗಿರಬಹುದು.
| Question | Preserve | SNAT |
|---|---|---|
| Does the backend enforce policy per client? | Yes, the address is the identity | Only if a trusted proxy supplies identity |
| Can the cluster route 10.90.0.0/24 back to a stable gateway? | Required | Not needed |
| Is the workload a forwarder or a proxy? | Forwarder | Proxy is fine |
backend ಮೊದಲ ಪ್ರಶ್ನೆಗೆ ಹೌದು ಮತ್ತು ಎರಡನೆಯದಕ್ಕೆ ಇಲ್ಲ ಎಂದು ಉತ್ತರಿಸಿದರೆ, ನಿಮಗೆ ನೆಟ್ವರ್ಕ್ ಕೆಲಸವಿದೆ, manifest ಸಂಪಾದನೆಯಲ್ಲ. ಮೂರನೆಯ ಸಾಲು ಪ್ರಾಕ್ಸಿ ಎಂದು ಹೇಳಿದರೆ, ವಿಳಾಸವು ಎಂದಿಗೂ ಉಳಿಯುತ್ತಿರಲಿಲ್ಲ, ಮತ್ತು ವಿರುದ್ಧವಾಗಿ ಹೇಳುವುದು ಒಂದು ವಾರದ ಪ್ಯಾಕೆಟ್ ಸೆರೆಹಿಡಿಯುವಿಕೆಯ ವೆಚ್ಚ.
preserve ಮೋಡ್ ನೆಟ್ವರ್ಕ್‌ನಿಂದ ಏನನ್ನು ಕೇಳುತ್ತದೆ
ಮೂಲವನ್ನು ರಕ್ಷಿಸುವುದು ಎಂದರೆ ಗಮ್ಯಸ್ಥಾನ node ಸಂಚಾರವನ್ನು ಸಕ್ರಿಯ VPN ಗೇಟ್ವೇ ಮೂಲಕ 10.90.0.42 ಗೆ ಹಿಂತಿರುಗಿಸಬೇಕು. VPN ಪೂಲ್ ಕ್ಲಸ್ಟರ್ CIDR ಅಲ್ಲ, ಆದ್ದರಿಂದ ಯಾವುದೇ CNI ಅದನ್ನು ನಿಮಗಾಗಿ ಡೀಫಾಲ್ಟ್ ಆಗಿ ರೂಟ್ ಮಾಡುವುದಿಲ್ಲ. ನೀವೇ ಮಾರ್ಗವನ್ನು ಸೇರಿಸಿ, ನಂತರ ಅದು ಸೂಚಿಸುವ ಗೇಟ್ವೇ ಅಂತ್ಯಬಿಂದುವು ಮರುನಿಗದಿಯನ್ನು ತಡೆದುಕೊಳ್ಳುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳುತ್ತೀರಿ.
ip route add 10.90.0.0/24 via 10.244.3.17 dev eth0
sysctl -w net.ipv4.conf.eth0.rp_filter=2ಆ ಮುಂದಿನ ಹಾಪ್ pod ವಿಳಾಸ, pod ವಿಳಾಸಗಳು ಚಲಿಸುತ್ತವೆ. ಮಾರ್ಗವನ್ನು Service VIP ಅಥವಾ ಜಾಗದಲ್ಲೇ ಉಳಿಯುವ node ವಿಳಾಸದ ಕಡೆಗೆ ತಿರುಗಿಸಿ, ಅಥವಾ ಪ್ರತಿ ಹೊರಹಾಕುವಿಕೆಯ ನಂತರ ನೀವು ಗೇಟ್ವೇಯನ್ನು ಬೆನ್ನಟ್ಟುತ್ತೀರಿ ಎಂದು ಒಪ್ಪಿಕೊಳ್ಳಿ. ಹಿಮ್ಮುಖ ಮಾರ್ಗದ ಫಿಲ್ಟರಿಂಗ್ ಇನ್ನೊಂದು ಬಲೆ: ಕಟ್ಟುನಿಟ್ಟಿನ ಮೋಡ್, ಬಂದ ಇಂಟರ್ಫೇಸ್‌ಗೆ ಹೊಂದಿಕೆಯಾಗದ ಹಿಂತಿರುಗುವ ಮಾರ್ಗವಿರುವ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಬೀಳಿಸುತ್ತದೆ, ಮತ್ತು ಇದು ಸಂರಕ್ಷಿತ VPN ಹರಿವಿನ ನಿಖರ ರೂಪ.
ಸಡಿಲ ಮಾನ್ಯತೆ ಸಾಮಾನ್ಯವಾಗಿ ಕೆಲಸ ಮಾಡುವ ಹಿಂತಿರುಗುವ ಮಾರ್ಗ ಮತ್ತು backend ಬಿಟ್ಟ ನಂತರ ಮಾಯವಾಗುವ ಉತ್ತರಗಳ ನಡುವಿನ ವ್ಯತ್ಯಾಸ. VPN node ನ masquerade ನಿಯಮಗಳು ಸಹ ಸುರಂಗ ಶ್ರೇಣಿಯನ್ನು ಹೊರಗಿಡಬೇಕು, ಇಲ್ಲದಿದ್ದರೆ ಕಳುಹಿಸಿದ ಪ್ಯಾಕೆಟ್ pod ವಿಳಾಸದೊಂದಿಗೇ ಹೊರಬರುತ್ತದೆ, ನೀವು ಯಾವ ಮಾರ್ಗವನ್ನು ನಿರ್ಮಿಸಿದರೂ. ಈ ಹೊರಗಿಡುವಿಕೆಯನ್ನು iptables ಅನ್ನು ಕೈಯಿಂದ ಸಂಪಾದಿಸುವ ಬದಲು CNI ಯ ಸ್ವಂತ ಸಂರಚನೆಯಲ್ಲಿ ವ್ಯಕ್ತಪಡಿಸಿ, ಏಕೆಂದರೆ ಏಜೆಂಟ್ ಮರುಪ್ರಾರಂಭದಲ್ಲಿ ತನ್ನ ಸರಪಳಿಗಳನ್ನು ಮತ್ತೆ ಬರೆಯುತ್ತದೆ ಮತ್ತು ನಿಮ್ಮ ಕೈಯಿಂದ ಬರೆದ ನಿಯಮವು ಮುಂದಿನ ಅಪ್‌ಗ್ರೇಡ್‌ವರೆಗೆ ಮಾತ್ರ ಉಳಿಯುತ್ತದೆ.
NetworkPolicy ಪ್ರವೇಶ ನಿಯಂತ್ರಣ, ರೂಟಿಂಗ್ ಅಲ್ಲ. ನೀತಿಯನ್ನು ಕಠಿಣಗೊಳಿಸುವುದು masquerade ಈಗಾಗಲೇ ಬದಲಿಸಿರುವ ವಿಳಾಸವನ್ನು ಎಂದಿಗೂ ಮರುಸ್ಥಾಪಿಸುವುದಿಲ್ಲ.
SNAT ನ ವೆಚ್ಚವೇನು, ಮತ್ತು ಅದನ್ನು ಹೇಗೆ ದಾಖಲಿಸುವುದು
ಕ್ಲಸ್ಟರ್ ಕಡೆಗೆ ಮೂಲ NAT ಅಗ್ಗದ ವಿನ್ಯಾಸ, ಮತ್ತು ಅದು ತಪ್ಪಲ್ಲ. backend VPN pod ಅಥವಾ node ವಿಳಾಸವನ್ನು ನೋಡುತ್ತದೆ, ಲಾಗ್‌ಗಳು ಪರಸ್ಪರ ಹೊಂದಿಕೆಯಾಗುತ್ತವೆ, ಮತ್ತು ಹಿಂತಿರುಗುವ ಮಾರ್ಗವು ಇರಬೇಕಿಲ್ಲ. ನೀವು ಕಳೆದುಕೊಳ್ಳುವುದು ನೆಟ್ವರ್ಕ್ ಪದರದಲ್ಲಿ ಇಬ್ಬರು ಕ್ಲೈಂಟ್‌ಗಳನ್ನು ಪ್ರತ್ಯೇಕಿಸುವ ಸಾಮರ್ಥ್ಯ, ಆದ್ದರಿಂದ ಕೋಟಾ, ನಿಷೇಧಗಳು ಮತ್ತು ಆಡಿಟ್ ಕುರುಹುಗಳು ಬೇರೆಲ್ಲಿಂದಲೋ ಬರಬೇಕು.
ಸಾಮಾನ್ಯವಾಗಿ ಆ ಬೇರೆಲ್ಲೋ ಎಂದರೆ ಅಪ್ಲಿಕೇಶನ್: ಸೆಷನ್ ಟೋಕನ್, ಸಹಿ ಮಾಡಿದ ಹೆಡರ್, ಅಥವಾ ನೀವು ನಿಯಂತ್ರಿಸುವ ಪ್ರಾಕ್ಸಿ ಬರೆಯುವ PROXY ಪ್ರೋಟೋಕಾಲ್ ಸಾಲು. ಇವು ಗ್ರಾಹಕನಿಗೆ ಪ್ರಾಕ್ಸಿ ಮಾರ್ಗದಲ್ಲಿರುವಾಗ ಮತ್ತು ಹೆಡರ್ ಅನ್ನು ಕ್ಲೈಂಟ್ ಬದಿಯಿಂದ ಹೊಂದಿಸಲು ಸಾಧ್ಯವಿಲ್ಲದಾಗ ಮಾತ್ರ ನಂಬಬಹುದಾದ ಗುರುತನ್ನು ನೀಡುತ್ತವೆ. runbook ನಲ್ಲಿ ಯಾವುದು ಅನ್ವಯಿಸುತ್ತದೆ ಎಂದು ಸ್ಪಷ್ಟವಾಗಿ ಹೇಳಿ, ಏಕೆಂದರೆ ಮುಂದಿನ ಎಂಜಿನಿಯರ್ ಲಾಗ್‌ನಲ್ಲಿರುವ ವಿಳಾಸವೇ ಕ್ಲೈಂಟ್ ಎಂದು ಭಾವಿಸುತ್ತಾರೆ. ಹಾಗಲ್ಲ, ಮತ್ತು ಒಂದು ಘಟನೆ ಆ ಊಹೆಯನ್ನು ದುಬಾರಿಯಾಗಿಸಲು ಸಾಕು.
ಈ ವಿನಿಮಯವು ಬರೆದಿರುವವರೆಗೆ ಪ್ರಾಮಾಣಿಕವಾಗಿರುತ್ತದೆ.
ಕೆಲಸ ಮಾಡುವ ಮಾರ್ಗವನ್ನು ಅದೃಷ್ಟದ ಮಾರ್ಗದಿಂದ ಬೇರ್ಪಡಿಸುವ ಪರಿಶೀಲನೆಗಳು
ತಾಜಾ ಸಂಪರ್ಕದೊಂದಿಗೆ ಪರೀಕ್ಷಿಸಿ, ಕ್ಯಾಶ್ ಮಾಡಿದ ಸಂಪರ್ಕದೊಂದಿಗೆ ಅಲ್ಲ, ಮತ್ತು ಎರಡೂ ದಿಕ್ಕುಗಳಲ್ಲಿ ಪರೀಕ್ಷಿಸಿ. ಹಲವು ವೈಫಲ್ಯಗಳು ಮಾತ್ರ ಮಧ್ಯಂತರವೆಂದು ತೋರುವುದು ಹೊಸ ಹರಿವುಗಳು ಮರುಬರೆದ ಮಾರ್ಗವನ್ನು ತೆಗೆದುಕೊಳ್ಳುವುದರಿಂದ.
ಒಂದು ಅಧಿಕೃತ ವಿನಂತಿಯ ಸಮಯದಲ್ಲಿ tuple ಅನ್ನು ಮೂರು ಸ್ಥಳಗಳಲ್ಲಿ ಹಿಡಿಯಿರಿ: ಡೀಕ್ರಿಪ್ಶನ್ ನಂತರ ತಕ್ಷಣ, VPN pod ನ ನಿರ್ಗಮನ ಇಂಟರ್ಫೇಸ್‌ನಲ್ಲಿ, ಮತ್ತು backend ನಲ್ಲಿ. ಎರಡನೇ ಮತ್ತು ಮೂರನೇ ಹಿಡಿತದ ನಡುವೆ ಮೂಲ ಬದಲಾದರೆ, ಕಾರಣ pod ನ ಕೆಳಗಿದೆ. ಎರಡನೆಯದಕ್ಕಿಂತ ಮೊದಲು ಬದಲಾದರೆ, pod ಸ್ವತಃ ಅನುವಾದಿಸುತ್ತಿದೆ.
ನಂತರ VPN pod ಅನ್ನು ಅಳಿಸಿ ಮತ್ತು ಮರುನಿಗದಿಯ ಸಮಯದಲ್ಲಿ ಪರೀಕ್ಷೆಯನ್ನು ಪುನರಾವರ್ತಿಸಿ. ಹೊರಹಾಕುವಿಕೆಯಲ್ಲಿ ಒಡೆಯುವ ಸಂರಕ್ಷಿತ ಮಾರ್ಗವು ಅಪೂರ್ಣ, ಮತ್ತು ಈಗ ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲದ ವಿಳಾಸಕ್ಕೆ ಪಿನ್ ಮಾಡಿದ NAT ನಿಯಮವೂ ಹಾಗೆಯೇ. ಕೊನೆಗೆ, ತಿರಸ್ಕರಿಸಲ್ಪಡುತ್ತದೆ ಎಂದು ನೀವು ನಿರೀಕ್ಷಿಸುವ ಮೂಲದಿಂದ ಒಂದು ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸಿ ಮತ್ತು ತಿರಸ್ಕಾರ ನೀತಿಯಿಂದ ಬರುತ್ತದೆ, ಕಾಣೆಯಾದ ಮಾರ್ಗದಿಂದ ಅಲ್ಲ ಎಂದು ಖಚಿತಪಡಿಸಿ.