GKE ਪੋਡ VPN ਰਾਹੀਂ ਸਥਾਨਕ ਹੋਸਟਾਂ ਤੱਕ ਕਿਉਂ ਨਹੀਂ ਪਹੁੰਚ ਸਕਦੇ

ਨੋਡ ਤੋਂ ਪਿੰਗ ਚੱਲਦੀ ਹੈ ਅਤੇ ਪੋਡ ਤੋਂ ਫੇਲ੍ਹ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਸਥਾਨਕ ਪਾਸੇ ਕੁਝ ਨਹੀਂ ਪਹੁੰਚਦਾ। ਟਨਲ ਅਤੇ ਰੂਟ ਠੀਕ ਹਨ; ਤਾਰ ਉੱਤੇ ਸਰੋਤ ਪਤਾ ਨਹੀਂ। ਇਹਨਾਂ ਦੋ ਹਾਲਤਾਂ ਵਿੱਚ ਫ਼ਰਕ ਇਹ ਹੈ ਕਿ ਕਲਸਟਰ ਛੱਡਣ ਵੇਲੇ ਪੈਕਟ ਆਪਣੇ ਆਪ ਨੂੰ ਕੀ ਕਹਿੰਦਾ ਹੈ, ਅਤੇ GKE ਦਾ ਇਸ ਬਾਰੇ ਆਪਣਾ ਮੱਤ ਹੈ। ਕਾਰਜਵਿਧੀ masquerade ਛੋਟਾਂ ਦੀ ਸੂਚੀ ਹੈ, ਅਤੇ ਇਸ ਨੂੰ ਪੜ੍ਹਨ ਲਈ ਇੱਕ ਹੁਕਮ ਕਾਫ਼ੀ ਹੈ।

ਕੁਝ ਵੀ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਲਾਗੂ ਸੂਚੀ ਪੜ੍ਹੋ

GKE ਇੱਕ ਏਜੰਟ ਦਿੰਦਾ ਹੈ ਜੋ ਹਰ ਮੰਜ਼ਿਲ ਦਾਇਰੇ ਲਈ ਫ਼ੈਸਲਾ ਕਰਦਾ ਹੈ ਕਿ ਪੋਡ ਦੀ ਟ੍ਰੈਫ਼ਿਕ ਬਾਹਰ ਜਾਂਦਿਆਂ ਨੋਡ ਦੇ ਪਤੇ ਉੱਤੇ ਮੁੜ ਲਿਖੀ ਜਾਵੇ ਜਾਂ ਨਹੀਂ। ਇਸ ਦੀ ਦਿੱਤੀ ਸੰਰਚਨਾ ਤਿੰਨ RFC1918 ਬਲਾਕ, 10.0.0.0/8, 172.16.0.0/12 ਅਤੇ 192.168.0.0/16, ਨੂੰ ਛੋਟ ਪ੍ਰਾਪਤ ਮੰਜ਼ਿਲਾਂ ਵਜੋਂ ਨਾਮ ਦਿੰਦੀ ਹੈ। ਇਸ ਲਈ ਪੋਡ ਤੋਂ ਸਥਾਨਕ 10.x ਹੋਸਟ ਨੂੰ ਭੇਜੀ ਹਰ ਚੀਜ਼ ਪੋਡ ਦੇ ਆਪਣੇ ਪਤੇ ਸਮੇਤ ਨੋਡ ਛੱਡਦੀ ਹੈ। ਨੋਡ ਦੀ ਆਪਣੀ ਟ੍ਰੈਫ਼ਿਕ ਮੁੜ ਨਹੀਂ ਲਿਖੀ ਜਾਂਦੀ, ਅਤੇ ਇਸੇ ਕਰਕੇ ਇਸ ਦੀ ਪਿੰਗ ਚੱਲਦੀ ਹੈ।

