ਸਿਰਫ਼ VPN ਲਈ NGINX ਸਾਈਟ: ਲਿਸਨਰ, ਫਾਇਰਵਾਲ ਅਤੇ HTTP ਇਜਾਜ਼ਤ ਸੂਚੀ

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

ਉਦਾਹਰਨ tun0 'ਤੇ 10.90.0.1 'ਤੇ Linux OpenVPN ਗੇਟਵੇ, 10.90.0.0/24 ਵਿੱਚ ਕਲਾਇੰਟ, ਸੁਰੱਖਿਅਤ ਸਰੋਤ ਅਤੇ ਇਸ ਦਾਖਲੇ ਲਈ ਰਾਖਵਾਂ TCP 8443 ਵਰਤਦੀ ਹੈ। ਮੁੱਲ ਸਮਾਯੋਜਿਤ ਕਰੋ, ਪਰਤਾਂ ਰੱਖੋ।

ਹੋਸਟਨਾਮ ਨਾਲ ਨਹੀਂ, ਸਾਕਟ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ

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

server {
    listen 10.90.0.1:8443 ssl;
    server_name admin.corp.example;

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

    root /srv/private-site;

    allow 10.90.0.0/24;
    deny all;

    location / {
        try_files $uri $uri/ =404;
    }
}

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

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

ਉਸ ਸਮੱਗਰੀ ਲਈ ਹਰ ਹੋਰ ਲਿਸਨਰ ਬੰਦ ਕਰੋ

listen ਨਿਰਦੇਸ਼ਾਂ ਦੀ ਸੂਚੀ ਬਣਾਓ ਅਤੇ ਉਹਨਾਂ ਵੱਲੋਂ ਪਰੋਸੇ ਜਾਂਦੇ ਰੂਟਾਂ ਦੀ ਤੁਲਨਾ ਕਰੋ। ਕਿਸੇ ਹੋਰ ਐਪ ਲਈ ਜੋੜਿਆ ਬਲਾਕ ਉਸੇ upstream 'ਤੇ ਪ੍ਰੌਕਸੀ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ ਪੁਰਾਣਾ ਡਿਫਾਲਟ ਸਰਵਰ ਨਵਾਂ ਲੱਗਣ ਤੋਂ ਬਾਅਦ ਵੀ ਜਵਾਬ ਦੇ ਸਕਦਾ ਹੈ। ਉਹ ਆਉਟਪੁੱਟ ਸੱਚੀ ਸੂਚੀ ਹੈ, ਹੁਣੇ ਸੋਧੀ ਫਾਈਲ ਨਹੀਂ। ਉਹੀ ਸਮੱਗਰੀ ਪਰੋਸਣ ਵਾਲੇ ਹਰ ਰੂਟ ਦੀ ਤੁਲਨਾ ਕਰੋ।

sudo nginx -T | grep -n "listen\|server_name\|root\|proxy_pass"

ਦੋਵੇਂ ਪਤਾ ਪਰਿਵਾਰ ਜਾਂਚੋ। IPv4 ਬਾਈਂਡ IPv6 ਸਾਕਟ ਨੂੰ ਛੋਹੇ ਬਿਨਾਂ ਛੱਡਦਾ ਹੈ, ਅਤੇ ਨਵਾਂ A ਰਿਕਾਰਡ ਪੁਰਾਣੇ AAAA ਜਵਾਬ ਨੂੰ ਵਾਪਸ ਨਹੀਂ ਲੈਂਦਾ ਜੋ ਅਜੇ ਵੀ ਜਨਤਕ ਰਾਹ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ।

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

ਹੋਸਟ 'ਤੇ ਆਉਣ ਵਾਲੇ ਰਾਹ ਦੀ ਸੀਮਾ ਤੈਅ ਕਰੋ

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

ਡਿਫਾਲਟ-ਇਨਕਾਰ ਇਨਕਮਿੰਗ ਨੀਤੀ ਅਤੇ ਇਸ ਸੇਵਾ ਲਈ ਵਿਆਪਕ ਇਜਾਜ਼ਤ ਤੋਂ ਬਿਨਾਂ, ਸੀਮਤ ਨਿਯਮ ਟਨਲ, ਸਰੋਤ ਰੇਂਜ, ਮੰਜ਼ਿਲ ਅਤੇ ਪੋਰਟ ਨੂੰ ਇਕੱਠੇ ਨਾਮ ਦਿੰਦਾ ਹੈ:

sudo ufw allow in on tun0 proto tcp from 10.90.0.0/24 to 10.90.0.1 port 8443

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

