Kubernetes ನಲ್ಲಿ OpenVPN ಪಾಡ್ ಏನನ್ನೂ ಫಾರ್ವರ್ಡ್ ಮಾಡುತ್ತಿಲ್ಲವೇ? ip_forward ಪರಿಶೀಲಿಸಿ

ನಿಮ್ಮ ಲ್ಯಾಪ್ಟಾಪ್ ಹಸಿರು ಸುರಂಗವನ್ನು ತೋರಿಸುತ್ತದೆ, ಕ್ಲೈಂಟ್ ಲಾಗ್ ಮಾರ್ಗಗಳನ್ನು ಪುಶ್ ಮಾಡಲಾಗಿದೆ ಎಂದು ಹೇಳುತ್ತದೆ, ಮತ್ತು ಉತ್ತರಿಸುವ ಏಕೈಕ ವಿಳಾಸ VPN ಸರ್ವರ್ನ ಸ್ವಂತ ಸುರಂಗ IP. ಅದರಾಚೆಗಿನ ಪಿಂಗ್ಗಳು ನೀವು ಏನನ್ನು ಗುರಿಯಾಗಿಸಿದರೂ ಸಾಯುತ್ತವೆ, ಅದು ClusterIP ಆಗಿರಲಿ, ಇನ್ನೊಂದು ಪಾಡ್ನ ವಿಳಾಸವಾಗಿರಲಿ ಅಥವಾ ಸಾರ್ವಜನಿಕ ಹೋಸ್ಟ್ನಾಮ್ ಆಗಿರಲಿ. ಈ ಸಂಯೋಜನೆ ಅಸ್ಪಷ್ಟವಲ್ಲ, ರೋಗನಿರ್ಣಯಾತ್ಮಕವಾಗಿದೆ: ಡೀಕ್ಯಾಪ್ಸುಲೇಶನ್ ಕೆಲಸ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಎರಡನೇ ಹಾಪ್ ಮಾಡುವುದಿಲ್ಲ.

ನಾನು ಇದನ್ನು chart ಮೂಲಕ ಸ್ಥಾಪಿಸಿದ OpenVPN ಇಮೇಜ್ ಚಲಾಯಿಸುತ್ತಿದ್ದ Debian ನೋಡ್ನಲ್ಲಿ ಎದುರಿಸಿದೆ, ಮತ್ತು ಸುರಂಗ ಸುಲಭ ಭಾಗವಾಗಿತ್ತು. ಕ್ಲೈಂಟ್ 10.8.0.x ಲೀಸ್ ಪಡೆಯಿತು, 10.8.0.1 ಉತ್ತರಿಸಿತು, ಮತ್ತು 10.96.0.10, ಕ್ಲಸ್ಟರ್ DNS ಸೇವೆ, ಸಮಯ ಮೀರಿತು. ಸರ್ವರ್ ಲಾಗ್ನಲ್ಲಿ ಏನೂ ಅನಾರೋಗ್ಯಕರವಾಗಿ ಕಾಣಲಿಲ್ಲ, ಮತ್ತು ಅವರು ಎಂದಿಗೂ ಮುಟ್ಟಬೇಕಾಗಿಲ್ಲದ iptables ನಿಯಮಗಳನ್ನು ಮತ್ತೆ ಬರೆಯಲು ಪ್ರಾರಂಭಿಸುವುದಕ್ಕೆ ಅದೇ ಕಾರಣ.

VPN ಪಾಡ್ ಒಂದು ರೌಟರ್, ಮತ್ತು ಅದನ್ನು ನೇರವಾಗಿ ಹೇಳುವುದು ಯೋಗ್ಯ. ಎನ್ಕ್ರಿಪ್ಟ್ ಮಾಡಿದ ಪ್ಯಾಕೆಟ್ಗಳು ಬರುತ್ತವೆ, ಪಾಡ್ನ ಸ್ವಂತ ನೆಟ್ವರ್ಕ್ ನೇಮ್ಸ್ಪೇಸ್ನಲ್ಲಿ ತೆರೆಯಲ್ಪಡುತ್ತವೆ, ನಂತರ ಬೇರೆ ಇಂಟರ್ಫೇಸ್ ಮೂಲಕ ಹೊರಹೋಗಬೇಕು. Linux ಆ ಎರಡನೇ ಹಂತವನ್ನು ಅದೇ ನೇಮ್ಸ್ಪೇಸ್ ಒಳಗೆ ಫಾರ್ವರ್ಡಿಂಗ್ ಸಕ್ರಿಯವಾಗಿಲ್ಲದಿದ್ದರೆ ನಿರಾಕರಿಸುತ್ತದೆ.