ਯੋਜਿਤ ਸੰਰਚਨਾ ਅਤੇ ਸਥਾਪਿਤ ਨਿਯਮ ਪੜ੍ਹੋ, ਕਿਉਂਕਿ ਉਹ ਮੇਲ ਨਹੀਂ ਖਾ ਸਕਦੇ। kubectl -n kube-system get configmap ip-masq-agent -o yaml ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਏਜੰਟ ਨੂੰ ਕੀ ਦੱਸਿਆ ਗਿਆ, ਅਤੇ kubectl -n kube-system get pods -l k8s-app=ip-masq-agent ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਇਸ ਨੂੰ ਲਾਗੂ ਕਰਨ ਲਈ ਕੁਝ ਚੱਲ ਰਿਹਾ ਹੈ ਜਾਂ ਨਹੀਂ। ਨੋਡ ਉੱਤੇ iptables-save | grep -i masq ਉਹ ਨਿਯਮ ਦਿਖਾਉਂਦਾ ਹੈ ਜੋ ਕਰਨਲ ਵਿੱਚ ਸੱਚਮੁੱਚ ਮੌਜੂਦ ਹਨ। ਜਦੋਂ ConfigMap ਇੱਕ ਗੱਲ ਕਹਿੰਦਾ ਹੈ ਅਤੇ ਨਿਯਮ ਦੂਜੀ, ਤਾਂ ਸ਼ੱਕੀ ਨੈੱਟਵਰਕ ਨਹੀਂ, ਏਜੰਟ ਹੁੰਦਾ ਹੈ।

ਕੈਪਚਰ ਨਾਲ ਸਰੋਤ ਪਤੇ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ

ਸੂਚੀ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਕੈਪਚਰ ਕਰੋ। ਇੱਕੋ ਮੰਜ਼ਿਲ ਉੱਤੇ ਫਿਲਟਰ ਆਉਟਪੁੱਟ ਨੂੰ ਪੜ੍ਹਨਯੋਗ ਰੱਖਦਾ ਹੈ: tcpdump -ni any host 10.20.30.40।

ਇਸ ਦੀ ਤੁਲਨਾ ਉਸ ਨਾਲ ਕਰੋ ਜੋ ਪਾਰਲੇ ਪਾਸੇ ਤੋਂ ਦੱਸਿਆ ਜਾਂਦਾ ਹੈ। ਸਥਾਨਕ ਪਾਸੇ ਪੋਡ ਦਾ ਪਤਾ ਦਿਖਾਉਣ ਵਾਲਾ ਅਤੇ ਕੋਈ ਜਵਾਬ ਨਾ ਹੋਣ ਵਾਲਾ ਕੈਪਚਰ ਚੱਕਰ ਬੰਦ ਕਰਦਾ ਹੈ: ਛੋਟ ਸੂਚੀ ਟਨਲ ਦੀ ਕਿਸੇ ਵੀ ਖ਼ਰਾਬੀ ਤੋਂ ਬਿਨਾਂ ਅਸਮਾਨਤਾ ਦੀ ਵਿਆਖਿਆ ਕਰਦੀ ਹੈ। ਇੱਕੋ ਸਰੋਤ ਪਤੇ ਦੇ ਦੋ ਨਿਰੀਖਣ CNI ਬਾਰੇ ਅੰਦਾਜ਼ਾ ਲਾਉਣਾ ਛੱਡਣ ਲਈ ਕਾਫ਼ੀ ਹਨ।

ਛੋਟ ਨੂੰ ਪੋਡ CIDR ਤੱਕ ਸੀਮਤ ਕਰੋ

