kubectl OpenVPN ਰਾਹੀਂ ਨਿੱਜੀ ਕਲਸਟਰ ਦਾ API ਹੱਲ ਨਹੀਂ ਕਰ ਸਕਦਾ

kubectl ਨਾਮ ਖੋਜ ਵਿੱਚ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਟਨਲ ਚਾਲੂ ਹੈ ਅਤੇ API ਦਾ ਨਿੱਜੀ ਪਤਾ ਅਜੇ ਵੀ ping ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ। ਰਸਤਾ ਠੀਕ ਹੈ; ਕਲਾਇੰਟ ਅਜਿਹੇ ਰਿਜ਼ੌਲਵਰ ਨੂੰ ਪੁੱਛ ਰਿਹਾ ਹੈ ਜਿਸ ਨੇ ਕਲਸਟਰ ਦੇ ਨਿੱਜੀ ਜ਼ੋਨ ਬਾਰੇ ਕਦੇ ਨਹੀਂ ਸੁਣਿਆ। ਦੋ ਸੁਧਾਰ ਸਭ ਤੋਂ ਵੱਧ ਵਰਤੇ ਜਾਂਦੇ ਹਨ: ਵਰਚੁਅਲ ਨੈੱਟਵਰਕ ਦਾ ਰਿਜ਼ੌਲਵਰ ਹਰ VPN ਕਲਾਇੰਟ ਨੂੰ ਭੇਜਣਾ, ਜਾਂ ਨਾਮ ਨੂੰ ਸਥਾਨਕ ਤੌਰ ’ਤੇ hosts ਐਂਟਰੀ ਜਾਂ ਸ਼ਰਤੀ ਫਾਰਵਰਡਰ ਨਾਲ ਪਿੰਨ ਕਰਨਾ। ਦੋਵੇਂ ਇੱਕੋ ਲੱਛਣ ਨੂੰ ਵੱਖਰੀ ਜ਼ਿੰਮੇਵਾਰੀ ਨਾਲ ਹੱਲ ਕਰਦੇ ਹਨ, ਅਤੇ ਇਹਨਾਂ ਨੂੰ ਮਿਲਾਉਣਾ ਹੀ ਕਾਰਨ ਹੈ ਕਿ ਟੀਮਾਂ ਹਰ ਵਾਰ ਐਂਡਪੌਇੰਟ ਦੁਬਾਰਾ ਬਣਨ ’ਤੇ hosts ਫਾਈਲਾਂ ਸੋਧਦੀਆਂ ਹਨ।

ਹੱਲ ਅਤੇ ਪਹੁੰਚ ਵੱਖਰੀਆਂ ਪਰਤਾਂ ਵਿੱਚ ਫੇਲ੍ਹ ਹੁੰਦੇ ਹਨ

ਕੁਝ ਵੀ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਖੋਜ ਆਪ ਚਲਾਓ। Linux ’ਤੇ getent hosts ਜਾਂ Windows ’ਤੇ nslookup ਦੱਸਦਾ ਹੈ ਕਿ ਕਲਾਇੰਟ ਨੂੰ ਜਵਾਬ ਮਿਲਦਾ ਹੈ ਜਾਂ ਨਹੀਂ; ਸਮਾਂ ਖਤਮ ਹੋਣਾ ਜਾਂ NXDOMAIN ਰਿਜ਼ੌਲਵਰ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਗਲਤ ਪਤੇ ਵਾਲਾ ਜਵਾਬ ਪੁਰਾਣੇ ਰਿਕਾਰਡ ਜਾਂ ਜਨਤਕ ਰਾਹ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ।

ਫਿਰ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ kubectl ਅਸਲ ਵਿੱਚ ਕਿਹੜੇ ਸਰਵਰ ਨਾਲ ਜੁੜਦਾ ਹੈ। kubeconfig ਸੰਦਰਭ URL ਸਟੋਰ ਕਰਦਾ ਹੈ, ਅਤੇ VPN ਰਸਤਾ ਇਸਨੂੰ ਦੁਬਾਰਾ ਨਹੀਂ ਲਿਖਦਾ: ਜੇ ਸੰਦਰਭ ਜਨਤਕ ਐਂਡਪੌਇੰਟ ਦੱਸਦਾ ਹੈ, ਤਾਂ DNS ਸੰਪੂਰਨ ਹੋ ਸਕਦਾ ਹੈ ਅਤੇ ਕਮਾਂਡ ਫਿਰ ਵੀ ਫੇਲ੍ਹ ਹੋ ਸਕਦੀ ਹੈ।

