NGINX ਸਟ੍ਰੀਮ ਰੀਲੇ ਰਾਹੀਂ SSH — ਬਿਨਾਂ ਤੋੜੇ

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

ਦੋ ਸੀਮਾਵਾਂ, ਦੋ ਲੱਛਣ

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

ਅੱਪਸਟ੍ਰੀਮ ਦੀ ਅਸਫਲਤਾ ਵੱਖਰੀ ਦਿਸਦੀ ਹੈ। ਕਨੈਕਸ਼ਨ sshd ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ, sshd ਉਹ ਬਾਈਟ ਪੜ੍ਹਦਾ ਹੈ ਜੋ ਉਸ ਦੀ ਉਮੀਦ ਵਾਲੀ ਪਛਾਣ-ਅਦਲਾ-ਬਦਲੀ ਨਹੀਂ ਹਨ, ਅਤੇ ਸੈਸ਼ਨ ਕਦੇ ਚਾਬੀ ਦਿੱਤੇ ਬਿਨਾਂ ਮਰ ਜਾਂਦਾ ਹੈ ਜਾਂ ਅਟਕ ਜਾਂਦਾ ਹੈ।

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

PROXY ਹੈਡਰ ਇੱਕ ਸੁਨੇਹਾ ਹੈ, ਸਵਿੱਚ ਨਹੀਂ

ਸਟ੍ਰੀਮ ਮੌਡਿਊਲ ਵਿੱਚ, proxy_protocol on NGINX ਨੂੰ ਪੇਲੋਡ ਤੋਂ ਪਹਿਲਾਂ ਅੱਪਸਟ੍ਰੀਮ ਵੱਲ PROXY ਪ੍ਰੋਟੋਕੋਲ ਹੈਡਰ ਲਿਖਣ ਦਾ ਹੁਕਮ ਦਿੰਦਾ ਹੈ। ਇਹ TCP ਪ੍ਰੌਕਸੀ ਚਾਲੂ ਨਹੀਂ ਕਰਦਾ, ਅਤੇ ਇਸ ਦਾ SSH ਐਨਕ੍ਰਿਪਸ਼ਨ ਨਾਲ ਕੋਈ ਸੰਬੰਧ ਨਹੀਂ। ਇਹ ਪ੍ਰਾਪਤਕਰਤਾ ਵੱਲ ਸੰਬੋਧਿਤ ਨੋਟ ਹੈ। ਜੇ ਪ੍ਰਾਪਤਕਰਤਾ ਇਸ ਨੂੰ ਪੜ੍ਹ ਨਹੀਂ ਸਕਦਾ, ਤਾਂ ਇਹ ਸਟ੍ਰੀਮ ਦੇ ਸ਼ੁਰੂ ਵਿੱਚ ਕੂੜਾ ਬਣ ਜਾਂਦਾ ਹੈ।

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

stream {
    server {
        listen 2222;
        proxy_pass 10.77.0.20:22;
    }
}

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

ਦੋਵੇਂ ਦਿਸ਼ਾਵਾਂ ਵੀ ਵੱਖ ਕਰੋ। listen ਲਾਈਨ 'ਤੇ proxy_protocol ਸੈੱਟ ਕਰਨ ਦਾ ਮਤਲਬ ਹੈ NGINX ਉਮੀਦ ਕਰਦਾ ਹੈ ਕਿ ਉਸ ਦਾ ਆਪਣਾ ਕਲਾਇੰਟ ਪਹਿਲਾਂ ਹੈਡਰ ਭੇਜੇ; ਆਮ SSH ਕਲਾਇੰਟ ਲਈ ਇਸ ਨੂੰ ਚਾਲੂ ਕਰਨ ਨਾਲ ਲੋਕਾਂ ਦੁਆਰਾ ਆਮ ਤੌਰ 'ਤੇ ਹੱਲ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ ਜਾਂਦੀ ਸਮੱਸਿਆ ਦਾ ਬਿਲਕੁਲ ਉਲਟ ਹੁੰਦਾ ਹੈ।

ਜਨਤਕ ਹੋਸਟਨਾਮ ਅਸਲ ਵਿੱਚ ਕਿੱਥੇ ਪਹੁੰਚਦਾ ਹੈ