ਸਮਰਥਿਤ ਮੁਰੰਮਤ ਛੋਟ ਨੂੰ ਹਟਾਉਣ ਦੀ ਬਜਾਏ ਸੀਮਤ ਕਰਦੀ ਹੈ: ਪੋਡ CIDR ਨੂੰ ਛੋਟ ਵਜੋਂ ਰੱਖੋ ਅਤੇ 10.x ਥਾਂ ਦਾ ਬਾਕੀ ਛੱਡ ਦਿਓ। ਉਹ ਸੂਚੀ ਏਜੰਟ ਦੀ ConfigMap ਵਿੱਚ nonMasqueradeCIDRs ਹੇਠ ਹੈ, ਅਤੇ ਇਸ ਨੂੰ ਬਦਲਣਾ ਸੋਧ ਹੈ ਅਤੇ ਉਸ ਤੋਂ ਬਾਅਦ ਰੋਲਆਊਟ। ਚੌੜੀ ਐਂਟਰੀ ਨੂੰ ਕਲਸਟਰ ਦੀ ਅਸਲ ਪੋਡ ਰੇਂਜ ਨਾਲ ਬਦਲੋ, ਕਲਸਟਰ ਅੰਦਰ ਦੀ ਟ੍ਰੈਫ਼ਿਕ ਨੂੰ ਹਾਲੇ ਵੀ ਲੋੜ ਹੋਵੇ ਤਾਂ ਹੋਰ ਨਿੱਜੀ ਬਲਾਕ ਰੱਖੋ, ਅਤੇ ਕਾਰਨ ਨਾ ਹੋਵੇ ਤਾਂ resyncInterval ਨੂੰ ਜਿਵੇਂ ਹੈ ਤਿਵੇਂ ਛੱਡੋ। ਲਾਗੂ ਕਰੋ, ਏਜੰਟ ਦੇ ਪੋਡ ਮੁੜ ਸ਼ੁਰੂ ਹੋਣ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ, ਅਤੇ ਕਰਨਲ ਦੇ ਨਿਯਮ ਬਦਲਣ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ।

ਇਹ ਅਸਲ ਪ੍ਰਭਾਵ ਦਾਇਰੇ ਵਾਲਾ ਪੂਰੇ ਕਲਸਟਰ ਦਾ ਬਦਲਾਅ ਹੈ। ਲਾਗੂ ਹੋਣ ਤੋਂ ਬਾਅਦ, ਪਹਿਲਾਂ ਆਪਣਾ ਪੋਡ ਸਰੋਤ ਰੱਖਣ ਵਾਲੀ ਟ੍ਰੈਫ਼ਿਕ ਹੁਣ ਨੋਡ ਉੱਤੇ ਮੁੜ ਲਿਖੀ ਹੋਈ ਆਉਂਦੀ ਹੈ, ਇਸ ਲਈ ਉਹਨਾਂ ਪੋਡ ਪਤਿਆਂ ਉੱਤੇ ਨਿਰਭਰ ਹਰ ਚੀਜ਼ ਵੱਖਰਾ ਭੇਜਣ ਵਾਲਾ ਵੇਖਦੀ ਹੈ। ਸ਼ਿਕਾਰ ਉਹ ਲਾਗ, ਮਨਜ਼ੂਰੀ ਸੂਚੀਆਂ ਅਤੇ ਸਥਾਨਕ ਫਾਇਰਵਾਲ ਨਿਯਮ ਹਨ ਜੋ ਪੋਡ ਪਤੇ ਨਾਮ ਦਿੰਦੇ ਹਨ, ਅਤੇ ਉਹ ਚੁੱਪਚਾਪ ਫੇਲ੍ਹ ਹੁੰਦੇ ਹਨ। ਬਦਲਾਅ ਨੂੰ ਮੁਰੰਮਤ ਵਜੋਂ ਨਹੀਂ, ਵਿਵਹਾਰ ਬਦਲਾਅ ਵਜੋਂ ਐਲਾਨੋ।

ਕਈ ਨੋਡ ਪੂਲ ਵਾਲੇ ਕਲਸਟਰ ਵਿੱਚ, ਜਾਂਚੋ ਕਿ ਏਜੰਟ ਉਹਨਾਂ ਨੋਡਾਂ ਉੱਤੇ ਤੈਅ ਹੈ ਜਿੱਥੇ ਪ੍ਰਭਾਵਿਤ ਪੋਡ ਸੱਚਮੁੱਚ ਚੱਲਦੇ ਹਨ। DaemonSet ਤੋਂ ਬਿਨਾਂ ਪੂਲ ਆਪਣੇ ਪੁਰਾਣੇ ਨਿਯਮ ਰੱਖਦਾ ਹੈ, ਅਤੇ ConfigMap ਵਿੱਚ ਇਹ ਦਿਖਾਉਣ ਵਾਲਾ ਕੁਝ ਨਹੀਂ ਹੋਵੇਗਾ।