getent hosts api.internal.example
kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}'
kubectl -v=8 get nodes 2>&1 | head -40

ਤੀਜਾ ਸੰਕੇਤ ਖੋਜ ਤੋਂ ਬਾਅਦ ਦੀ ਫੇਲ੍ਹਤਾ ਦਾ ਆਕਾਰ ਹੈ। ਜੋ ਨਾਮ ਨਿੱਜੀ ਪਤੇ ’ਤੇ ਹੱਲ ਹੋ ਕੇ ਫਿਰ TCP ਸਮਾਂ ਖਤਮ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ ਉਹ ਫਾਇਰਵਾਲ ਜਾਂ ਅਧਿਕ੍ਰਿਤ ਨੈੱਟਵਰਕ ਦੀ ਸਮੱਸਿਆ ਹੈ। ਜੋ ਨਾਮ ਜਨਤਕ ਪਤੇ ’ਤੇ ਹੱਲ ਹੁੰਦਾ ਹੈ ਉਸਦਾ ਅਰਥ ਹੈ ਕਿ ਕਵੈਰੀ ਨਿੱਜੀ ਜ਼ੋਨ ਤੋਂ ਬਾਹਰ ਨਿਕਲ ਗਈ। ਇਹਨਾਂ ਤਿੰਨ ਨਤੀਜਿਆਂ ਨੂੰ ਵੱਖਰਾ ਰੱਖੋ; ਹਰ ਇੱਕ ਤੁਹਾਨੂੰ ਵੱਖਰੇ ਜ਼ਿੰਮੇਵਾਰ ਕੋਲ ਭੇਜਦਾ ਹੈ।

ਵਿਕਲਪ A: ਵਰਚੁਅਲ ਨੈੱਟਵਰਕ ਦਾ ਰਿਜ਼ੌਲਵਰ ਟਨਲ ਵਿੱਚ ਭੇਜੋ

ਜਦੋਂ VPN ਸਰਵਰ ਵਰਚੁਅਲ ਨੈੱਟਵਰਕ ਦੇ ਅੰਦਰ ਚੱਲਦਾ ਹੈ, ਕਲਾਇੰਟ ਸਰਵਰ ਹੋਸਟ ਵਾਂਗ ਹੀ ਉਹੀ ਰਿਜ਼ੌਲਵਰ ਵਰਤ ਸਕਦੇ ਹਨ। OpenVPN Community ਵਿੱਚ ਸਰਵਰ DNS ਵਿਕਲਪ ਭੇਜਦਾ ਹੈ; Access Server ਉਹੀ ਸੈਟਿੰਗ ਐਡਮਿਨ ਇੰਟਰਫੇਸ ਵਿੱਚ ਦਿਖਾਉਂਦਾ ਹੈ, ਅਤੇ ਕਲਾਇੰਟ ਨੂੰ ਪ੍ਰੋਫਾਈਲ ਦੁਬਾਰਾ ਡਾਊਨਲੋਡ ਕਰਨੀ ਪੈਂਦੀ ਹੈ ਕਿਉਂਕਿ DNS ਨਿਰਦੇਸ਼ ਇਸਦੇ ਅੰਦਰ ਸਫ਼ਰ ਕਰਦਾ ਹੈ।

# server.conf
push "dhcp-option DNS 10.0.0.4"
push "route 10.0.0.4 255.255.255.255"

ਰੂਟ ਲਾਈਨ split tunnel ਪ੍ਰੋਫਾਈਲਾਂ ਵਿੱਚ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਰਿਜ਼ੌਲਵਰ ਦਾ ਪਤਾ ਭੇਜਣਾ ਇਸਨੂੰ ਪਹੁੰਚਯੋਗ ਬਣਾਉਣ ਦੇ ਬਰਾਬਰ ਨਹੀਂ: ਜੇ ਟਨਲ ਰਾਹੀਂ ਸਿਰਫ਼ ਕਲਸਟਰ ਦਾ ਸਬਨੈੱਟ ਜਾਂਦਾ ਹੈ, ਤਾਂ 10.0.0.4 ਦੀ ਕਵੈਰੀ ਸਥਾਨਕ LAN ਰਾਹੀਂ ਨਿਕਲ ਕੇ ਮਰ ਜਾਂਦੀ ਹੈ। ਰਿਜ਼ੌਲਵਰ ਲਈ ਹੋਸਟ ਰੂਟ ਭੇਜੋ, ਜਾਂ ਇਸਦਾ ਸਬਨੈੱਟ ਟਨਲ ਵਿੱਚ ਸ਼ਾਮਲ ਕਰੋ।

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

