ਤੁਹਾਡੇ URL ਨੂੰ ਪੋਰਟ 80 ਜਾਂ 443 ’ਤੇ ਪ੍ਰਵੇਸ਼ ਕਿਉਂ ਚਾਹੀਦਾ ਹੈ, 45000 ’ਤੇ ਨਹੀਂ

ਬ੍ਰਾਊਜ਼ਰ ਵਿੱਚ ਹੋਸਟਨਾਮ ਲਿਖੋ ਅਤੇ ਸਕੀਮ ਮੰਜ਼ਿਲ ਪੋਰਟ ਤੈਅ ਕਰਦੀ ਹੈ: http ਲਈ 80, https ਲਈ 443। DNS ਜਵਾਬ ਵਿੱਚ ਕੁਝ ਵੀ ਇਸ ਨੂੰ ਰੱਦ ਨਹੀਂ ਕਰਦਾ, ਅਤੇ ਤੁਹਾਡੀ ਮਸ਼ੀਨ ’ਤੇ ਕੋਈ ਫਾਰਵਰਡਿੰਗ ਨਿਯਮ ਪ੍ਰਦਾਤਾ ਦੇ ਕਿਨਾਰੇ ’ਤੇ ਸਰੋਤਾ ਨਹੀਂ ਘੜ ਸਕਦਾ। ਜਦੋਂ VPN ਪ੍ਰਦਾਤਾ ਤੁਹਾਨੂੰ 45000 ਵਰਗਾ ਉੱਚਾ ਜਨਤਕ ਪੋਰਟ ਦਿੰਦਾ ਹੈ, ਤਾਂ ਸਪਸ਼ਟ URL ਕੰਮ ਕਰਦਾ ਹੈ ਅਤੇ ਸਾਫ਼ ਨਹੀਂ। ਪਾੜਾ ਪ੍ਰਵੇਸ਼ ਬਿੰਦੂ ’ਤੇ ਹੈ, ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਅੰਦਰ ਨਹੀਂ।

ਬ੍ਰਾਊਜ਼ਰ ਤੋਂ ਪ੍ਰਕਿਰਿਆ ਤੱਕ ਦਾ ਰਾਹ ਇੱਕ ਵਾਰ ਦੇਖੋ, ਅਤੇ ਤਿੰਨੇ ਪ੍ਰਕਾਸ਼ਨ ਵਿਕਲਪ ਰਹੱਸਮਈ ਲੱਗਣਾ ਬੰਦ ਕਰ ਦੇਣਗੇ।

ਦੇਖੋ ਬੇਨਤੀ ਅਸਲ ਵਿੱਚ ਕਿੱਥੇ ਜਾਂਦੀ ਹੈ

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

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

ਕੋਈ ਸਥਾਨਕ ਨਿਯਮ ਕਿਨਾਰੇ ਨੂੰ ਕਿਉਂ ਠੀਕ ਨਹੀਂ ਕਰ ਸਕਦਾ

ਐਪਲੀਕੇਸ਼ਨ ਹੋਸਟ ’ਤੇ ਰੀਡਾਇਰੈਕਟ ਜਾਂ DNAT ਨਿਯਮ ਉਹਨਾਂ ਪੈਕੇਟਾਂ ’ਤੇ ਕੰਮ ਕਰਦਾ ਹੈ ਜੋ ਪਹਿਲਾਂ ਹੀ ਆ ਚੁੱਕੇ ਹਨ। ਪ੍ਰਦਾਤਾ ’ਤੇ ਪੋਰਟ 80 ’ਤੇ ਭੇਜੇ ਪੈਕੇਟ ਕਦੇ ਨਹੀਂ ਪਹੁੰਚਦੇ, ਇਸ ਲਈ ਨਿਯਮ ਦਾ ਕਦੇ ਮੁਲਾਂਕਣ ਨਹੀਂ ਹੁੰਦਾ। ਪੂਰੀ ਸਮੱਸਿਆ ਵਿੱਚ ਇਹ ਸਭ ਤੋਂ ਆਮ ਬਰਬਾਦ ਹੋਣ ਵਾਲਾ ਘੰਟਾ ਹੈ।

DNS ਵੀ ਪੋਰਟ ਨਹੀਂ ਢੋ ਸਕਦਾ। HTTP ਵਿਸ਼ੇਸ਼ਣ ਸਕੀਮ ਦੇ ਡਿਫਾਲਟ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ, ਅਤੇ A ਜਾਂ AAAA ਰਿਕਾਰਡ ਪਤਾ ਵਾਪਸ ਕਰਦਾ ਹੈ ਜਦਕਿ CNAME ਦੂਜਾ ਨਾਮ ਵਾਪਸ ਕਰਦਾ ਹੈ। ਬ੍ਰਾਊਜ਼ਰ ਫਿਰ ਵੀ ਸਕੀਮ ਦਾ ਪੋਰਟ ਜੋੜਦਾ ਹੈ, ਇਸ ਲਈ URL ਵਿੱਚ ਸਪਸ਼ਟ ਪੋਰਟ ਹੀ ਮੰਜ਼ਿਲ ਬਦਲਦਾ ਹੈ।

ਵਿਕਲਪ ਇੱਕ: ਸਪਸ਼ਟ ਪੋਰਟ ਰੱਖੋ

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

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

ਵਿਕਲਪ ਦੋ: ਡਿਫਾਲਟ ਪੋਰਟ ’ਤੇ ਅਸਲੀ ਪ੍ਰਵੇਸ਼ ਲਵੋ

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

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

ਵਿਕਲਪ ਤਿੰਨ: ਅੱਗੇ ਇੱਕ ਫਰੰਟਐਂਡ ਰੱਖੋ

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

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

ਇੱਕੋ ਮੂਲ ਰੱਖੋ

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

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