ਬਦਲ ਅਤੇ ਇਸ ਦੀ ਕੀਮਤ

ਦੂਜਾ ਵਿਕਲਪ ਪੋਡ ਪਤਿਆਂ ਨੂੰ ਅਛੂਤ ਰੱਖਦਾ ਹੈ ਅਤੇ ਰਾਹ ਨੂੰ ਉਹਨਾਂ ਬਾਰੇ ਸਿਖਾਉਂਦਾ ਹੈ। ਪੋਡ CIDR Cloud VPN ਦੇ ਟ੍ਰੈਫ਼ਿਕ ਚੋਣਕਾਰਾਂ ਵਿੱਚ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਸਥਾਨਕ ਪਾਸੇ ਨੂੰ ਜਵਾਬਾਂ ਨੂੰ ਪਤਾ ਹੋਣ ਲਈ ਕਿ ਕਿੱਥੇ ਜਾਣਾ ਹੈ, ਇਸ ਲਈ ਵਾਪਸੀ ਰੂਟ ਚਾਹੀਦਾ ਹੈ। ਇਹ ਕੁਝ ਸੁਰੱਖਿਆ ਮਾਡਲਾਂ ਦੀ ਲੋੜੀਂਦੀ ਪੋਡ ਪਛਾਣ ਬਚਾਉਂਦਾ ਹੈ, ਅਤੇ ਪਾਰਲੇ ਪਾਸੇ ਨੂੰ ਮੰਨਣ ਵਾਲੀ ਰੂਟਿੰਗ ਅਤੇ ਫਾਇਰਵਾਲ ਦੀ ਹੱਦ ਦੋਵੇਂ ਵਧਾਉਂਦਾ ਹੈ।

ਸੌਦਾ ਪੜ੍ਹਨਯੋਗਤਾ ਬਨਾਮ ਹੱਦ ਹੈ। ਅਨੁਵਾਦ ਸਥਾਨਕ ਪਾਸੇ ਨੂੰ ਹਰ ਨੋਡ ਲਈ ਇੱਕ ਪਤਾ ਦਿਖਾਉਂਦਾ ਹੈ, ਜੋ ਮਨਜ਼ੂਰੀ ਸੂਚੀ ਵਿੱਚ ਪਾਉਣਾ ਸੌਖਾ ਹੈ ਅਤੇ ਇਹ ਲੁਕਾਉਂਦਾ ਹੈ ਕਿ ਕਿਹੜਾ ਪੋਡ ਕੀ ਭੇਜਿਆ। ਅਨੁਵਾਦ ਤੋਂ ਬਿਨਾਂ ਪੋਡ ਪਤਾ ਸਿਰੇ ਤੋਂ ਸਿਰੇ ਤੱਕ ਰਹਿੰਦਾ ਹੈ, ਜੋ ਸਿਹਰੇ ਲਈ ਵਧੀਆ ਅਤੇ ਨਵੀਂ ਰੇਂਜ ਸਿੱਖਣ ਵਾਲੇ ਰਾਹ ਦੇ ਹਰ ਜੰਤਰ ਲਈ ਮਾੜਾ ਹੈ। ਦੋਵੇਂ ਵਿਕਲਪ Docker ਜਾਂ CNI ਦੋਸ਼ ਨਹੀਂ; ਦੋਵੇਂ ਸੰਚਾਲਨ ਬਿੱਲ ਵਾਲੇ ਰੂਟਿੰਗ ਫ਼ੈਸਲੇ ਹਨ। ਉਹ ਚੁਣੋ ਜਿਸ ਦਾ ਬਿੱਲ ਤੁਹਾਡੀ ਟੀਮ ਭਰ ਸਕਦੀ ਹੈ, ਅਤੇ ਕਿਉਂ ਲਿਖੋ।

ਪੁਸ਼ਟੀ ਕਰੋ ਅਤੇ ਵਾਪਸ ਕਰੋ