SSH ਸੈਸ਼ਨ ਵਿੱਚ HTTP 400 ਪੰਨਾ ਕਿਨਾਰੇ ਬਾਰੇ ਸਬੂਤ ਹੈ। ਰਾਹ ਵਿੱਚ ਕੁਝ HTTP ਬੋਲਦਾ ਹੈ, ਅਤੇ ਬੈਕਐਂਡ 'ਤੇ ਚਾਬੀ ਜਾਂ ਖਾਤੇ ਦਾ ਕੋਈ ਵੀ ਕੰਮ ਇਸ ਨੂੰ ਨਹੀਂ ਬਦਲੇਗਾ। ਕਿਨਾਰਾ ਤੈਅ ਹੋਣ ਤੱਕ ਬੈਕਐਂਡ ਬਦਲਣਾ ਬੰਦ ਕਰੋ।

Cloudflare ਦਾ ਆਮ ਪ੍ਰੌਕਸੀ ਕੀਤਾ ਰਿਕਾਰਡ ਆਪਣੀ ਸਮਰਥਿਤ HTTP ਅਤੇ HTTPS ਟ੍ਰੈਫਿਕ ਨਿਰਧਾਰਿਤ ਪੋਰਟਾਂ 'ਤੇ ਲਿਜਾਂਦਾ ਹੈ। ਹੋਸਟਨਾਮ ਲਈ ਪ੍ਰੌਕਸੀ ਚਾਲੂ ਕਰਨ ਨਾਲ ਆਮ TCP ਰੀਲਾ ਨਹੀਂ ਬਣਦਾ, ਅਤੇ SSH ਨੂੰ ਪੋਰਟ 443 'ਤੇ ਲਿਜਾਣ ਨਾਲ ਇਹ HTTPS ਨਹੀਂ ਬਣਦਾ।

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

ਤੁਸੀਂ ਜੋ ਵੀ ਚੁਣੋ, ਰੀਲੇ ਨੂੰ ਅਜੇ ਵੀ ਬੈਕਐਂਡ ਤੱਕ VPN ਰਸਤਾ, ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਕਨੈਕਸ਼ਨ ਅਤੇ ਵਾਪਸੀ ਰਸਤਾ ਚਾਹੀਦਾ ਹੈ। ਰਸਤਾ ਲਾਜ਼ਮੀ ਹੈ ਕਿਉਂਕਿ ਜਨਤਕ ਪਾਸਾ ਕੰਮ ਕਰਦਾ ਹੈ।

ਉਪਨਾਮ ਰਾਹੀਂ SSH ਪਛਾਣ ਸਥਿਰ ਰੱਖੋ

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

Host git.example.com
    HostName ssh-entry.example.net
    Port 2222
    User git
    HostKeyAlias git.example.com

HostKeyAlias ਤੋਂ ਬਿਨਾਂ, OpenSSH ਹੋਸਟ ਚਾਬੀ ਨੂੰ ਉਸ ਨਾਮ ਹੇਠ ਲੱਭਦਾ ਹੈ ਜਿਸ ਨਾਲ ਜੁੜਦਾ ਹੈ, ਇਸ ਲਈ ਐਂਟਰੀ ਖਿਸਕ ਜਾਂਦੀ ਹੈ ਅਤੇ ਹਰ ਵਰਤੋਂਕਾਰ ਪਹਿਲੀ ਵਰਤੋਂ 'ਤੇ ਬਦਲੀ ਚਾਬੀ ਦੀ ਚੇਤਾਵਨੀ ਵੇਖਦਾ ਹੈ। ਉਪਨਾਮ ਸੈੱਟ ਕਰਨ ਨਾਲ known-hosts ਐਂਟਰੀਆਂ ਸਥਿਰ ਰਹਿੰਦੀਆਂ ਹਨ ਅਤੇ ਕਨੈਕਸ਼ਨ ਅਜੇ ਵੀ ਰੀਲੇ ਵੱਲ ਜਾਂਦਾ ਹੈ।

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

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

ਹਰ ਹੌਪ ਨੂੰ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਪਰਖੋ

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

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

ਅੰਤ ਵਿੱਚ, ਮੰਤਵਿਤ ਬੇਪਰਦਗੀ ਦਾ ਦਸਤਾਵੇਜ਼ ਬਣਾਓ। ਨਿੱਜੀ ਬੈਕਐਂਡ ਤੱਕ SSH ਲਿਜਾਣ ਵਾਲਾ TCP ਰੀਲਾ ਜਨਤਕ ਘੇਰੇ ਵਿੱਚ ਜਾਣ-ਬੁੱਝ ਕੇ ਖੋਲ੍ਹਿਆ ਦਰਵਾਜ਼ਾ ਹੈ, ਅਤੇ ਇਹ ਕਿਸੇ ਵੀ ਹੋਰ ਆਉਣ ਵਾਲੀ ਸੇਵਾ ਵਾਂਗ ਸਮੀਖਿਆ ਦਾ ਹੱਕਦਾਰ ਹੈ।