ਉਹ ਨਿਯਮ ਹੋਸਟ ਇਨਪੁਟ ਹੈ, ਕਿਸੇ ਹੋਰ LAN ਮਸ਼ੀਨ ਵੱਲ ਰਾਹ ਨਹੀਂ, ਅਤੇ ਗੇਟਵੇ ਦਾ ਬਾਹਰੀ OpenVPN ਲਿਸਨਰ ਵੱਖਰੀ ਸੇਵਾ ਹੀ ਰਹਿੰਦਾ ਹੈ। ਜੇ ਸਾਈਟ ਪਹਿਲਾਂ ਜਨਤਕ ਸੀ, ਤਾਂ ਯੋਜਨਾ ਬਣਾਓ ਕਿ ਪੁਰਾਣਾ ਦਾਖਲਾ ਕਿਵੇਂ ਹਟੇਗਾ ਅਤੇ ਮੌਜੂਦਾ ਸੈਸ਼ਨ ਕਿਵੇਂ ਸੰਭਾਲੇ ਜਾਣਗੇ।

ਟਿਕਾਣੇ ਬਦਲਣ 'ਤੇ HTTP ਸੂਚੀ ਅਟੁੱਟ ਰੱਖੋ

NGINX allow ਅਤੇ deny ਐਂਟਰੀਆਂ ਨੂੰ ਕ੍ਰਮ ਵਿੱਚ ਮੁਲਾਂਕਣ ਕਰਦਾ ਹੈ, ਅਤੇ ਉੱਪਰਲੀ ਸਰਵਰ-ਪੱਧਰੀ ਸੂਚੀ ਅੰਤਿਮ deny ਤੋਂ ਪਹਿਲਾਂ ਘੋਸ਼ਿਤ ਸਮੂਹ ਨੂੰ ਦਾਖਲਾ ਦਿੰਦੀ ਹੈ। ਪਹੁੰਚ ਮੋਡਿਊਲ ਇਹ ਵੀ ਦਰਜ ਕਰਦਾ ਹੈ ਕਿ ਕੋਈ ਵੀ ਪਹੁੰਚ ਐਂਟਰੀ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨ ਵਾਲਾ ਟਿਕਾਣਾ ਮੂਲ ਸੂਚੀ ਦੀ ਥਾਂ ਆਪਣੀ ਸੂਚੀ ਵਰਤਦਾ ਹੈ। ਕ੍ਰਮ ਐਂਟਰੀਆਂ ਜਿੰਨਾ ਹੀ ਮਹੱਤਵਪੂਰਨ ਹੈ।

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

ਹਰ ਟਿਕਾਣੇ, ਉਪਨਾਮ ਅਤੇ ਵਿਕਲਪਕ ਬਲਾਕ ਦੀ ਇੱਕੋ ਨੀਤੀ ਦੇ ਹਿੱਸੇ ਵਜੋਂ ਸਮੀਖਿਆ ਕਰੋ। ਜੇ IP ਜਾਂਚਾਂ NGINX ਪ੍ਰਮਾਣੀਕਰਨ ਨਾਲ ਜੋੜੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਤਾਂ satisfy ਸਮਝੋ: any ਸੈਟਿੰਗ ਇੱਕ ਵਿਧੀ ਰਾਹੀਂ ਕਲਾਇੰਟ ਨੂੰ ਅੰਦਰ ਆਉਣ ਦੇ ਸਕਦੀ ਹੈ ਜਦੋਂ ਦੂਜੀ ਅਜੇ ਪਾਸ ਨਹੀਂ ਹੋਈ। ਪਹੁੰਚ ਸੂਚੀ ਨੂੰ ਟਿਕਾਣਾ ਸਮੀਖਿਆ ਚੈੱਕਲਿਸਟ ਵਿੱਚ ਰੱਖੋ।

HTTP ਇਨਕਾਰ TCP ਕਨੈਕਸ਼ਨ ਦੇ NGINX ਤੱਕ ਪਹੁੰਚਣ ਤੋਂ ਬਾਅਦ ਹੁੰਦਾ ਹੈ। ਇਹ ਨੈੱਟਵਰਕ ਪਾਬੰਦੀ ਦਾ ਪੂਰਕ ਹੈ, ਅਤੇ ਐਪ ਦਾ ਆਪਣਾ ਅਧਿਕਾਰ ਹਰ ਵਰਤੋਂਕਾਰ 'ਤੇ ਅਜੇ ਵੀ ਲਾਗੂ ਹੈ।

ਜੀਵੰਤ ਰਾਹ ਅਤੇ ਫੇਲ੍ਹ ਹੋਣ ਦੀ ਸਥਿਤੀ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ

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

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

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

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