ਕਲਾਇੰਟ ’ਤੇ ਜਾਂਚੋ ਕਿ ਕੀ ਲਾਗੂ ਹੋਇਆ: systemd-resolved Linux ’ਤੇ resolvectl status, macOS ’ਤੇ scutil --dns, Windows ’ਤੇ ipconfig /all। ਭੇਜਿਆ DNS ਸਰਵਰ ਜੋ ਕਦੇ ਨਹੀਂ ਦਿਸਦਾ, ਇਸਦਾ ਅਰਥ ਹੈ ਕਿ ਪ੍ਰੋਫਾਈਲ ਦੁਬਾਰਾ ਲੋਡ ਨਹੀਂ ਹੋਈ।

ਵਿਕਲਪ B: hosts ਐਂਟਰੀਆਂ ਅਤੇ ਸ਼ਰਤੀ ਫਾਰਵਰਡਿੰਗ

hosts ਐਂਟਰੀ ਸਭ ਤੋਂ ਛੋਟਾ ਸੰਭਵ ਸੁਧਾਰ ਅਤੇ ਸਭ ਤੋਂ ਨਾਜ਼ੁਕ ਹੈ। ਇਹ ਇੱਕ ਨਾਮ ਨੂੰ ਇੱਕ ਮਸ਼ੀਨ ’ਤੇ ਇੱਕ ਪਤੇ ਨਾਲ ਜੋੜਦੀ ਹੈ, ਇਸ ਲਈ ਡੈਮੋ ਲਈ ਕੰਮ ਕਰਦੀ ਹੈ ਅਤੇ ਨਿੱਜੀ ਐਂਡਪੌਇੰਟ ਜਾਂ ਇਸਦਾ IP ਦੁਬਾਰਾ ਬਣਨ ’ਤੇ ਟੁੱਟ ਜਾਂਦੀ ਹੈ। ਇਹ ਅਸਲ ਖਾਲੀ ਥਾਂ ਨੂੰ ਬਾਕੀ ਟੀਮ ਤੋਂ ਲੁਕਾਉਂਦੀ ਵੀ ਹੈ।

ਸ਼ਰਤੀ ਫਾਰਵਰਡਰ ਹਰ ਕਲਾਇੰਟ ਨੂੰ DNS ਭੇਜੇ ਬਿਨਾਂ ਵਧੀਆ ਸਕੇਲ ਹੁੰਦਾ ਹੈ। dnsmasq ਇੱਕ ਜ਼ੋਨ VNet ਰਿਜ਼ੌਲਵਰ ਨੂੰ ਭੇਜ ਕੇ ਬਾਕੀ ਸਭ ਨੂੰ ਸ਼ਾਂਤ ਛੱਡ ਸਕਦਾ ਹੈ: server=/cluster.internal/10.0.0.4। Windows DNS ਵਿੱਚ ਸ਼ਰਤੀ ਫਾਰਵਰਡਰ ਹਨ, ਅਤੇ Windows ਕਲਾਇੰਟ ਉਸੇ ਵੰਡ ਲਈ NRPT ਨਿਯਮ ਵਰਤ ਸਕਦੇ ਹਨ। ਫਾਰਵਰਡਰ ਨੂੰ ਅਜੇ ਵੀ VNet ਰਿਜ਼ੌਲਵਰ ਤੱਕ ਰੂਟ ਚਾਹੀਦਾ ਹੈ।

