ਇੱਕ ਕਲਾਊਡ ਸੇਵਾ ਲਈ ਨੇਟਿਵ TLS, SSH ਫਾਰਵਰਡ ਜਾਂ VPN

ਸਵਾਲ ਘੱਟ ਹੀ ਇਹ ਹੁੰਦਾ ਹੈ ਕਿ ਦੋ ਕਲਾਊਡ ਮਸ਼ੀਨਾਂ ਵਿਚਕਾਰ ਕੁਝ ਇਨਕ੍ਰਿਪਟ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਜਾਂ ਨਹੀਂ; ਸਵਾਲ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ਕਿਹੜਾ ਇੰਟਰਫੇਸ ਇਨਕ੍ਰਿਪਟ ਕਰ ਰਹੇ ਹੋ ਅਤੇ ਕੌਣ ਕਿਸਦੀ ਪਛਾਣ ਜਾਂਚਦਾ ਹੈ। ਮੈਂ ਇਹ ਗੱਲਬਾਤ ਨੈੱਟਵਰਕ ਡਾਇਗ੍ਰਾਮ ਨਾਲ ਨਹੀਂ, ਸੇਵਾ ਨਾਲ ਸ਼ੁਰੂ ਕਰਦਾ ਹਾਂ, ਕਿਉਂਕਿ ਸੇਵਾ ਨੂੰ ਪਹਿਲਾਂ ਹੀ ਪਤਾ ਹੈ ਕਿ ਉਸਨੂੰ ਕੀ ਚਾਹੀਦਾ ਹੈ। ਤਿੰਨ ਸੀਮਾਵਾਂ ਜ਼ਿਆਦਾਤਰ ਮਾਮਲੇ ਢਕਦੀਆਂ ਹਨ: ਐਪ ਦਾ ਆਪਣਾ TLS, SSH ਰਾਹੀਂ ਫਾਰਵਰਡ ਕੀਤਾ ਇੱਕ TCP ਪੋਰਟ, ਅਤੇ ਰਾਊਟਿਡ ਓਵਰਲੇ ਜੋ ਹਰ ਭਾਗੀਦਾਰ ਨੂੰ ਪਤਾ ਦਿੰਦਾ ਹੈ। ਇਹ ਤਾਕਤ ਦੇ ਕ੍ਰਮ ਵਿੱਚ ਨਹੀਂ, ਸਗੋਂ ਸਮੱਸਿਆ ਦਾ ਕਿੰਨਾ ਹਿੱਸਾ ਢਕਦੀਆਂ ਹਨ ਦੇ ਕ੍ਰਮ ਵਿੱਚ ਰੱਖੀਆਂ ਜਾਂਦੀਆਂ ਹਨ।

ਨੈੱਟਵਰਕ ਨਾਲ ਨਹੀਂ, ਸੇਵਾ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ

ਪ੍ਰਕਿਰਿਆ ਤੋਂ ਬਾਹਰ ਜਾਓ। ਇਹ ਕਿਹੜਾ ਪ੍ਰੋਟੋਕੋਲ ਬੋਲਦੀ ਹੈ, ਕਲਾਇੰਟ ਕਿਹੜਾ ਨਾਮ ਪ੍ਰਮਾਣਿਤ ਕਰੇਗਾ, ਅਤੇ ਕਿਸਨੂੰ ਬਿਲਕੁਲ ਕਨੈਕਸ਼ਨ ਖੋਲ੍ਹਣ ਦੀ ਆਗਿਆ ਹੈ? ਇਹ ਤਿੰਨ ਜਵਾਬ ਕਿਸੇ ਵੀ ਤੁਲਨਾ ਸਾਰਣੀ ਨਾਲੋਂ ਤੇਜ਼ੀ ਨਾਲ ਵਿਕਲਪ ਹਟਾਉਂਦੇ ਹਨ, ਅਤੇ ਸੇਵਾ ਦੀ ਆਪਣੀ ਸੰਰਚਨਾ ਆਮ ਤੌਰ 'ਤੇ ਕੁਝ ਮਿੰਟਾਂ ਵਿੱਚ ਇਹਨਾਂ ਦਾ ਜਵਾਬ ਦਿੰਦੀ ਹੈ।