ಕ್ಲೈಂಟ್ ಏನನ್ನು ತಲುಪಬಲ್ಲದು ಮತ್ತು ಏನನ್ನು ತಲುಪಲಾರದು

ಉತ್ತರಿಸುವ ವಿಳಾಸ ಸುರಂಗದ ಎಂಡ್ಪಾಯಿಂಟ್ಗೆ ಸೇರಿದೆ, ಮತ್ತು VPN ಪ್ರಕ್ರಿಯೆ ಅದನ್ನು ಸ್ಥಳೀಯವಾಗಿ ಹೊಂದಿದೆ, ಆದ್ದರಿಂದ ಫಾರ್ವರ್ಡಿಂಗ್ ಸಂಪೂರ್ಣವಾಗಿ ಒಳಗೊಂಡಿಲ್ಲ. ಉಳಿದ ಎಲ್ಲವೂ, ಇನ್ನೊಂದು ಪಾಡ್, ಸೇವೆಯ VIP ಅಥವಾ ಇಂಟರ್ನೆಟ್ ಸೇರಿದಂತೆ, ಕರ್ನೆಲ್ ಪ್ಯಾಕೆಟ್ ಅನ್ನು tun0 ಇಂದ eth0 ಗೆ ಸರಿಸುವುದನ್ನು ಬೇಡುತ್ತದೆ. ಆ ಸರಿಸುವಿಕೆಯನ್ನು ನಿರಾಕರಿಸಿದಾಗ, ಲಕ್ಷಣವು ನಿರಾಕರಣೆಯಲ್ಲ, ಏಕರೂಪದ ಮೌನ, ಏಕೆಂದರೆ ಸುರಂಗದ ಕೆಳಗೆ ಮರಳಿ ಯಾವುದೇ ICMP ದೋಷವನ್ನು ಉತ್ಪಾದಿಸುವುದಿಲ್ಲ. ನೀವು ಟೈಮೌಟ್ಗಳನ್ನು ಪಡೆಯುತ್ತೀರಿ, ತಲುಪಲಾಗದ ಸಂದೇಶಗಳನ್ನಲ್ಲ, ಮತ್ತು ಯಾರೂ ರೌಟ್ ಮಾಡುತ್ತಿಲ್ಲ ಎಂಬುದಕ್ಕೆ ಅದೇ ಸುಳಿವು.

ಎರಡು ನಿಮಿಷಗಳ ವರ್ಗೀಕರಣ ಪದರವನ್ನು ಸಂಕುಚಿಸುತ್ತದೆ. DNS ಹೆಸರುಗಳು ವಿಫಲವಾದರೆ ಸೇವಾ IP ಗೆ ಕಚ್ಚಾ ಪಿಂಗ್ಗಳು ಯಶಸ್ವಿಯಾದರೆ, ಸಮಸ್ಯೆ ಫಾರ್ವರ್ಡಿಂಗ್ನಲ್ಲ, DNS ಪ್ಲಂಬಿಂಗ್ನಲ್ಲಿದೆ. ಪೀರ್ ವಿಳಾಸದ ಆಚೆಗಿನ ಪ್ರತಿ ಗಮ್ಯಸ್ಥಾನವೂ ಟೈಮೌಟ್ ಆದರೆ, ಬರಿಯ IP ಸೇರಿದಂತೆ, ನೇಮ್ಸ್ಪೇಸ್ನಿಂದ ಪ್ರಾರಂಭಿಸಿ.

ನೇಮ್ಸ್ಪೇಸ್ ಒಳಗಿನ ಸೆಟ್ಟಿಂಗ್ ಓದಿ

ಪ್ರತಿ ಪಾಡ್ ತನ್ನದೇ ನೆಟ್ವರ್ಕ್ ನೇಮ್ಸ್ಪೇಸ್ ಪಡೆಯುತ್ತದೆ, ಮತ್ತು net.ipv4.ip_forward ಪ್ರತಿ ನೇಮ್ಸ್ಪೇಸ್ಗೆ sysctl ಆಗಿದೆ. ನೋಡ್ನಲ್ಲಿ ಅದನ್ನು ಬದಲಾಯಿಸುವುದು ಕಂಟೇನರ್ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ, ಮತ್ತು ತಪ್ಪು ಯಂತ್ರದಲ್ಲಿ ಮಧ್ಯಾಹ್ನ ಕಳೆಯುವ ವಿಶ್ವಾಸಾರ್ಹ ದಾರಿ.

