ਇੱਕ OpenVPN ਪ੍ਰੋਫਾਈਲ ਘਰ ਵਿੱਚ ਕਿਉਂ ਕੰਮ ਕਰਦੀ ਹੈ ਪਰ ਹੋਟਲ ਵਿੱਚ ਕਿਉਂ ਫੇਲ ਹੁੰਦੀ ਹੈ

ਦਫ਼ਤਰ ਦਾ Wi-Fi ਅਤੇ ਹੋਟਲ ਦਾ ਕਮਰਾ ਇੱਕੋ ਲੈਪਟਾਪ ਨੂੰ ਦੋ ਬਿਲਕੁਲ ਵੱਖਰੇ ਨੈੱਟਵਰਕ ਦੇ ਸਕਦੇ ਹਨ, ਅਤੇ ਵਿਚਕਾਰਲੇ ਪ੍ਰੋਫਾਈਲ ਨੂੰ ਇਸ ਬਾਰੇ ਕੁਝ ਪਤਾ ਨਹੀਂ ਹੁੰਦਾ। ਘਰ ਵਿੱਚ ਜੋ ਕੰਮ ਕਰਦਾ ਹੈ ਉਹ ਖੁੱਲ੍ਹੇ ਅਪਲਿੰਕ, ਕੰਮ ਕਰਦੇ ਨਾਮ-ਹੱਲ ਅਤੇ ਅਜਿਹੇ ਸਥਾਨਕ ਸਬਨੈੱਟ ਦੀ ਧਾਰਨਾ ਲੈਂਦਾ ਹੈ ਜੋ ਟਨਲ ਦੁਆਰਾ ਲਿਜਾਈ ਕਿਸੇ ਵੀ ਚੀਜ਼ ਨਾਲ ਨਹੀਂ ਟਕਰਾਉਂਦਾ। ਇਹਨਾਂ ਵਿੱਚੋਂ ਹਰ ਧਾਰਨਾ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਫੇਲ ਹੋ ਸਕਦੀ ਹੈ।

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

ਚਾਰ ਨੈੱਟਵਰਕ ਤੱਥ ਥਾਵਾਂ ਵਿਚਕਾਰ ਬਦਲਦੇ ਹਨ

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

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

ਤੀਜਾ ਆਵਾਜਾਈ ਫਿਲਟਰਿੰਗ ਹੈ। ਜੋ ਨੈੱਟਵਰਕ ਸਿਰਫ਼ ਬ੍ਰਾਊਜ਼ਿੰਗ ਦੀ ਆਗਿਆ ਦੇਣਾ ਚਾਹੁੰਦੇ ਹਨ ਉਹ TCP 443 ਨੂੰ ਕਿਸੇ ਵੀ ਮੰਜ਼ਿਲ ਤੱਕ ਜਾਣ ਦਿੰਦੇ ਹਨ ਅਤੇ UDP ਸਮੇਤ ਲਗਭਗ ਬਾਕੀ ਸਭ ਕੁਝ ਸੁੱਟ ਦਿੰਦੇ ਹਨ।

ਚੌਥਾ ਪਤਾ-ਨਿਰਧਾਰਣ ਹੈ। ਸਥਾਨਕ ਸਬਨੈੱਟ ਟਨਲ ਦੇ ਪਿੱਛੇ ਦੇ ਨੈੱਟਵਰਕ ਨਾਲ ਓਵਰਲੈਪ ਹੋ ਸਕਦਾ ਹੈ, ਜਾਂ ਅਪਲਿੰਕ ਕੋਈ ਵੀ ਵਰਤੋਂਯੋਗ IPv4 ਰਾਹ ਨਹੀਂ ਦੇ ਸਕਦਾ।

ਨਾਮ-ਹੱਲ ਅਤੇ ਕੈਪਟਿਵ ਪੋਰਟਲ

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

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

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

ਆਵਾਜਾਈ ਫਿਲਟਰਿੰਗ: ਪਹਿਲਾਂ UDP, ਬੈਕਅੱਪ ਵਜੋਂ TCP 443

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

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

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

ਪਤਾ ਟਕਰਾਅ ਅਤੇ IPv4 ਰਹਿਤ ਅਪਲਿੰਕ

ਟਨਲ ਸਥਾਪਿਤ ਹੋ ਕੇ ਵੀ ਕੁਝ ਨਹੀਂ ਢੋ ਸਕਦੀ। ਜਦੋਂ ਸਥਾਨਕ LAN ਅਤੇ ਦੂਰ ਦਾ ਨੈੱਟਵਰਕ 192.168.1.0/24 ਵਰਗਾ ਅਗੇਤਰ ਸਾਂਝਾ ਕਰਦੇ ਹਨ, ਕਲਾਇੰਟ ਦੂਰ ਦੇ ਹੋਸਟ ਨੂੰ ਸਿੱਧਾ ਜੁੜਿਆ ਮੰਨਦਾ ਹੈ ਅਤੇ ਪੈਕਟ ਨੂੰ ਟਨਲ ਦੀ ਬਜਾਏ ਸਥਾਨਕ ਲਿੰਕ 'ਤੇ ਭੇਜਦਾ ਹੈ। ਲੱਛਣ ਇੱਕ ਅਪਹੁੰਚ ਸਬਨੈੱਟ ਵਾਲਾ ਸਫਲ ਕਨੈਕਸ਼ਨ ਹੈ, ਜਿਸ ਨੂੰ ਸਰਵਰ-ਪਾਸੇ ਦੀ ਰੂਟ ਸਮੱਸਿਆ ਵਜੋਂ ਗਲਤ ਪੜ੍ਹਨਾ ਸੌਖਾ ਹੈ।