8443 ਪੋਰਟ 'ਤੇ ਪਹਿਲਾਂ ਹੀ HTTPS ਦੇਣ ਵਾਲੀ ਛੋਟੀ ਅੰਦਰੂਨੀ API ਲਓ, api.internal.example ਲਈ ਸਰਟੀਫਿਕੇਟ ਨਾਲ। ਹੋਸਟ 'ਤੇ ss -ltnp ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਇਹ ਕਿਸ ਨਾਲ ਬੱਝੀ ਹੈ, ਅਤੇ openssl s_client -connect 127.0.0.1:8443 -verify_hostname api.internal.example ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਸਰਟੀਫਿਕੇਟ ਉਸ ਨਾਮ ਲਈ ਵੈਧ ਹੈ ਜੋ ਕਲਾਇੰਟ ਅਸਲ ਵਿੱਚ ਵਰਤੇਗਾ। ਜੇ ਦੋਵੇਂ ਸਿਹਤਮੰਦ ਹਨ, ਸੇਵਾ ਆਪਣਾ ਪ੍ਰਵਾਹ ਬਚਾ ਸਕਦੀ ਹੈ ਅਤੇ ਸਿਰਫ ਪਹੁੰਚ ਬਾਕੀ ਰਹਿੰਦੀ ਹੈ। ਇਹ ਨੈੱਟਵਰਕ ਬਣਾਉਣ ਨਾਲੋਂ ਬਹੁਤ ਛੋਟੀ ਸਮੱਸਿਆ ਹੈ।

ਕਦਮ 1: ਕੀ ਸੇਵਾ ਆਪਣੀ ਰੱਖਿਆ ਕਰਦੀ ਹੈ?

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

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

ਕਦਮ 2: ਕੀ ਇੱਕ TCP ਪੋਰਟ ਹੀ ਪੂਰੀ ਲੋੜ ਹੈ?

ਜਦੋਂ ਲੋੜ ਸੱਚਮੁੱਚ ਇੱਕ TCP ਪੋਰਟ ਹੈ, ਫਾਰਵਰਡ ਸਭ ਤੋਂ ਛੋਟੀ ਕੰਮ ਕਰਨ ਵਾਲੀ ਚੀਜ਼ ਹੈ। SSH ਸਥਾਨਕ ਫਾਰਵਰਡ ਉਹ ਪੋਰਟ ਪਹਿਲਾਂ ਹੀ ਮੌਜੂਦ ਪ੍ਰਮਾਣਿਤ ਕਨੈਕਸ਼ਨ ਰਾਹੀਂ ਲੈ ਜਾਂਦਾ ਹੈ।

ਆਕਾਰ ssh -N -L 8443:127.0.0.1:8443 [email protected] ਹੈ, ਅਤੇ ਮਹੱਤਵਪੂਰਨ ਵੇਰਵਾ ਟਾਰਗਿਟ ਪਤਾ ਹੈ: 127.0.0.1 ਦੂਰ ਦੇ ਪਾਸੇ ਹੱਲ ਹੁੰਦਾ ਹੈ, ਇਸ ਲਈ ਸੇਵਾ ਨਾਲ ਕਨੈਕਸ਼ਨ ਤੁਹਾਡੇ ਲੈਪਟਾਪ ਨਾਲੋਂ ਨਹੀਂ, ਬਾਸਟੀਅਨ ਤੋਂ ਖੁੱਲ੍ਹਦਾ ਹੈ। ਸਥਾਨਕ ਸਰੋਤੇ ਨੂੰ -L 127.0.0.1:8443:... ਵਜੋਂ ਤੰਗ ਰੂਪ ਵਿੱਚ ਬੰਨ੍ਹੋ ਤਾਂ ਜੋ ਤੁਸੀਂ ਗਲਤੀ ਨਾਲ ਸੇਵਾ ਆਪਣੇ ਸਥਾਨਕ ਨੈੱਟਵਰਕ 'ਤੇ ਪ੍ਰਕਾਸ਼ਿਤ ਨਾ ਕਰੋ। ਸਰਵਰ ਵਾਲੇ ਪਾਸੇ, ਕਲਾਇੰਟ ਦੇ ਚੰਗੇ ਵਿਵਹਾਰ 'ਤੇ ਭਰੋਸਾ ਕਰਨ ਦੀ ਬਜਾਏ ਖਾਤਾ ਕੀ ਫਾਰਵਰਡ ਕਰ ਸਕਦਾ ਹੈ ਸੀਮਿਤ ਕਰੋ। PermitOpen, AllowTcpForwarding local ਅਤੇ GatewayPorts no ਡਿਫਾਲਟ ਤਿੰਨ ਸੈਟਿੰਗਾਂ ਹਨ ਜੋ ਆਮ ਰਿਲੇ ਨੂੰ ਖਾਸ ਚੈਨਲ ਵਿੱਚ ਬਦਲਦੀਆਂ ਹਨ।