kubectl exec -it deploy/openvpn -- sysctl net.ipv4.ip_forward
# net.ipv4.ip_forward = 0

ಸೊನ್ನೆ ರೋಗನಿರ್ಣಯವನ್ನು ದೃಢೀಕರಿಸುತ್ತದೆ. ಮೌಲ್ಯವು ನೋಡ್ನ ರನ್ಟೈಮ್ ಸಂರಚನೆಯಿಂದಲೂ ಆನುವಂಶಿಕವಾಗಿ ಬರುವುದಿಲ್ಲ: ಕಂಟೇನರ್ ರಚಿಸಿದಾಗಲೆಲ್ಲಾ ಅದು ಇಮೇಜ್ನ ಡೀಫಾಲ್ಟ್ನಿಂದ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ. ಆದ್ದರಿಂದ kubectl exec ... sysctl -w ಮೂಲಕ ಕೈಯಿಂದ ಅನ್ವಯಿಸಿದ ಸರಿಪಡಿಸುವಿಕೆ ಮುಂದಿನ ಮರುಪ್ರಾರಂಭದಲ್ಲಿ ಮಾಯವಾಗಿ, ಮಧ್ಯಂತರವಾಗಿ ಕಾಣುವ ದೋಷವಾಗಿ ಮರಳುತ್ತದೆ.

ಮ್ಯಾನಿಫೆಸ್ಟ್ ಅದನ್ನು ಉಳಿಸಿಕೊಳ್ಳುವಂತೆ ಸಕ್ರಿಯಗೊಳಿಸುವುದು

ಬಾಳಿಕೆ ಬರುವ ಆಯ್ಕೆ ಎಂದರೆ ಅದೇ ಪಾಡ್ ಸ್ಯಾಂಡ್ಬಾಕ್ಸ್ನಲ್ಲಿ ಚಲಿಸುವ ಮತ್ತು VPN ಕಂಟೇನರ್ ಪ್ರಾರಂಭವಾಗುವ ಮೊದಲು ಮೌಲ್ಯವನ್ನು ಬರೆಯುವ init ಕಂಟೇನರ್. ಪಾಡ್ನಲ್ಲಿನ ಕಂಟೇನರ್ಗಳು ನೆಟ್ವರ್ಕ್ ನೇಮ್ಸ್ಪೇಸ್ ಹಂಚಿಕೊಳ್ಳುತ್ತವೆ, ಆದ್ದರಿಂದ ಸೆಟ್ಟಿಂಗ್ ಮುಖ್ಯ ಕಂಟೇನರ್ಗೆ ಹೋಗುತ್ತದೆ.

initContainers:
- name: enable-forwarding
  image: busybox:1.36
  command: ["sysctl", "-w", "net.ipv4.ip_forward=1"]
  securityContext:
    privileged: true

ಅದೇ privileged: true ಸಮೀಕ್ಷಕರು ಆಕ್ಷೇಪಿಸುವ ಸಾಲು, ಮತ್ತು ಅವರು ಸರಿ. sysctl ಬರೆಯಲು ಸವಲತ್ತು ಅಥವಾ ಸಂಕುಚಿತ ಸಾಮರ್ಥ್ಯ ಬೇಕು, ಮತ್ತು ನಿರ್ಬಂಧಿತ Pod Security Standard ಚಲಾಯಿಸುವ ಕ್ಲಸ್ಟರ್ ಸವಲತ್ತುಳ್ಳ init ಕಂಟೇನರ್ ಅನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ನಿರಾಕರಿಸಬಹುದು. admission ಪಾಡ್ ಅನ್ನು ನಿರಾಕರಿಸಿದರೆ, ರಚನೆಯ ಸಮಯದಲ್ಲೇ ತಿಳಿಯುತ್ತದೆ, ಅದು ಕನಿಷ್ಠ ಪ್ರಾಮಾಣಿಕ ಮತ್ತು ಓದಲು ಸುಲಭ.

