Kubernetes ਵਿੱਚ OpenVPN ਪੌਡ ਕੁਝ ਵੀ ਫਾਰਵਰਡ ਨਹੀਂ ਕਰਦਾ? ip_forward ਵੇਖੋ

ਤੁਹਾਡਾ ਲੈਪਟਾਪ ਹਰਾ ਟਨਲ ਦਿਖਾਉਂਦਾ ਹੈ, ਕਲਾਇੰਟ ਲੌਗ ਦੱਸਦਾ ਹੈ ਕਿ ਰੂਟ ਪੁਸ਼ ਹੋਏ, ਅਤੇ ਜਵਾਬ ਦੇਣ ਵਾਲਾ ਇੱਕੋ ਪਤਾ VPN ਸਰਵਰ ਦਾ ਆਪਣਾ ਟਨਲ IP ਹੈ। ਇਸ ਤੋਂ ਅੱਗੇ ਦੇ ਪਿੰਗ ਤੁਸੀਂ ਜੋ ਵੀ ਨਿਸ਼ਾਨਾ ਬਣਾਓ, ਮਰ ਜਾਂਦੇ ਹਨ, ਚਾਹੇ ਉਹ ClusterIP ਹੋਵੇ, ਕਿਸੇ ਹੋਰ ਪੌਡ ਦਾ ਪਤਾ ਹੋਵੇ ਜਾਂ ਜਨਤਕ ਹੋਸਟਨਾਮ ਹੋਵੇ। ਇਹ ਸੁਮੇਲ ਧੁੰਦਲਾ ਨਹੀਂ, ਨਿਦਾਨਕ ਹੈ: ਡੀਕੈਪਸੂਲੇਸ਼ਨ ਕੰਮ ਕਰਦਾ ਹੈ, ਅਤੇ ਦੂਜੀ ਹੌਪ ਨਹੀਂ।

ਮੈਨੂੰ ਇਹ ਇੱਕ Debian ਨੋਡ ਉੱਤੇ ਮਿਲਿਆ ਜੋ chart ਰਾਹੀਂ ਇੰਸਟਾਲ ਕੀਤੀ OpenVPN ਇਮੇਜ ਚਲਾ ਰਿਹਾ ਸੀ, ਅਤੇ ਟਨਲ ਸੌਖਾ ਹਿੱਸਾ ਸੀ। ਕਲਾਇੰਟ ਨੇ 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 ਨਾਲ ਹੱਥੀਂ ਲਾਇਆ ਸੁਧਾਰ ਅਗਲੇ ਰੀਸਟਾਰਟ ਉੱਤੇ ਅਲੋਪ ਹੋ ਜਾਂਦਾ ਹੈ ਅਤੇ ਵਿਚਕਾਰਲੇ ਤੌਰ ਤੇ ਦਿਸਣ ਵਾਲੀ ਖਰਾਬੀ ਵਜੋਂ ਵਾਪਸ ਆਉਂਦਾ ਹੈ।

ਇਸਨੂੰ ਚਾਲੂ ਕਰਨਾ ਤਾਂ ਜੋ ਮੈਨਿਫੈਸਟ ਇਸਨੂੰ ਰੱਖੇ

ਟਿਕਾਊ ਵਿਕਲਪ ਇੱਕ init ਕੰਟੇਨਰ ਹੈ ਜੋ ਉਸੇ ਪੌਡ ਸੈਂਡਬਾਕਸ ਵਿੱਚ ਚੱਲਦਾ ਹੈ ਅਤੇ VPN ਕੰਟੇਨਰ ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਮੁੱਲ ਲਿਖਦਾ ਹੈ। ਪੌਡ ਵਿੱਚ ਕੰਟੇਨਰ ਇੱਕ ਨੈੱਟਵਰਕ ਨੇਮਸਪੇਸ ਸਾਂਝਾ ਕਰਦੇ ਹਨ, ਇਸ ਲਈ ਸੈਟਿੰਗ ਮੁੱਖ ਕੰਟੇਨਰ ਵਿੱਚ ਚਲੀ ਜਾਂਦੀ ਹੈ।

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 ਵੱਲੋਂ ਬਦਲਾਅ ਅਸਵੀਕਾਰ ਹੋਣ ਉੱਤੇ ਪਹਿਲਾਂ ਉੱਥੇ ਹੀ ਵੇਖਣਾ ਚਾਹੀਦਾ ਹੈ।