Kubernetes ਵਿੱਚ VPN ਕਲਾਇੰਟ IP: ਇਸਨੂੰ ਸੰਭਾਲੀਏ ਜਾਂ SNAT ਕਰੀਏ?
Kubernetes ਵਿੱਚ VPN ਕਲਾਇੰਟ ਦੇ ਅਸਲ ਪਤੇ ਅਤੇ ਸਰੋਤ NAT ਵਿਚਕਾਰ ਤਿੰਨ ਸ਼ਰਤਾਂ ਦੇ ਆਧਾਰ 'ਤੇ ਚੁਣੋ, ਫਿਰ ਵਾਪਸੀ ਦਾ ਰਾਹ ਅਤੇ pod ਬਦਲਾਅ ਜਾਂਚੋ।
ਕਿਤੇ ਟਨਲ ਅਤੇ backend ਵਿਚਕਾਰ ਕਲਾਇੰਟ ਦਾ ਪਤਾ ਜਾਂ ਤਾਂ ਬਚਦਾ ਹੈ ਜਾਂ ਬਦਲ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਦੋਵੇਂ ਨਤੀਜੇ ਜਾਇਜ਼ ਹਨ। ਚੋਣ ਪ੍ਰਾਪਤ ਕਰਨ ਵਾਲੀ ਸੇਵਾ ਦੇ ਮਾਲਕ ਦੀ ਹੈ, CNI ਸਥਾਪਤ ਕਰਨ ਵਾਲੇ ਦੀ ਨਹੀਂ। ਜਦੋਂ ਪ੍ਰਤੀ-ਕਲਾਇੰਟ ਅਧਿਕਾਰ, ਕੋਟੇ ਜਾਂ ਆਡਿਟ ਰਿਕਾਰਡ ਮਾਅਨੇ ਰੱਖਦੇ ਹਨ, ਤਾਂ ਪਤੇ ਨੂੰ ਹਰ ਹੌਪ ਪਾਰ ਕਰਨਾ ਪਵੇਗਾ। ਜਦੋਂ ਸਾਂਝਾ ਆਰੋਪਣ ਸਵੀਕਾਰਯੋਗ ਹੈ, ਤਾਂ ਸਰੋਤ NAT ਉਹ ਰਾਊਟਿੰਗ ਸਮੱਸਿਆ ਹਟਾ ਦਿੰਦਾ ਹੈ ਜੋ ਨਹੀਂ ਤਾਂ ਤੁਸੀਂ ਹਮੇਸ਼ਾ ਸੰਭਾਲਦੇ ਰਹਿੰਦੇ।
ਪਤਾ ਅਸਲ ਵਿੱਚ ਕਿੱਥੇ ਗਾਇਬ ਹੁੰਦਾ ਹੈ
ਕਿਸੇ ਦੂਰ ਦੇ ਕਲਾਇੰਟ ਦਾ ਪੈਕਟ VPN pod ਤੱਕ ਟਨਲ ਰੇਂਜ ਦੇ ਅੰਦਰ ਅੰਦਰੂਨੀ ਸਰੋਤ ਨਾਲ ਪਹੁੰਚਦਾ ਹੈ, ਮੰਨ ਲਓ 10.90.0.42। ਜਦੋਂ pod ਉਹ ਪੈਕਟ ClusterIP ਜਾਂ pod IP ਵੱਲ ਅੱਗੇ ਭੇਜਦਾ ਹੈ, ਤਾਂ ਤਿੰਨ ਵੱਖਰੇ ਕਾਰਜ ਸਰੋਤ ਨੂੰ ਮੁੜ ਲਿਖ ਸਕਦੇ ਹਨ। ਨੋਡ ਦਾ CNI masquerade ਨਿਯਮ ਉਸ ਟ੍ਰੈਫਿਕ ਨੂੰ ਢਕਦਾ ਹੈ ਜੋ pod ਕਲਸਟਰ CIDR ਤੋਂ ਬਾਹਰ ਭੇਜਦਾ ਹੈ। ਮੰਜ਼ਿਲ ਨੋਡ 'ਤੇ kube-proxy ਦੀ conntrack ਐਂਟਰੀ ਆਪ Service ਹੌਪ ਨੂੰ ਢਕਦੀ ਹੈ। ਜੋ ਪ੍ਰੌਕਸੀ ਕਨੈਕਸ਼ਨ ਖਤਮ ਕਰਦੀ ਹੈ ਉਹ ਪੈਕਟ ਬਿਲਕੁਲ ਅੱਗੇ ਨਹੀਂ ਭੇਜਦੀ, ਇਸ ਲਈ ਅੰਤ ਵਿੱਚ ਜੋ ਸਰੋਤ ਤੁਸੀਂ ਦੇਖਦੇ ਹੋ ਉਹ ਪ੍ਰੌਕਸੀ ਦਾ ਹੈ।
ਇਹਨਾਂ ਵਿੱਚੋਂ ਹਰ ਇੱਕ ਵੱਖਰੀ ਪਰਤ ਵਿੱਚ ਰਹਿੰਦਾ ਹੈ, ਇਸ ਲਈ ਇੱਕ Service ਫੀਲਡ ਲਗਭਗ ਕਦੇ ਪੂਰਾ ਰਾਹ ਠੀਕ ਨਹੀਂ ਕਰਦੀ।
VPN ਦੇ ਜਨਤਕ Service 'ਤੇ externalTrafficPolicy ਸਿਰਫ ਬਾਹਰੀ ਕਨੈਕਸ਼ਨ ਬਾਰੇ ਫੈਸਲਾ ਕਰਦਾ ਹੈ: Local ਦੂਰ ਦੇ ਪਤੇ ਨੂੰ ਉਸ ਨੋਡ 'ਤੇ ਰੱਖਦਾ ਹੈ ਜਿਸਨੇ ਇਸਨੂੰ ਪ੍ਰਾਪਤ ਕੀਤਾ, ਜਦੋਂ ਕਿ Cluster kube-proxy ਨੂੰ ਪੈਕਟ ਦੂਜੇ ਨੋਡ ਨੂੰ ਦੇਣ ਅਤੇ ਉੱਥੇ masquerade ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ। ਉਹ ਸੈਟਿੰਗ ਉਸ ਲਿਸਨਰ ਨੂੰ ਨਿਯੰਤਰਿਤ ਕਰਦੀ ਹੈ ਜਿਸ ਨਾਲ ਤੁਹਾਡੇ ਕਲਾਇੰਟ ਜੁੜਦੇ ਹਨ। ਇਹ ਉਸ ਡਿਕ੍ਰਿਪਟ ਕੀਤੇ ਪੈਕਟ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦੀ ਜੋ ਤੁਹਾਡੀ 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 ਮੋਡ ਨੈੱਟਵਰਕ ਤੋਂ ਕੀ ਮੰਗਦਾ ਹੈ
ਸਰੋਤ ਸੰਭਾਲਣ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਮੰਜ਼ਿਲ ਨੋਡ ਨੂੰ ਟ੍ਰੈਫਿਕ ਸਰਗਰਮ 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 ਜਾਂ ਕਿਸੇ ਨੋਡ ਪਤੇ ਵੱਲ ਮੋੜੋ ਜੋ ਆਪਣੀ ਥਾਂ 'ਤੇ ਰਹੇ, ਜਾਂ ਮੰਨ ਲਓ ਕਿ ਹਰ ਬੇਦਖਲੀ ਤੋਂ ਬਾਅਦ ਤੁਸੀਂ ਗੇਟਵੇ ਪਿੱਛੇ ਭੱਜੋਗੇ। ਉਲਟੇ ਰਾਹ ਦੀ ਫਿਲਟਰਿੰਗ ਦੂਜਾ ਜਾਲ ਹੈ: ਸਖਤ ਮੋਡ ਉਹ ਪੈਕਟ ਡੇਗ ਦਿੰਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਦਾ ਵਾਪਸੀ ਰਾਹ ਉਸ ਇੰਟਰਫੇਸ ਨਾਲ ਨਹੀਂ ਮਿਲਦਾ ਜਿਸ 'ਤੇ ਉਹ ਆਏ, ਅਤੇ ਇਹ ਬਿਲਕੁਲ ਸੰਭਾਲੇ VPN ਪ੍ਰਵਾਹ ਦਾ ਆਕਾਰ ਹੈ।
ਢਿੱਲੀ ਪ੍ਰਮਾਣਿਕਤਾ ਅਕਸਰ ਕੰਮ ਕਰਨ ਵਾਲੇ ਵਾਪਸੀ ਰਾਹ ਅਤੇ ਉਹਨਾਂ ਜਵਾਬਾਂ ਵਿਚਕਾਰ ਫਰਕ ਹੁੰਦੀ ਹੈ ਜੋ backend ਛੱਡਣ ਤੋਂ ਬਾਅਦ ਗਾਇਬ ਹੋ ਜਾਂਦੇ ਹਨ। VPN ਨੋਡ 'ਤੇ masquerade ਨਿਯਮਾਂ ਨੂੰ ਵੀ ਟਨਲ ਰੇਂਜ ਬਾਹਰ ਰੱਖਣਾ ਪਵੇਗਾ, ਨਹੀਂ ਤਾਂ ਅੱਗੇ ਭੇਜਿਆ ਪੈਕਟ pod ਦੇ ਪਤੇ ਨਾਲ ਨਿਕਲੇਗਾ, ਭਾਵੇਂ ਤੁਸੀਂ ਕੋਈ ਵੀ ਰਾਹ ਬਣਾਇਆ ਹੋਵੇ। ਇਸ ਅਪਵਾਦ ਨੂੰ iptables ਹੱਥ ਨਾਲ ਸੋਧਣ ਦੀ ਬਜਾਏ CNI ਦੀ ਆਪਣੀ ਕਨਫਿਗਰੇਸ਼ਨ ਵਿੱਚ ਪ੍ਰਗਟ ਕਰੋ, ਕਿਉਂਕਿ ਏਜੰਟ ਮੁੜ ਚਾਲੂ ਹੋਣ 'ਤੇ ਆਪਣੀਆਂ ਚੇਨਾਂ ਮੁੜ ਲਿਖਦਾ ਹੈ ਅਤੇ ਤੁਹਾਡਾ ਹੱਥ ਨਾਲ ਲਿਖਿਆ ਨਿਯਮ ਠੀਕ ਅਗਲੇ ਅੱਪਗ੍ਰੇਡ ਤੱਕ ਰਹਿੰਦਾ ਹੈ।
NetworkPolicy ਪਹੁੰਚ ਨਿਯੰਤਰਣ ਹੈ, ਰਾਊਟਿੰਗ ਨਹੀਂ। ਨੀਤੀ ਸਖਤ ਕਰਨਾ ਕਦੇ ਉਹ ਪਤਾ ਬਹਾਲ ਨਹੀਂ ਕਰੇਗਾ ਜੋ masquerade ਪਹਿਲਾਂ ਹੀ ਬਦਲ ਚੁੱਕਾ ਹੈ।
SNAT ਦਾ ਕੀ ਖਰਚ ਹੈ, ਅਤੇ ਇਸਨੂੰ ਕਿਵੇਂ ਲਿਖਣਾ ਹੈ
ਕਲਸਟਰ ਵੱਲ ਸਰੋਤ NAT ਸਸਤਾ ਡਿਜ਼ਾਈਨ ਹੈ, ਅਤੇ ਇਹ ਗਲਤੀ ਨਹੀਂ। backend VPN pod ਜਾਂ ਨੋਡ ਦਾ ਪਤਾ ਦੇਖਦਾ ਹੈ, ਲੌਗ ਆਪਸ ਵਿੱਚ ਮਿਲਦੇ ਹਨ, ਅਤੇ ਕੋਈ ਵਾਪਸੀ ਰਾਹ ਹੋਣਾ ਜ਼ਰੂਰੀ ਨਹੀਂ। ਤੁਸੀਂ ਜੋ ਗੁਆਉਂਦੇ ਹੋ ਉਹ ਨੈੱਟਵਰਕ ਪਰਤ 'ਤੇ ਦੋ ਕਲਾਇੰਟ ਵੱਖ ਕਰਨ ਦੀ ਸਮਰੱਥਾ ਹੈ, ਇਸ ਲਈ ਕੋਟੇ, ਪਾਬੰਦੀਆਂ ਅਤੇ ਆਡਿਟ ਨਿਸ਼ਾਨ ਕਿਤੇ ਹੋਰ ਤੋਂ ਆਉਣੇ ਚਾਹੀਦੇ ਹਨ।
ਆਮ ਤੌਰ 'ਤੇ ਉਹ ਕਿਤੇ ਹੋਰ ਐਪਲੀਕੇਸ਼ਨ ਹੁੰਦਾ ਹੈ: ਸੈਸ਼ਨ ਟੋਕਨ, ਦਸਤਖਤ ਕੀਤਾ ਹੈਡਰ, ਜਾਂ PROXY ਪ੍ਰੋਟੋਕੋਲ ਦੀ ਲਾਈਨ ਜੋ ਤੁਹਾਡੇ ਨਿਯੰਤਰਣ ਵਾਲੀ ਪ੍ਰੌਕਸੀ ਲਿਖਦੀ ਹੈ। ਇਹ ਪ੍ਰਾਪਤਕਰਤਾ ਨੂੰ ਅਜਿਹੀ ਪਛਾਣ ਦਿੰਦੇ ਹਨ ਜਿਸ 'ਤੇ ਉਹ ਸਿਰਫ ਤਦ ਭਰੋਸਾ ਕਰ ਸਕਦਾ ਹੈ ਜਦੋਂ ਪ੍ਰੌਕਸੀ ਰਾਹ 'ਤੇ ਹੋਵੇ ਅਤੇ ਹੈਡਰ ਕਲਾਇੰਟ ਵੱਲੋਂ ਸੈਟ ਨਾ ਕੀਤਾ ਜਾ ਸਕੇ। runbook ਵਿੱਚ ਸਪਸ਼ਟ ਕਹੋ ਕਿ ਕਿਹੜਾ ਲਾਗੂ ਹੁੰਦਾ ਹੈ, ਕਿਉਂਕਿ ਅਗਲਾ ਇੰਜੀਨੀਅਰ ਮੰਨ ਲਵੇਗਾ ਕਿ ਲੌਗ ਵਿੱਚ ਦਿੱਤਾ ਪਤਾ ਕਲਾਇੰਟ ਹੈ। ਇਹ ਨਹੀਂ ਹੈ, ਅਤੇ ਇੱਕ ਘਟਨਾ ਉਸ ਧਾਰਨਾ ਨੂੰ ਮਹਿੰਗਾ ਬਣਾਉਣ ਲਈ ਕਾਫੀ ਹੈ।
ਇਹ ਅਦਲਾ-ਬਦਲੀ ਉਦੋਂ ਤੱਕ ਇਮਾਨਦਾਰ ਰਹਿੰਦੀ ਹੈ ਜਦੋਂ ਤੱਕ ਲਿਖੀ ਰਹੇ।
ਉਹ ਜਾਂਚਾਂ ਜੋ ਕੰਮ ਕਰਨ ਵਾਲੇ ਰਾਹ ਨੂੰ ਕਿਸਮਤ ਵਾਲੇ ਰਾਹ ਤੋਂ ਵੱਖ ਕਰਦੀਆਂ ਹਨ
ਤਾਜ਼ਾ ਕਨੈਕਸ਼ਨ ਨਾਲ ਜਾਂਚੋ, ਕੈਸ਼ ਕੀਤੇ ਕਨੈਕਸ਼ਨ ਨਾਲ ਨਹੀਂ, ਅਤੇ ਦੋਵੇਂ ਦਿਸ਼ਾਵਾਂ ਵਿੱਚ ਜਾਂਚੋ। ਕਈ ਅਸਫਲਤਾਵਾਂ ਸਿਰਫ ਇਸ ਲਈ ਰੁਕ-ਰੁਕ ਕੇ ਲੱਗਦੀਆਂ ਹਨ ਕਿਉਂਕਿ ਨਵੇਂ ਪ੍ਰਵਾਹ ਮੁੜ ਲਿਖਿਆ ਰਾਹ ਲੈਂਦੇ ਹਨ।
ਇੱਕ ਅਧਿਕਾਰਤ ਬੇਨਤੀ ਦੌਰਾਨ tuple ਤਿੰਨ ਥਾਵਾਂ 'ਤੇ ਫੜੋ: ਡਿਕ੍ਰਿਪਸ਼ਨ ਤੋਂ ਤੁਰੰਤ ਬਾਅਦ, VPN pod ਦੇ ਨਿਕਾਸ ਇੰਟਰਫੇਸ 'ਤੇ, ਅਤੇ backend 'ਤੇ। ਜੇ ਸਰੋਤ ਦੂਜੀ ਅਤੇ ਤੀਜੀ ਫੜ ਵਿਚਕਾਰ ਬਦਲਦਾ ਹੈ, ਤਾਂ ਕਾਰਨ pod ਤੋਂ ਹੇਠਾਂ ਹੈ। ਜੇ ਦੂਜੀ ਤੋਂ ਪਹਿਲਾਂ ਬਦਲਦਾ ਹੈ, ਤਾਂ pod ਖੁਦ ਅਨੁਵਾਦ ਕਰ ਰਿਹਾ ਹੈ।
ਫਿਰ VPN pod ਮਿਟਾਓ ਅਤੇ ਮੁੜ-ਨਿਯਤ ਕਰਨ ਦੌਰਾਨ ਟੈਸਟ ਦੁਹਰਾਓ। ਸੰਭਾਲਿਆ ਰਾਹ ਜੋ ਬੇਦਖਲੀ 'ਤੇ ਟੁੱਟ ਜਾਵੇ ਅਧੂਰਾ ਹੈ, ਅਤੇ ਉਹ NAT ਨਿਯਮ ਵੀ ਜੋ ਹੁਣ ਮੌਜੂਦ ਨਹੀਂ ਪਤੇ ਨਾਲ ਬੰਨ੍ਹਿਆ ਹੋਵੇ। ਅੰਤ ਵਿੱਚ ਅਜਿਹੇ ਸਰੋਤ ਤੋਂ ਇੱਕ ਬੇਨਤੀ ਭੇਜੋ ਜਿਸਦਾ ਇਨਕਾਰ ਆਸ ਕਰਦੇ ਹੋ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਇਨਕਾਰ ਨੀਤੀ ਤੋਂ ਆਉਂਦਾ ਹੈ, ਕਿਸੇ ਗਾਇਬ ਰਾਹ ਤੋਂ ਨਹੀਂ।