HAProxy 302 ਤੋਂ ਇੱਕ ਨਿੱਜੀ ਐਪ ਤੱਕ: ਦੂਜੀ ਛਲਾਂਗ ਕੌਣ ਖੋਲ੍ਹਦਾ ਹੈ?

ਰੀਡਾਇਰੈਕਟ ਦੂਜਾ ਕਨੈਕਸ਼ਨ ਬ੍ਰਾਊਜ਼ਰ ਨੂੰ ਵਾਪਸ ਦਿੰਦਾ ਹੈ। ਇਸ ਦੀ ਬਜਾਏ ਬੇਨਤੀ backend ਨੂੰ ਭੇਜੋ, ਫਿਰ ਐਪ ਦੇ ਆਪਣੇ ਪੂਰਨ ਰੀਡਾਇਰੈਕਟ ਅਤੇ ਕੂਕੀਜ਼ ਠੀਕ ਕਰੋ।

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

ਕਨਫਿਗਰੇਸ਼ਨ ਵਿੱਚ ਇੱਕੋ ਜਿਹੇ ਦਿਸਦੇ ਦੋ ਰਾਹ

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

GET /app        client -> proxy
302 Location    proxy  -> client   (http://10.40.0.20:8080/)
GET /app        client -> 10.40.0.20:8080   client network, no route

ਪ੍ਰੌਕਸੀ ਦਾ backend ਦੂਜਾ ਪੜਾਅ ਸਰਵਰ ਵਾਲੇ ਪਾਸੇ ਰੱਖਦਾ ਹੈ। ਪ੍ਰੌਕਸੀ ਇਸਨੂੰ ਉਸੇ ਰਾਹ ਰਾਹੀਂ ਖੋਲ੍ਹਦੀ ਹੈ ਜੋ ਉਸ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਹੈ, ਅਤੇ ਕਲਾਇੰਟ ਇੱਕ ਜਨਤਕ ਨਾਮ ਨਾਲ ਗੱਲ ਕਰਦਾ ਰਹਿੰਦਾ ਹੈ। ਜੇ ਟਨਲ ਡਿੱਗੇ, ਕਲਾਇੰਟ ਨੂੰ ਉਸ URL ਦੀ ਬਜਾਏ ਗਲਤੀ ਮਿਲਦੀ ਹੈ ਜਿਸਦਾ ਉਹ ਪਿੱਛਾ ਨਹੀਂ ਕਰ ਸਕਦਾ। ਇਹੀ ਅੰਤਰ ਨੁਕਸ ਨੂੰ ਨਿਦਾਨਯੋਗ ਬਣਾਉਂਦਾ ਹੈ, ਕਿਉਂਕਿ ਗਲਤੀ ਉੱਥੇ ਦਿਸਦੀ ਹੈ ਜਿੱਥੇ ਲੌਗ ਹੁੰਦੇ ਹਨ:

GET /app        client -> proxy
GET /app        proxy  -> 10.40.0.20:8080   over the VPN
response        proxy  -> client

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

ਬ੍ਰਾਊਜ਼ਰ ਨੂੰ ਕੀ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਸਰਵਰ ਦਾ VPN ਉਸਨੂੰ ਕੀ ਨਹੀਂ ਦਿੰਦਾ

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

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

ਜਦੋਂ ਸਿਰਫ਼ ਪ੍ਰੌਕਸੀ ਹੀ ਐਪ ਤੱਕ ਪਹੁੰਚ ਸਕਦੀ ਹੈ

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

backend private_app
    mode http
    option httpchk GET /health
    server app1 10.40.0.20:8080 check

ਉਸ ਬਲਾਕ ਨੂੰ ਪ੍ਰੌਕਸੀ ਦੀ ਰੂਟਿੰਗ ਟੇਬਲ ਬਾਰੇ ਬਿਆਨ ਵਜੋਂ ਪੜ੍ਹੋ: 10.40.0.20 ਪ੍ਰੌਕਸੀ ਹੋਸਟ ਤੋਂ ਹੀ ਪਹੁੰਚਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਜਿਸਦਾ ਇੱਥੇ ਅਰਥ ਹੈ ਡਿਫਾਲਟ ਰੂਟ ਦੀ ਬਜਾਏ VPN ਇੰਟਰਫੇਸ ਰਾਹੀਂ। check ਕੀਵਰਡ ਸਿਰਫ਼ ਦੱਸਦਾ ਹੈ ਕਿ ਉਹ ਰੂਟ ਕੀ ਕਰਦਾ ਹੈ, ਅਤੇ ਸਿਹਤ ਮਾਰਗ ਐਪ 'ਤੇ ਹੋਣਾ ਲਾਜ਼ਮੀ ਹੈ, ਨਹੀਂ ਤਾਂ ਹਰ ਜਾਂਚ ਸਰਵਰ ਨੂੰ ਡਾਊਨ ਚਿੰਨ੍ਹਿਤ ਕਰਦੀ ਹੈ। ਸਫਲ ਜਾਂਚ ਕਲਾਇੰਟ ਬਾਰੇ ਕੁਝ ਸਾਬਤ ਨਹੀਂ ਕਰਦੀ ਅਤੇ ਉਸ ਨੀਤੀ ਦੀ ਥਾਂ ਨਹੀਂ ਲੈਂਦੀ ਜੋ ਤੈਅ ਕਰਦੀ ਹੈ ਕਿ backend ਕੌਣ ਵਰਤ ਸਕਦਾ ਹੈ।

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

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

ਐਪ ਦੇ ਆਪਣੇ ਰੀਡਾਇਰੈਕਟ ਅਜੇ ਵੀ ਅੰਦਰ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੇ ਹਨ

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

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

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

ਤੁਹਾਡੇ ਕੋਲ ਅਸਲ ਵਿੱਚ ਕਿਹੜਾ ਡਿਜ਼ਾਈਨ ਹੈ, ਇਹ ਤੈਅ ਕਰੋ

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

ਵਰਤੋਂਕਾਰਾਂ ਦੇ ਨੈੱਟਵਰਕ ਦੀ ਮਸ਼ੀਨ ਤੋਂ ਜਾਂਚ ਚਲਾਓ ਅਤੇ ਬ੍ਰਾਊਜ਼ਰ ਵੱਲੋਂ ਕੀਤੀ ਹਰ ਛਲਾਂਗ ਦਾ ਪਿੱਛਾ ਕਰੋ, ਸਿਰਫ਼ ਪਹਿਲੇ ਜਵਾਬ ਦਾ ਨਹੀਂ। ਪਤਾ ਪੱਟੀ ਅਤੇ ਹਰ ਅਗਲੀ ਬੇਨਤੀ 'ਤੇ ਨਜ਼ਰ ਰੱਖੋ, ਕਿਉਂਕਿ ਐਸੈਟ ਟੈਗ ਵਿੱਚ ਇੱਕ ਪੂਰਨ URL ਹੀ ਉਸ ਪ੍ਰਵਾਹ ਨੂੰ ਤੋੜਨ ਲਈ ਕਾਫ਼ੀ ਹੈ ਜੋ ਪਹਿਲੀ ਛਲਾਂਗ ਪਾਰ ਕਰ ਗਈ ਸੀ। ਸਾਈਨ-ਇਨ ਜਨਤਕ ਨਾਮ ਰਾਹੀਂ ਕੰਮ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਜਿਹਨਾਂ ਸਰੋਤਾਂ ਨੂੰ ਨਾਂਹ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ ਉਹ ਨਾਂਹ ਹੀ ਰਹਿਣ।

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

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

ਸੰਬੰਧਿਤ ਲੇਖ