ಸ್ವಚ್ಛವಾದ ಪರ್ಯಾಯ ಪಾಡ್ ಮಟ್ಟದ securityContext.sysctls ಪಟ್ಟಿ, ಇದು ಯಾವುದೇ ಕಂಟೇನರ್ಗೆ ಸವಲತ್ತು ನೀಡದೆ kubelet ಗೆ ನೇಮ್ಸ್ಪೇಸ್ಡ್ sysctl ಅನ್ವಯಿಸಲು ಅವಕಾಶ ನೀಡುತ್ತದೆ. ಇದು ಕ್ಲಸ್ಟರ್ನ ಅನುಮತಿ ಪಟ್ಟಿಯಲ್ಲಿನ ಹೆಸರುಗಳನ್ನು ಮಾತ್ರ ಒಳಗೊಳ್ಳುತ್ತದೆ. net.ipv4.ip_forward ಆ ಪಟ್ಟಿಯಲ್ಲಿದೆಯೇ ಎಂಬುದು kubelet ಹೇಗೆ ಸಂರಚಿಸಲಾಗಿದೆ ಎಂಬುದನ್ನು ಅವಲಂಬಿಸಿದೆ, ಮತ್ತು ಅದರ ಹೊರಗಿನ sysctl ಕೇಳುವ ಪಾಡ್ admission ನಲ್ಲಿ ನಿರಾಕರಿಸಲ್ಪಡುತ್ತದೆ ಅಥವಾ ಸ್ಯಾಂಡ್ಬಾಕ್ಸ್ ಮರುಪ್ರಯತ್ನಿಸುವಾಗ CreateContainerConfigError ನಲ್ಲಿ ಸಿಲುಕುತ್ತದೆ. ಕ್ಷೇತ್ರ ಮುರಿದಿದೆ ಎಂದು ಭಾವಿಸುವ ಮೊದಲು ಅನುಮತಿ ಪಟ್ಟಿ ಪರಿಶೀಲಿಸಿ.

ಎರಡೂ ವಿಧಾನಗಳಲ್ಲಿ ಯಾವುದನ್ನಾದರೂ ಕೈಯಿಂದ ನಿರ್ಮಿಸುವ ಮೊದಲು, chart ಈಗಾಗಲೇ ಸ್ವಿಚ್ ಅನ್ನು ಒದಗಿಸುತ್ತದೆಯೇ ನೋಡಿ, ಹೆಚ್ಚಾಗಿ ipForwardInitContainer: true ರಂತಹ ಯಾವುದೋ ರೂಪದಲ್ಲಿ. chart ಮೌಲ್ಯವನ್ನು ಬಳಸುವುದು ನಿಮ್ಮ override ಫೈಲ್ ಚಿಕ್ಕದಾಗಿರಿಸುತ್ತದೆ ಮತ್ತು ಮುಂದಿನ ಅಪ್ಗ್ರೇಡ್ ಅನ್ನು ದಾಟುತ್ತದೆ, ಕೈಯಿಂದ ಪ್ಯಾಚ್ ಮಾಡಿದ Deployment ಬದಲಾವಣೆಗಳು ಅದನ್ನು ಮಾಡುವುದಿಲ್ಲ.

ಎರಡನೇ ಅರ್ಧ: ಹಿಂತಿರುಗುವ ದಾರಿ ಮತ್ತು ನೀತಿ

ಫಾರ್ವರ್ಡಿಂಗ್ ಆನ್ ಆಗಿರುವುದು ಅಗತ್ಯ, ಸಾಕಲ್ಲ. ಕ್ಲೈಂಟ್ಗಳು ಕ್ಲಸ್ಟರ್ ನೆಟ್ವರ್ಕ್ಗೆ ಮಾರ್ಗವಿಲ್ಲದ ಖಾಸಗಿ ಪೂಲ್ ಬಳಸಿದರೆ, ಉತ್ತರಗಳು ಸುರಂಗಕ್ಕೆ ಹಿಂತಿರುಗುವ ದಾರಿ ಕಂಡುಕೊಳ್ಳಲಾರವು, ಮತ್ತು ಪಾಡ್ ಆ ಸಂಚಾರವನ್ನು ಅದರ ಗಮ್ಯಸ್ಥಾನದ ಕಡೆಗೆ ಮಾಸ್ಕ್ ಮಾಡಬೇಕು.