ਸਮਝੌਤਾ ਦੋਵੇਂ ਦਿਸ਼ਾਵਾਂ ਵਿੱਚ ਤੰਗ ਹੈ। SSH ਆਪਣੇ ਚੈਨਲ ਦੀ ਰੱਖਿਆ ਕਰਦਾ ਹੈ, ਅਤੇ ਬਾਸਟੀਅਨ ਤੋਂ ਕਿਸੇ ਹੋਰ ਐਪ ਤੱਕ ਅਗਲੇ ਹੌਪ ਨੂੰ ਆਪਣੀ ਸੁਰੱਖਿਆ ਚਾਹੀਦੀ ਹੈ। ਸਿਰਫ ਬਾਸਟੀਅਨ ਦੇ loopback 'ਤੇ ਸੁਣਨ ਵਾਲੀ ਸੇਵਾ ਦਾ ਸੰਪਰਕ ਦੂਜੇ ਨੈੱਟਵਰਕ ਰਾਹੀਂ ਪਹੁੰਚਣ ਵਾਲੀ ਸੇਵਾ ਨਾਲੋਂ ਬਿਲਕੁਲ ਵੱਖਰਾ ਹੈ, ਅਤੇ ਫਾਰਵਰਡ ਇਸਨੂੰ ਨਹੀਂ ਬਦਲਦਾ। ਟਨਲ ਨੂੰ ਉਹਨਾਂ ਦਾ ਬਦਲ ਮੰਨਣ ਦੀ ਬਜਾਏ ਐਪ ਦੀ ਪ੍ਰਮਾਣਿਕਤਾ ਅਤੇ TLS ਜਾਂਚਾਂ ਬਣਾਈ ਰੱਖੋ।

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

ਕਦਮ 3: ਕੀ ਰਾਊਟਿੰਗ ਹੀ ਅਸਲ ਲੋੜ ਹੈ?

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

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

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

ਬਾਅਦ ਵਿੱਚ ਤੁਹਾਡੇ ਕੋਲ ਕੀ ਹੈ

ਤੁਸੀਂ ਛੱਡਣ ਵਾਲੇ ਰਿਕਾਰਡ ਵਿੱਚ ਦੋ ਚੀਜ਼ਾਂ ਆਉਂਦੀਆਂ ਹਨ। ਪਹਿਲੀ ਉਹ ਪਛਾਣ ਹੈ ਜੋ ਕਲਾਇੰਟ ਨੂੰ ਪ੍ਰਮਾਣਿਤ ਕਰਨੀ ਹੈ, ਕਿਉਂਕਿ ਕੁਝ ਕੰਮ ਕਰਾਉਣ ਲਈ ਨਾਮ-ਜਾਂਚ ਢਿੱਲੀ ਹੁੰਦੇ ਹੀ ਇਹਨਾਂ ਵਿੱਚੋਂ ਹਰ ਸੀਮਾ ਚੁੱਪਚਾਪ ਵਿਗੜਦੀ ਹੈ। ਦੂਜੀ ਹਟਾਉਣ ਦਾ ਕਦਮ ਹੈ: ਪਹੁੰਚ ਖਤਮ ਹੋਣ 'ਤੇ ਕਿਹੜੀ ਕੁੰਜੀ, ਕਿਹੜਾ ਨਿਯਮ ਜਾਂ ਕਿਹੜਾ ਰੂਟ ਗਾਇਬ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਇਹ ਕੌਣ ਕਰਦਾ ਹੈ।

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