ਫਾਰਵਰਡਿੰਗ ਆਮ ਬ੍ਰਾਊਜ਼ਿੰਗ ਨੂੰ ਸਥਾਨਕ ਰੱਖਦੀ ਹੈ, ਜੋ split tunnel ਵਿੱਚ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਇਹ ਤੁਹਾਨੂੰ ਨਿੱਜੀ ਜ਼ੋਨ ਦੀਆਂ ਕਵੈਰੀਆਂ ਲੌਗ ਕਰਨ ਦੀ ਇੱਕ ਥਾਂ ਅਤੇ ਫਾਰਵਰਡਰ ਹੋਸਟ ਦੇ ਹਿਲਣ ’ਤੇ ਟੁੱਟਣ ਵਾਲੀ ਇੱਕ ਥਾਂ ਦਿੰਦੀ ਹੈ।

ਜ਼ਿੰਮੇਵਾਰੀ ਅਨੁਸਾਰ ਚੁਣੋ, ਸੁਵਿਧਾ ਅਨੁਸਾਰ ਨਹੀਂ

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

hosts ਐਂਟਰੀਆਂ ਨਿਦਾਨ ਹਨ, ਤੈਨਾਤੀ ਨਹੀਂ। ਇੱਕ ਵਰਤੋ ਤਾਂ ਕਿ ਸਾਬਤ ਹੋਵੇ ਕਿ API ਪਹੁੰਚਯੋਗ ਹੈ, ਫਿਰ ਇਸਨੂੰ ਹਟਾਓ ਅਤੇ ਰਿਜ਼ੌਲਵਰ ਦਾ ਰਾਹ ਸੁਧਾਰੋ; ਇਸਨੂੰ ਰਹਿਣ ਦੇਣਾ ਬਾਅਦ ਵਿੱਚ ਰੂਟਿੰਗ ਦੇ ਸਵਾਲ ਨੂੰ ਖਜ਼ਾਨੇ ਦੀ ਭਾਲ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ। ਕੋਈ ਵੀ ਵਿਕਲਪ ਚੁਣੋ, ਜ਼ੋਨ, ਰਿਜ਼ੌਲਵਰ ਦਾ ਪਤਾ ਅਤੇ ਕਵੈਰੀ ਢੋਣ ਵਾਲਾ ਰੂਟ ਲਿਖ ਲਓ।

API ਐਂਡਪੌਇੰਟ ਦੀ ਜਾਂਚ ਕਰੋ, ਸਿਰਫ਼ ਨਾਮ ਨਹੀਂ

ਖੋਜ ਸਫਲ ਹੋਣ ’ਤੇ, ਕਲਸਟਰ CA ਨਾਲ API ਦਾ ਸੰਸਕਰਣ ਐਂਡਪੌਇੰਟ ਲਓ। curl --cacert ca.crt https://api.internal.example:6443/version TLS ਅਤੇ ਅਧਿਕਾਰ ਦੀਆਂ ਫੇਲ੍ਹਤਾਵਾਂ ਨੂੰ DNS ਤੋਂ ਵੱਖ ਕਰਦਾ ਹੈ। 403 ਦਾ ਅਰਥ ਹੈ ਕਿ ਨਾਮ ਅਤੇ ਕਨੈਕਸ਼ਨ ਕੰਮ ਕਰਦੇ ਹਨ ਅਤੇ ਪਛਾਣ ਨਹੀਂ।

ਇਹ ਵੀ ਵੇਖੋ ਕਿ ਕਲਾਇੰਟ ਦੀ ਪਤਾ ਰੇਂਜ ਨੂੰ ਕਲਸਟਰ ਦੇ ਅਧਿਕ੍ਰਿਤ ਨੈੱਟਵਰਕ ਜਾਂ ਫਾਇਰਵਾਲ ਮਨਜ਼ੂਰੀ ਦਿੰਦੇ ਹਨ ਜਾਂ ਨਹੀਂ। ਨਿੱਜੀ ਕਲਸਟਰ ਅਕਸਰ API ਟ੍ਰੈਫਿਕ ਸਿਰਫ਼ VNet ਜਾਂ peered ਰੇਂਜਾਂ ਤੋਂ ਸਵੀਕਾਰ ਕਰਦੇ ਹਨ, ਇਸ ਲਈ ਦੂਜੇ ਪੂਲ ਤੋਂ ਪਤੇ ਦੇਣ ਵਾਲੀ ਟਨਲ ਨੈੱਟਵਰਕ ਪਰਤ ’ਤੇ ਜੁੜਦੀ ਹੈ ਅਤੇ API ’ਤੇ ਛੱਡ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ।

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

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