ਅੱਗੇ Nginx, VPN ਪਿੱਛੇ ਨਿੱਜੀ ਬੈਕਐਂਡ

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

ਇੱਕ ਬੇਨਤੀ ਨੂੰ ਦੋ ਕਨੈਕਸ਼ਨਾਂ ਵਿੱਚੋਂ ਲੰਘਦਿਆਂ ਦੇਖਣਾ

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

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

Public client  -> frontend public address:443   (TLS, public name)
Frontend       -> VPN private backend 10.40.0.20:8443  (TLS, private name)

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

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

ਗੇਟਵੇ ਦਾ ਨਾਮ ਸੁਰੰਗ ਵਿੱਚੋਂ ਬਚਣਾ ਚਾਹੀਦਾ ਹੈ

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

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

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

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

ਸਰਵਰ ਬਲਾਕ ਇਸ ਤਰ੍ਹਾਂ ਲਿਖੋ ਕਿ ਦੋਵੇਂ ਹਿੱਸੇ ਜਾਂਚ ਕਰਨ

ਮੰਨ ਲਓ ਬੈਕਐਂਡ ਇਸ ਨਾਮ ਲਈ ਸਰਟੀਫਿਕੇਟ ਪੇਸ਼ ਕਰਦਾ ਹੈ: backend.corp.example ਅਤੇ ਨਿੱਜੀ ਪਤੇ ਉੱਤੇ ਜਵਾਬ ਦਿੰਦਾ ਹੈ। ਨਾਮ ਜਾਂਚਦਿਆਂ ਪਤੇ ਨਾਲ ਜੁੜਨਾ ਠੀਕ ਉਹੀ ਹੈ ਜਿਸ ਲਈ ਪ੍ਰਾਕਸੀ ਮਾਡਿਊਲ ਦੇ SNI ਅਤੇ ਨਾਮ ਵਿਕਲਪ ਹਨ।

upstream private_app {
    server 10.40.0.20:8443;
}

server {
    listen 443 ssl;
    server_name app.example.com;

    ssl_certificate     /etc/nginx/tls/app-fullchain.pem;
    ssl_certificate_key /etc/nginx/tls/app-key.pem;

    location / {
        proxy_pass https://private_app;
        proxy_ssl_server_name on;
        proxy_ssl_name backend.corp.example;
        proxy_ssl_trusted_certificate /etc/nginx/trust/backend-ca.pem;
        proxy_ssl_verify on;
        proxy_ssl_verify_depth 3;

        proxy_set_header Host app.example.com;
        proxy_set_header X-Forwarded-Proto https;
        proxy_set_header X-Forwarded-For $remote_addr;
    }
}

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

proxy_set_header Host app.example.com ਜਾਣ-ਬੁੱਝ ਕੇ ਹੈ। ਬੈਕਐਂਡ ਨੂੰ ਇਹ ਜਨਤਕ ਮੂਲ ਸਵੀਕਾਰ ਕਰਨ ਲਈ ਸੰਰਚਿਤ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਉਸਨੂੰ ਫਾਰਵਰਡ ਕੀਤੇ ਹੈਡਰਾਂ ਉੱਤੇ ਸਿਰਫ਼ ਇਸ ਫਰੰਟਐਂਡ ਤੋਂ ਭਰੋਸਾ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਇਸ ਉੱਤੇ ਲਿਖਣਾ X-Forwarded-For ਕਲਾਇੰਟ ਪਤੇ ਨਾਲ ਇੱਕ ਪ੍ਰਾਕਸੀ ਲਈ ਸਹੀ ਹੈ ਅਤੇ ਜ਼ੰਜੀਰ ਲਈ ਗਲਤ, ਇਸ ਲਈ ਬਹੁ-ਪ੍ਰਾਕਸੀ ਤੈਨਾਤੀ ਨੂੰ ਆਪਣੀ ਭਰੋਸੇਯੋਗ ਪਤਾ ਵਿਵਸਥਾ ਚਾਹੀਦੀ ਹੈ।