ನೀತಿ ಅದರ ಮೇಲೆ ಕುಳಿತಿದೆ. NetworkPolicy ವಸ್ತುಗಳು ಮತ್ತು ಕ್ಲೌಡ್ ಫೈರ್ವಾಲ್ ನಿಯಮಗಳನ್ನು ಅನುವಾದದ ನಂತರ ಪ್ಯಾಕೆಟ್ ಹೊತ್ತಿರುವ ಮೂಲ ವಿಳಾಸದ ವಿರುದ್ಧ ಮೌಲ್ಯಮಾಪನ ಮಾಡಲಾಗುತ್ತದೆ, ಆದ್ದರಿಂದ ಕ್ಲೈಂಟ್ ಪೂಲ್ಗೆ ಬರೆದ ನಿಯಮ ಮಾಸ್ಕಿಂಗ್ ಸಕ್ರಿಯವಾದ ನಂತರ ಮೌನವಾಗಿ ಹೊಂದಿಕೆಯಾಗುವುದನ್ನು ನಿಲ್ಲಿಸಬಹುದು.

ಕ್ಲೈಂಟ್ಗಳು ಕ್ಲಸ್ಟರ್ ಒಳಗಿನ ಸೇವೆಗಳನ್ನು ಮಾತ್ರ ತಲುಪಬೇಕಿದ್ದರೆ, VPN ಅನ್ನು ಸೇವಾ VIP ನಲ್ಲಿ ಕೊನೆಗೊಳಿಸುವುದು ಪಾಡ್ ನೆಟ್ವರ್ಕ್ಗೆ ರೌಟ್ ಮಾಡುವುದಕ್ಕಿಂತ ಚಿಕ್ಕ ವಿನ್ಯಾಸ. ಇದು ಕ್ಲೈಂಟ್ ಪೂಲ್ ಅನ್ನು CNI ಯ ರೌಟಿಂಗ್ ಟೇಬಲ್ನಿಂದ ಸಂಪೂರ್ಣವಾಗಿ ಹೊರಗಿಡುತ್ತದೆ.

ವಿಫಲವಾಗುವ ಹಾಪ್ ಅನ್ನು ಕ್ಲೈಂಟ್ನಿಂದ ಪ್ರತ್ಯೇಕಿಸುವುದು

ಹೊರಮುಖವಾಗಿ ಕೆಲಸ ಮಾಡಿ ಮತ್ತು ಮೊದಲ ಮೌನ ಹಂತದಲ್ಲಿ ನಿಲ್ಲಿಸಿ. VPN ಪೀರ್ನಿಂದ ಪ್ರಾರಂಭಿಸಿ, ನಂತರ ಯಾವುದೋ ಪಾಡ್ನ ವಿಳಾಸ ಪ್ರಯತ್ನಿಸಿ, ನಂತರ ಸೇವಾ VIP, ಮತ್ತು ನಂತರವೇ ಸಾರ್ವಜನಿಕ ಗಮ್ಯಸ್ಥಾನ. ಪ್ರತಿ ಯಶಸ್ಸು ಗಡಿಯನ್ನು ಒಂದು ಹಾಪ್ ಮುಂದೆ ಸರಿಸುತ್ತದೆ, ಮತ್ತು ಪ್ರತಿ ವೈಫಲ್ಯ ಪರಿಶೀಲಿಸಲು ಯೋಗ್ಯವಾದ ಪದರವನ್ನು ಹೆಸರಿಸುತ್ತದೆ. ಯಾವುದೇ ರೋಲ್ಔಟ್ ನಂತರ, exec ಮೂಲಕ ಒಳಹೋಗಿ sysctl ಅನ್ನು ಮತ್ತೆ ಓದಿ, ಏಕೆಂದರೆ ಬದಲಾಯಿಸಲಾದ ಪಾಡ್ ಇಮೇಜ್ನ ಡೀಫಾಲ್ಟ್ನಿಂದ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ ಮತ್ತು ಮ್ಯಾನಿಫೆಸ್ಟ್ನಲ್ಲಿ ಎಂದೂ ಇರದ ಸರಿಪಡಿಸುವಿಕೆ ಈಗಾಗಲೇ ಹೋಗಿದೆ.

Kubernetes ನ ದಾಖಲೆ ಕ್ಲಸ್ಟರ್ನಲ್ಲಿ sysctl ಬಳಕೆ ಕುರಿತು ಯಾವ ಹೆಸರುಗಳನ್ನು ಪಾಡ್ ಭದ್ರತಾ ಸಂದರ್ಭದ ಮೂಲಕ ಸೆಟ್ ಮಾಡಬಹುದು ಎಂದು ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ, ಮತ್ತು admission ಬದಲಾವಣೆಯನ್ನು ನಿರಾಕರಿಸಿದಾಗ ಮೊದಲು ನೋಡಬೇಕಾದದ್ದು ಅಲ್ಲಿಯೇ.