ਪੱਕਾ ਹੱਲ ਇਹ ਹੈ ਕਿ ਦੂਰ ਦੇ LAN ਨੂੰ ਅਸਾਧਾਰਨ ਨਿੱਜੀ ਰੇਂਜ ਵਿੱਚ ਭੇਜਿਆ ਜਾਵੇ। ਅਜਿਹੀ ਰੇਂਜ ਚੁਣਨਾ ਜੋ ਘਰ ਵਿੱਚ ਕੋਈ ਨਹੀਂ ਵਰਤਦਾ, ਜਿਵੇਂ 10.42.0.0/24, ਸਮੱਸਿਆ ਨੂੰ ਇੱਕ ਦੀ ਬਜਾਏ ਹਰ ਭਵਿੱਖੀ ਥਾਂ ਲਈ ਰੋਕਦਾ ਹੈ। ਸਥਾਨਕ ਜੁਗਾੜ ਉਸ ਹੋਟਲ, ਹਾਟਸਪਾਟ ਜਾਂ ਰਾਊਟਰ ਤੋਂ ਬਚਣਾ ਹੈ, ਜੋ ਕੋਈ ਹੱਲ ਨਹੀਂ।

ਮੋਬਾਈਲ ਅਪਲਿੰਕ ਦੋ ਭਿੰਨਤਾਵਾਂ ਜੋੜਦੇ ਹਨ। ਕੈਰੀਅਰ-ਗ੍ਰੇਡ NAT ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਅੰਦਰ ਆਉਣ ਵਾਲੇ ਕਨੈਕਸ਼ਨ ਨਹੀਂ ਪਹੁੰਚਦੇ, ਜੋ ਸਰਵਰ ਹੋਸਟ ਕਰਨ ਵੇਲੇ ਮਹੱਤਵਪੂਰਨ ਹੈ ਪਰ ਬਾਹਰ ਜਾਣ ਵਾਲੇ ਕਲਾਇੰਟ ਲਈ ਨਹੀਂ। NAT64 ਅਨੁਵਾਦ ਨਾਲ ਸਿਰਫ਼ IPv6 ਵਜੋਂ ਕਨਫਿਗਰ ਕੀਤਾ APN ਉਸ ਕਲਾਇੰਟ ਨੂੰ ਫੇਲ ਕਰ ਸਕਦਾ ਹੈ ਜੋ ਅਸਲੀ IPv4 ਰਾਹ 'ਤੇ ਜ਼ੋਰ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਆਮ ਇਲਾਜ APN ਪ੍ਰੋਟੋਕਾਲ ਨੂੰ IPv4 ਜਾਂ ਦੋਹਰੇ ਸਟੈਕ ਵਿੱਚ ਬਦਲਣਾ ਹੈ।

ਟਨਲ ਉੱਠਣ ਤੋਂ ਬਾਅਦ ਦੇ ਲੱਛਣ

ਜੁੜ ਕੇ ਫਿਰ ਚੁੱਪ ਹੋ ਜਾਣ ਵਾਲੀ ਟਨਲ ਆਮ ਤੌਰ 'ਤੇ keepalive ਜਾਂ MTU ਸਮੱਸਿਆ ਹੈ, ਰੋਕਿਆ ਪੋਰਟ ਨਹੀਂ। ਨਿਸ਼ਚਿਤ ਮਿੰਟਾਂ ਬਾਅਦ ਡਿੱਗਣ ਵਾਲਾ ਕਨੈਕਸ਼ਨ keepalive ਜਾਂ ਮੁੜ-ਵਿਚਾਰ ਟਾਈਮਰ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ। ਕਲਾਇੰਟ ਨੂੰ ਆਪਣੇ ਸਾਥੀ ਦੀ ਜਾਂਚ ਕਰਨ ਅਤੇ ਜਵਾਬ ਰੁਕਣ 'ਤੇ ਮੁੜ ਸ਼ੁਰੂ ਕਰਨ ਲਈ ਸੈੱਟ ਕਰੋ, ਅਤੇ ਜੇ ping ਸਫਲ ਹੋਣ ਪਰ ਵੱਡੇ ਸਥਾਨਾਂਤਰਨ ਅਟਕਣ ਤਾਂ ਛੋਟਾ ਟਨਲ MTU ਜਾਂਚੋ।

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