ਉਹੀ ਕੈਪਚਰ ਦੁਬਾਰਾ ਚਲਾਓ। ਤੁਹਾਡੀ ਸੋਧ ਤੋਂ ਬਾਅਦ ਵੀ ਨੋਡ-ਪੱਧਰੀ ਕੈਪਚਰ ਪੋਡ ਦਾ ਪਤਾ ਛਾਪਦਾ ਹੈ ਤਾਂ ConfigMap ਕੁਝ ਵੀ ਕਹੇ, ਨਿਯਮ ਕਦੇ ਨਹੀਂ ਬਦਲੇ। ਤਾਰ ਹੀ ਤੱਥ ਹੈ; ਬਾਕੀ ਸਭ ਅੰਦਾਜ਼ਾ ਹੈ।

ਫਿਰ ਉਲਟ ਦਿਸ਼ਾ ਜਾਂਚੋ, ਕਿਉਂਕਿ ਇਹਨਾਂ ਬਦਲਾਵਾਂ ਵਿੱਚੋਂ ਅੱਧੇ ਹੀ ਬਾਹਰ ਵੱਲ ਪੁਸ਼ਟੀ ਹੁੰਦੇ ਹਨ। ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਜਵਾਬ ਬੇਨਤੀ ਭੇਜਣ ਵਾਲੇ ਨੋਡ ਜਾਂ ਪੋਡ ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ, ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਨੇ ਸਿਰਫ਼ SYN ਲੈਣ ਦੀ ਬਜਾਏ ਪੂਰਾ ਕੀਤਾ। ਜਵਾਬ ਤੋਂ ਬਿਨਾਂ ਬੇਨਤੀ ਦਿਖਾਉਣ ਵਾਲਾ ਕੈਪਚਰ ਪਾਰਲੇ ਪਾਸੇ ਦੀ ਰੂਟਿੰਗ ਸਮੱਸਿਆ ਹੈ, ਇਸ ਪਾਸੇ ਦੀ masquerade ਸਮੱਸਿਆ ਨਹੀਂ।

ਵਾਪਸ ਕਰਨਾ ਪਿਛਲੀ ConfigMap ਹੈ, ਉਸੇ ਤਰੀਕੇ ਨਾਲ ਲਾਗੂ ਕੀਤੀ, ਉਸੇ ਪੁਸ਼ਟੀ ਨਾਲ ਕਿ ਏਜੰਟ ਮੁੜ ਸ਼ੁਰੂ ਹੋਇਆ ਅਤੇ ਨਿਯਮ ਬਦਲੇ। ਬਦਲਾਅ ਰਿਕਾਰਡ ਵਿੱਚ ਇੱਕ ਜਾਣੀ ਬੇਨਤੀ ਦਾ ਸਰੋਤ ਪਤਾ ਪਹਿਲਾਂ ਅਤੇ ਬਾਅਦ ਰੱਖੋ, ਕਿਉਂਕਿ ਉਹੀ ਇੱਕ ਲਾਈਨ ਸਾਬਤ ਕਰਦੀ ਹੈ ਕਿ ਬਦਲਾਅ ਨੇ ਤੁਹਾਡੀ ਕਹੀ ਗੱਲ ਕੀਤੀ। GKE IP masquerade ਏਜੰਟ ਗਾਈਡ ਡਿਫ਼ਾਲਟ ਅਤੇ ConfigMap ਖੇਤਰਾਂ ਦਾ ਦਸਤਾਵੇਜ਼ ਕਰਦੀ ਹੈ। ਰੋਲਆਊਟ ਤੋਂ ਬਾਅਦ ਸਰੋਤ ਪਤਾ ਨਾ ਬਦਲੇ ਤਾਂ ਉਸ ਨੋਡ ਉੱਤੇ ਏਜੰਟ ਨਹੀਂ ਚੱਲ ਰਿਹਾ ਅਤੇ ਕਿੰਨੀ ਵੀ YAML ਸੋਧ ਇਸ ਨੂੰ ਠੀਕ ਨਹੀਂ ਕਰੇਗੀ।