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

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

ਮਿੱਥ: ਜੁੜਨਾ ਮਾਰਗਨ ਨਹੀਂ ਹੈ

ਇੱਕ ਟਨਲ ਸਥਾਪਿਤ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਕਲਾਇੰਟ ਕੁਝ ਪ੍ਰੀਫਿਕਸਾਂ ਲਈ ਮਾਰਗ ਸਥਾਪਿਤ ਕਰਦਾ ਹੈ। ਜੁੜਨਾ ਸਿਰਫ਼ ਇੰਨਾ ਹੀ ਕਰਦਾ ਹੈ। ਕੋਈ ਅਸੰਬੰਧਿਤ HTTPS ਬੇਨਤੀ ਟਨਲ ਵਿੱਚੋਂ ਲੰਘਦੀ ਹੈ ਜਾਂ ਨਹੀਂ, ਅਤੇ ਪਹੁੰਚਣ ’ਤੇ ਇਹ ਕਿਹੜੇ ਜਨਤਕ ਪਤੇ ਤੋਂ ਆਈ ਲੱਗਦੀ ਹੈ, ਇਹ ਫੈਸਲੇ ਬਾਅਦ ਵਿੱਚ ਹੋਰ ਹਿੱਸੇ ਲੈਂਦੇ ਹਨ: ਮਾਰਗ ਸਾਰਣੀ ਰਾਹ ਚੁਣਦੀ ਹੈ, ਅਤੇ ਐਗਰੈਸ ਸਰੋਤ ਚੁਣਦਾ ਹੈ।

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

ਤਿੰਨ ਬੇਨਤੀ ਅਵਸਥਾਵਾਂ, ਦੋ ਮਨਜ਼ੂਰ ਐਗਰੈਸ

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

Request pathSource the site seesIntended decision
Office, no tunnelOffice public exitAdmit to the application login
Remote, approved full tunnelApproved VPN egressAdmit to the same login
Remote, ordinary connectionNeither approved addressDeny at the network boundary

ਇਹਨਾਂ ਯੋਜਨਾਵਾਂ ਵਿੱਚੋਂ ਬਹੁਤੀਆਂ ਵਿਚਕਾਰਲੀ ਕਤਾਰ ’ਤੇ ਟੁੱਟਦੀਆਂ ਹਨ। ਮਹੱਤਵ ਉਸ ਪਤੇ ਦਾ ਹੈ ਜੋ ਲਾਗੂਕਰਨ ਵਾਲਾ ਯੰਤਰ ਦੇਖਦਾ ਹੈ, ਨਾ ਕਿ ਉਹ ਨਿੱਜੀ ਪਤਾ ਜੋ ਲੈਪਟਾਪ ਟਨਲ ਅੰਦਰ ਰੱਖਦਾ ਹੈ ਅਤੇ ਨਾ ਹੀ ਉਸਦਾ LAN ਪਤਾ। 10.8.0.6 ਵਰਗਾ ਮੁੱਲ ਜਨਤਕ ਸਾਈਟ ਲਈ ਕੁਝ ਨਹੀਂ ਦਰਸਾਉਂਦਾ, ਅਤੇ 192.168.1.44 ਵੀ ਨਹੀਂ। ਟਨਲ ਦਾ ਪਤਾ ਟਨਲ ਦੇ ਐਡਰੈਸਿੰਗ ਦਾ ਵੇਰਵਾ ਹੈ, ਅਜਿਹਾ ਕੋਈ ਪ੍ਰਮਾਣ ਨਹੀਂ ਜੋ ਸਾਈਟ ਜਾਂਚ ਸਕੇ।

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

ਸਰੋਤ ਉੱਥੇ ਪੜ੍ਹੋ ਜਿੱਥੇ ਫੈਸਲਾ ਲਿਆ ਜਾਂਦਾ ਹੈ

ਪਾਬੰਦੀ ਉਸ ਯੰਤਰ ’ਤੇ ਰੱਖੋ ਜੋ ਬੇਨਤੀ ਨੂੰ ਸਮਾਪਤ ਕਰਦਾ ਹੈ, ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਕੋਈ ਵਿਕਲਪਿਕ ਮੂਲ ਮਾਰਗ ਇਸ ਨੂੰ ਨਹੀਂ ਟਾਲਦਾ। Nginx ਪਹੁੰਚ ਮਾਡਿਊਲ allow ਅਤੇ deny ਨਿਰਦੇਸ਼ਾਂ ਦਾ ਕ੍ਰਮ ਅਨੁਸਾਰ ਮੁਲਾਂਕਣ ਕਰਦਾ ਹੈ, ਪਹਿਲਾ ਮੇਲ ਜਿੱਤਦਾ ਹੈ, ਅਤੇ ਘੇਰਨ ਵਾਲੇ ਬਲਾਕ ਤੋਂ ਵਿਰਾਸਤ ਵਿੱਚ ਮਿਲੇ ਨਿਯਮ location ਅੰਦਰ ਅਜੇ ਵੀ ਲਾਗੂ ਰਹਿੰਦੇ ਹਨ। ਇੱਕੋ ਥਾਂ ’ਤੇ ਤੰਗ allow ਦੇ ਕੋਲ ਚੌੜਾ allow ਹੋਣ ਦਾ ਅਰਥ ਆਮ ਤੌਰ ’ਤੇ ਇਹ ਹੁੰਦਾ ਹੈ ਕਿ ਚੌੜਾ ਫੈਸਲਾ ਕਰਦਾ ਹੈ। ਉਸ location ਦੀ ਇੱਕ ਵੀ ਲਾਈਨ ਸੰਪਾਦਿਤ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਉਸਦੀ ਪੂਰੀ ਪ੍ਰਭਾਵੀ ਸੰਰਚਨਾ ਪੜ੍ਹੋ।

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

    set_real_ip_from 10.20.0.10;
    real_ip_header X-Forwarded-For;
    real_ip_recursive on;

    location /app/ {
        allow 203.0.113.24;    # office public exit
        allow 198.51.100.77;   # approved VPN egress
        deny  all;
        proxy_pass http://app_backend;
    }
}

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

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

ਵੰਡੀ ਟਨਲ: ਉਹ ਬੇਨਤੀ ਜੋ ਕਦੇ ਅੰਦਰ ਨਹੀਂ ਆਉਂਦੀ

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

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

ਇਨਕਾਰ ਸਾਬਤ ਕਰੋ, ਫਿਰ ਬਹਾਲੀ

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

curl -sS -o /dev/null -w 'status=%{http_code}
' https://intranet.example.com/app/login
# repeat with the tunnel up, then with it down
tail -f /var/log/nginx/access.log | grep ' /app/'

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

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

ਸੰਬੰਧਿਤ ਲੇਖ