ਜਨਤਕ ਮੂਲ ਨੂੰ ਜਨਤਕ ਮੂਲ ਵਾਂਗ ਵਿਵਹਾਰ ਕਰਵਾਓ

ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਜਨਤਕ ਮੂਲ ਲਈ ਪੂਰਨ URL, ਰੀਡਾਇਰੈਕਟ ਅਤੇ ਕੂਕੀਜ਼ ਜਾਰੀ ਕਰਨੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ। ਜੇ ਇਹ ਕਿਸੇ ਆਗੰਤੁਕ ਨੂੰ ਇੱਥੇ ਭੇਜਦੀ ਹੈ: backend.corp.example, ਤਾਂ ਉਹ ਆਗੰਤੁਕ ਅਜਿਹੇ ਨਾਮ ਉੱਤੇ ਭੇਜਿਆ ਜਾਂਦਾ ਹੈ ਜੋ ਉਹ ਹੱਲ ਨਹੀਂ ਕਰ ਸਕਦਾ।

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

ਕੂਕੀਜ਼ ਵੀ ਉਸੇ ਦੇਖਭਾਲ ਦੇ ਹੱਕਦਾਰ ਹਨ। ਨਿੱਜੀ ਨਾਮ ਤੱਕ ਸੀਮਿਤ ਕੂਕੀ ਸਿਰਫ਼ ਜਨਤਕ ਨਾਮ ਜਾਣਨ ਵਾਲਾ ਬ੍ਰਾਊਜ਼ਰ ਕਦੇ ਨਹੀਂ ਭੇਜੇਗਾ।

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

ਹਰ ਹਿੱਸੇ ਨੂੰ ਉੱਥੇ ਹੀ ਜਾਂਚੋ ਜਿੱਥੇ ਉਹ ਸੱਚਮੁੱਚ ਚੱਲਦਾ ਹੈ

ਕਿਸੇ ਵੀ ਦੁਬਾਰਾ ਲੋਡ ਤੋਂ ਪਹਿਲਾਂ ਸੰਰਚਨਾ ਨੂੰ ਸਥਾਪਿਤ ਪਾਰਸਰ ਨਾਲ ਵੈਧ ਕਰੋ, ਤਾਂ ਜੋ ਟਾਈਪਿੰਗ ਦੀ ਗਲਤੀ ਹੁਣ ਸੇਵਾ ਦੇ ਰਹੇ ਸਰੋਤੇ ਨੂੰ ਡੇਗ ਨਾ ਦੇਵੇ।

ਫਿਰ ਬੈਕਐਂਡ ਵਾਲਾ ਹਿੱਸਾ ਫਰੰਟਐਂਡ ਹੋਸਟ ਤੋਂ ਹੀ, Nginx ਵਰਤਦਾ ਹੈ ਉਸੇ ਨੈੱਟਵਰਕ ਸੰਦਰਭ ਵਿੱਚ ਪਰਖੋ। ਸੁਰੰਗ ਰਾਹੀਂ ping ਪਹੁੰਚ ਸਾਬਤ ਕਰਦਾ ਹੈ ਅਤੇ TLS, ਅਧਿਕਾਰ ਜਾਂ ਐਪਲੀਕੇਸ਼ਨ ਬਾਰੇ ਕੁਝ ਨਹੀਂ।

ਅੰਤ ਵਿੱਚ ਅਸਲੀ ਹੋਸਟ ਨਾਮ ਉੱਤੇ ਆਮ ਸਰਟੀਫਿਕੇਟ ਜਾਂਚ ਨਾਲ ਤਾਜ਼ਾ ਜਨਤਕ ਬੇਨਤੀ ਕਰੋ, ਅਤੇ ਸਿਰਫ਼ ਜਵਾਬੀ ਬਾਡੀ ਨਹੀਂ ਬਲਕਿ ਜਵਾਬੀ ਰਾਹ ਦੇਖੋ।

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