ਕੈਪਟਿਵ ਪੋਰਟਲ ਤੁਹਾਡੇ VPN ਨੂੰ ਕਿਉਂ ਰੋਕਦਾ ਹੈ, ਅਤੇ ਦੁਬਾਰਾ ਸਾਈਨ ਇਨ ਕਿਵੇਂ ਕਰੀਏ
ਜਨਤਕ Wi-Fi ਤੁਹਾਡੇ ਡਿਵਾਈਸ ਨੂੰ ਇਸ ਤੋਂ ਇੱਕ ਵੀ ਪੈਕੇਟ ਨਿਕਲਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਮਨਜ਼ੂਰੀ ਦਿੰਦਾ ਹੈ। ਪੋਰਟਲ ਕੀ ਸੁੱਟਦਾ ਹੈ, ਤੁਹਾਡਾ VPN ਇਸ ਨੂੰ ਕਿਉਂ ਗਲਤ ਢੰਗ ਨਾਲ ਰਿਪੋਰਟ ਕਰਦਾ ਹੈ, ਅਤੇ ਕਿਹੜੇ ਕ੍ਰਮ ਵਿੱਚ ਤੁਹਾਨੂੰ ਦੁਬਾਰਾ ਜੋੜਦਾ ਹੈ।
ਖੁੱਲ੍ਹੇ ਨੈੱਟਵਰਕ 'ਤੇ ਤੁਹਾਡਾ ਐਕਸੈਸ ਪੁਆਇੰਟ ਪੈਕੇਟਾਂ ਨੂੰ ਸਿੱਧਾ ਇੰਟਰਨੈੱਟ ਨੂੰ ਨਹੀਂ ਸੌਂਪਦਾ। ਉੱਪਰਲਾ ਨੀਤੀ ਬਿੰਦੂ ਜਾਂਚਦਾ ਹੈ ਕਿ ਤੁਹਾਡੇ ਡਿਵਾਈਸ ਨੂੰ ਅਜੇ ਮਨਜ਼ੂਰੀ ਮਿਲੀ ਹੈ ਜਾਂ ਨਹੀਂ, ਅਤੇ ਜਦੋਂ ਤੱਕ ਨਹੀਂ ਮਿਲਦੀ, ਲਗਭਗ ਸਭ ਕੁਝ ਸੁੱਟ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ। ਤੁਹਾਡਾ VPN ਕਲਾਇੰਟ ਉਸ ਖ਼ਾਮੋਸ਼ੀ ਨੂੰ ਮਰੇ ਸਰਵਰ ਵਜੋਂ ਪੜ੍ਹਦਾ ਹੈ। ਇਹ ਇਹ ਗੱਲ ਕਦੇ-ਕਦਾਈਂ ਹੀ ਕਹਿੰਦਾ ਹੈ: WireGuard ਖਾਲੀ ਥਾਂ ਵਿੱਚ ਹੈਂਡਸ਼ੇਕ ਦੁਹਰਾਉਂਦਾ ਹੈ, OpenVPN ਕਨੈਕਸ਼ਨ ਟਾਈਮਆਊਟ ਦੀ ਰਿਪੋਰਟ ਕਰਦਾ ਹੈ, ਅਤੇ IKEv2 ਜਵਾਬ ਨਾ ਦੇਣ ਵਾਲੇ ਦੂਰ ਦੇ ਸਰਵਰ ਬਾਰੇ ਗਲਤੀ 809 ਨਾਲ ਵਾਪਸ ਆਉਂਦਾ ਹੈ।
ਪੋਰਟਲ ਅਸਲ ਵਿੱਚ ਕੀ ਨਿਯੰਤਰਿਤ ਕਰਦਾ ਹੈ
ਕੈਪਟਿਵ ਪੋਰਟਲ ਦੋ ਚੀਜ਼ਾਂ ਹਨ ਜੋ ਇੱਕਠੀਆਂ ਚਿਪਕੀਆਂ ਹੋਈਆਂ ਹਨ: ਨੀਤੀ ਫ਼ੈਸਲਾ ਬਿੰਦੂ ਅਤੇ ਰੀਡਾਇਰੈਕਟਰ। ਜਦੋਂ ਤੁਹਾਡਾ ਡਿਵਾਈਸ ਜੁੜਦਾ ਹੈ ਅਤੇ DHCP ਲੀਜ਼ ਲੈਂਦਾ ਹੈ, ਨੈੱਟਵਰਕ ਤੁਹਾਨੂੰ ਮਨਜ਼ੂਰੀ ਤੋਂ ਪਹਿਲਾਂ ਦੀ ਹਾਲਤ ਵਿੱਚ ਰੱਖਦਾ ਹੈ।
ਉਹ ਹਾਲਤ ਫਾਇਰਵਾਲ ਨਿਯਮਾਂ ਦਾ ਸਮੂਹ ਹੈ। ਇਹ ਆਮ ਤੌਰ 'ਤੇ DNS ਨੂੰ ਮਨਜ਼ੂਰੀ ਦਿੰਦਾ ਹੈ ਅਤੇ ਪੋਰਟਲ ਹੋਸਟਾਂ ਦੀ ਛੋਟੀ ਸੂਚੀ ਤੱਕ HTTP ਜਾਂ HTTPS ਨੂੰ ਮਨਜ਼ੂਰੀ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਬਾਕੀ ਸਭ ਕੁਝ ਸੁੱਟ ਦਿੰਦਾ ਹੈ। ਮਨਜ਼ੂਰ ਸੂਚੀ ਕੰਧਾਂ ਨਾਲ ਘਿਰਿਆ ਬਾਗ਼ ਹੈ, ਅਤੇ ਇਸ ਵਿੱਚ ਲਗਭਗ ਕਦੇ ਵੀ VPN ਅੰਤ ਬਿੰਦੂ ਸ਼ਾਮਲ ਨਹੀਂ ਹੁੰਦਾ।
ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਸੁੱਟਣਾ ਨਿਮਰ ਨਹੀਂ ਹੈ। VPN ਸਰਵਰ ਵੱਲ ਭੇਜੇ ਪੈਕੇਟ ਨਾਮਨਜ਼ੂਰ ਕਰਨ ਦੀ ਬਜਾਏ ਸੁੱਟ ਦਿੱਤੇ ਜਾਂਦੇ ਹਨ, ਇਸ ਲਈ ਕਲਾਇੰਟ ਨੂੰ ਨ ICMP unreachable ਮਿਲਦਾ ਹੈ ਨ TCP reset, ਸਿਰਫ਼ ਜਵਾਬ ਦੀ ਗੈਰਹਾਜ਼ਰੀ ਮਿਲਦੀ ਹੈ। ਵਿਕਰੇਤਾ ਅਨੁਸਾਰ ਰੀਡਾਇਰੈਕਟਰ ਪੋਰਟ 80 'ਤੇ ਸਾਈਨ-ਇਨ ਪੰਨੇ ਵੱਲ ਰੀਡਾਇਰੈਕਟ ਨਾਲ ਜਵਾਬ ਦੇ ਸਕਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਪੋਰਟ 443 ਸੁੱਟਿਆ ਜਾਂ ਰੋਕਿਆ ਜਾਂਦਾ ਹੈ। ਰੀਡਾਇਰੈਕਟ ਪਛਾਣਨੇ ਸੌਖੇ ਹਨ ਕਿਉਂਕਿ ਉਹ ਸਾਧਾਰਨ HTTP ਜਵਾਬ ਲੈ ਕੇ ਜਾਂਦੇ ਹਨ; 443 'ਤੇ ਰੋਕਣ ਲਈ ਉਹ ਸਰਟੀਫਿਕੇਟ ਚਾਹੀਦਾ ਹੈ ਜਿਸ 'ਤੇ ਤੁਹਾਡਾ ਬ੍ਰਾਊਜ਼ਰ ਭਰੋਸਾ ਕਰਨ ਤੋਂ ਇਨਕਾਰ ਕਰੇਗਾ।
ਮਨਜ਼ੂਰੀ ਆਪਣੇ ਆਪ ਵਿੱਚ ਆਮ ਤੌਰ 'ਤੇ ਡਿਵਾਈਸ ਦੇ MAC ਪਤੇ ਨਾਲ ਜੁੜੀ ਹੁੰਦੀ ਹੈ, ਕਦੇ-ਕਦਾਈਂ ਲੀਜ਼ ਕੀਤੇ IP ਨਾਲ, ਅਤੇ ਇਹ ਟਾਈਮਰ ਵਾਲੀ ਸੈਸ਼ਨ ਸਾਰਣੀ ਵਿੱਚ ਰਹਿੰਦੀ ਹੈ। ਸਾਈਨ ਇਨ ਕਰਨ ਨਾਲ ਇੱਕ ਐਂਟਰੀ ਬਣਦੀ ਹੈ। ਜੋ ਫਾਇਰਵਾਲ ਨਿਯਮ ਤੁਹਾਡੇ ਟ੍ਰੈਫਿਕ ਨੂੰ ਲੰਘਣ ਦਿੰਦਾ ਹੈ ਉਹ ਸਿਰਫ਼ ਉਦੋਂ ਤੱਕ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਤੱਕ ਉਹ ਐਂਟਰੀ ਹੈ, ਅਤੇ ਇਸੇ ਲਈ ਤੁਹਾਡੇ ਪਾਸੇ ਕੁਝ ਵੀ ਬਦਲੇ ਬਿਨਾਂ ਪੂਰੀ ਸਮੱਸਿਆ ਬਾਅਦ ਵਿੱਚ ਵਾਪਸ ਆਉਂਦੀ ਹੈ।
VPN ਹੈਂਡਸ਼ੇਕ ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਕਿਉਂ ਮਰ ਜਾਂਦਾ ਹੈ
ਹਰ ਪ੍ਰੋਟੋਕੋਲ ਦਾ ਆਪਣਾ ਆਵਾਜਾਈ ਸਾਧਨ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਮਨਜ਼ੂਰੀ ਤੋਂ ਪਹਿਲਾਂ ਦਾ ਫਾਇਰਵਾਲ ਹਰ ਇੱਕ ਨੂੰ ਵੱਖਰੇ ਢੰਗ ਨਾਲ ਤੋੜਦਾ ਹੈ। Windows ਅਤੇ iOS 'ਤੇ IKEv2 UDP 500 ਅਤੇ UDP 4500 'ਤੇ ਚੱਲਦਾ ਹੈ; ਉਹਨਾਂ ਪੋਰਟਾਂ 'ਤੇ ਸੁੱਟਣਾ 809 ਵਜੋਂ, ਜਾਂ ਪੜਾਅ ਵੱਖਰੇ ਰਿਪੋਰਟ ਕਰਨ ਵਾਲੇ ਕਲਾਇੰਟਾਂ 'ਤੇ ਨਾਮ-ਹੱਲ ਵਰਗੀ ਅਸਫਲਤਾ ਵਜੋਂ ਦਿਖਦਾ ਹੈ। UDP 1194 'ਤੇ OpenVPN ਆਪਣਾ ਸਮਾਂ ਖ਼ਤਮ ਹੋਣ ਤੱਕ ਜੁੜਨ ਦੀ ਹਾਲਤ ਵਿੱਚ ਰਹਿੰਦਾ ਹੈ। TCP 443 'ਤੇ OpenVPN ਦਿਲਚਸਪ ਮਾਮਲਾ ਹੈ, ਕਿਉਂਕਿ ਪੋਰਟਲ TCP ਹੈਂਡਸ਼ੇਕ ਪੂਰਾ ਕਰਕੇ ਫਿਰ ਆਪਣੇ ਰੀਡਾਇਰੈਕਟ ਪੰਨੇ ਨਾਲ ਜਵਾਬ ਦੇ ਸਕਦਾ ਹੈ, ਇਸ ਲਈ ਤੁਹਾਨੂੰ ਟਾਈਮਆਊਟ ਦੀ ਬਜਾਏ TLS ਗਲਤੀ ਦਿਖਦੀ ਹੈ।
WireGuard ਇਹ ਕਾਰਜਵਿਧੀ ਸਭ ਤੋਂ ਸਾਫ਼ ਦਿਖਾਉਂਦਾ ਹੈ। ਇਹ ਡਿਜ਼ਾਈਨ ਅਨੁਸਾਰ ਸਿਰਫ਼ UDP ਹੈ, TCP ਵਿਕਲਪ ਨਹੀਂ, ਇਸ ਲਈ ਅਣਜਾਣ UDP ਸੁੱਟਣ ਵਾਲਾ ਫਾਇਰਵਾਲ ਆਵਾਜਾਈ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਹਟਾ ਦਿੰਦਾ ਹੈ। ਕਲਾਇੰਟ ਵਧਦੇ ਵਕਫ਼ੇ ਨਾਲ ਹੈਂਡਸ਼ੇਕ ਸ਼ੁਰੂਆਤ ਭੇਜਦਾ ਰਹਿੰਦਾ ਹੈ ਅਤੇ ਕਦੇ ਪੂਰਾ ਨਾ ਹੋਣ ਵਾਲੇ ਹੈਂਡਸ਼ੇਕ ਦੀ ਰਿਪੋਰਟ ਕਰਦਾ ਹੈ। ਉਸ ਸੁਨੇਹੇ ਵਿੱਚ ਕਿਤੇ ਵੀ Wi-Fi ਦਾ ਜ਼ਿਕਰ ਨਹੀਂ, ਅਤੇ ਇਸ ਵਿੱਚ ਬ੍ਰਾਊਜ਼ਰ ਖੋਲ੍ਹਣ ਦਾ ਕੋਈ ਸੰਕੇਤ ਨਹੀਂ।
ਪਲੇਟਫਾਰਮ ਤੁਹਾਡੇ VPN ਤੋਂ ਪਹਿਲਾਂ ਹਾਲਤ ਭਾਂਪਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ। Windows ਸਾਈਨ-ਇਨ ਸੂਚਨਾ ਦਿਖਾਉਣੀ ਹੈ ਜਾਂ ਨਹੀਂ ਇਹ ਤੈਅ ਕਰਨ ਲਈ ਜਾਣਿਆ URL ਲਿਆਉਂਦਾ ਹੈ, Android ਉਹ ਅੰਤ ਬਿੰਦੂ ਮੰਗਦਾ ਹੈ ਜਿਸ ਨੂੰ 204 No Content ਦਾ ਜਵਾਬ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ Apple ਡਿਵਾਈਸ ਛੋਟੀ ਕੈਪਟਿਵ-ਨੈੱਟਵਰਕ ਵਿੰਡੋ ਖੋਲ੍ਹਦੇ ਹਨ। ਉਹ ਪ੍ਰੋਬ ਕੰਮ ਕਰਦੇ ਹਨ ਕਿਉਂਕਿ ਪੋਰਟਲ ਉਮੀਦ ਕੀਤੇ ਮੁੱਖ ਹਿੱਸੇ ਦੀ ਬਜਾਏ ਰੀਡਾਇਰੈਕਟ ਨਾਲ ਜਵਾਬ ਦਿੰਦਾ ਹੈ। ਇਹੀ ਵਿਵਹਾਰ ਸਮਝਾਉਂਦਾ ਹੈ ਕਿ ਪੋਰਟਲ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸਿਹਤਮੰਦ ਕਿਵੇਂ ਦਿਖ ਸਕਦਾ ਹੈ ਜਦੋਂ ਕਿ ਤੁਹਾਡਾ ਟਨਲ ਮਰਿਆ ਹੈ: ਪ੍ਰੋਬ ਅਤੇ ਟਨਲ ਵੱਖਰੇ ਨਿਯਮਾਂ ਨਾਲ ਪਰਖੇ ਜਾਂਦੇ ਹਨ।
ਸੈਸ਼ਨ ਦੀ ਸਮਾਪਤੀ ਅਸਲ ਵਿੱਚ ਕੀ ਰੀਸੈਟ ਕਰਦੀ ਹੈ
ਥਾਵਾਂ ਤੁਹਾਡੇ VPN ਖਾਤੇ ਨਾਲ ਅਸੰਬੰਧਿਤ ਕਾਰਨਾਂ ਕਰਕੇ ਸੈਸ਼ਨ ਖ਼ਤਮ ਕਰਦੀਆਂ ਹਨ: ਨਿਸ਼ਕਿਰਿਆ ਦਾ ਸਮਾਂ, ਸੈਸ਼ਨ ਦੀ ਵੱਧ ਤੋਂ ਵੱਧ ਲੰਬਾਈ, ਨਵੀਂ DHCP ਲੀਜ਼, ਜਾਂ ਕਿਸੇ ਹੋਰ ਐਕਸੈਸ ਪੁਆਇੰਟ 'ਤੇ ਦੁਬਾਰਾ ਜੁੜਨਾ। ਟਾਈਮਰ ਵੱਜਣ 'ਤੇ ਸੈਸ਼ਨ ਸਾਰਣੀ ਦੀ ਐਂਟਰੀ ਗਾਇਬ ਹੋ ਜਾਂਦੀ ਹੈ ਅਤੇ ਮਨਜ਼ੂਰੀ ਤੋਂ ਪਹਿਲਾਂ ਦਾ ਨਿਯਮ ਸਮੂਹ ਚੈੱਕ-ਇਨ ਵੇਲੇ ਵਾਂਗ ਹੀ ਵਾਪਸ ਆਉਂਦਾ ਹੈ।
ਸਥਾਪਿਤ ਟਨਲ ਅਕਸਰ ਸਿਹਤਮੰਦ ਦਿਖਣ ਲਈ ਕਾਫ਼ੀ ਸਮਾਂ ਟਿਕਦਾ ਹੈ। ਜੀਵਤ-ਰੱਖਿਅਕ ਸੁਨੇਹੇ ਬਾਹਰ ਜਾਂਦੇ ਰਹਿੰਦੇ ਹਨ, ਅਤੇ ਕਲਾਇੰਟ ਇਸ ਨੂੰ ਨੋਟਿਸ ਕਰਦਾ ਹੈ ਜਾਂ ਨਹੀਂ ਇਹ ਇਸ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਕਿ ਉਹ ਬਿਨਾਂ ਜਵਾਬ ਵਾਲੇ ਟ੍ਰੈਫਿਕ ਨਾਲ ਕਿਵੇਂ ਨਜਿੱਠਦਾ ਹੈ, ਇਸ ਲਈ ਰਸਤਾ ਜਾਣ ਤੋਂ ਬਾਅਦ ਵੀ ਸਥਿਤੀ ਬੱਤੀ ਕੁਝ ਸਮਾਂ ਹਰੀ ਰਹਿ ਸਕਦੀ ਹੈ। ਫਿਰ ਟਨਲ ਡਿੱਗਦਾ ਹੈ ਅਤੇ ਦੁਬਾਰਾ ਜੁੜਨ ਦੀ ਹਰ ਕੋਸ਼ਿਸ਼ ਉਹਨਾਂ ਹੀ ਰੋਕੇ ਪੋਰਟਾਂ 'ਤੇ ਅਸਫਲ ਹੁੰਦੀ ਹੈ।
ਉਸ ਪਲ ਕਲਾਇੰਟ ਦੀ ਗਲਤੀ ਤੁਹਾਨੂੰ ਦੱਸਦੀ ਹੈ ਕਿ ਤੁਸੀਂ ਕਿਸ ਪੜਾਅ 'ਤੇ ਹੋ, ਜੇ ਤੁਸੀਂ ਇਸ ਨੂੰ ਧਿਆਨ ਨਾਲ ਪੜ੍ਹੋ:
| Symptom | What it means | Next check |
|---|---|---|
| Handshake times out with no reply | Pre-authorization drop on UDP | Load any HTTP page and see whether the portal appears |
| Immediate TLS error on 443 | The portal answered your TCP connection | Authorize, then retry the same profile |
| Authentication rejected | Your credentials reached the server | The network is fine, so treat this as an account problem |
| Connects, then drops repeatedly | Session or lease churn | Watch the portal timer and the lease time |
ਇੱਕ ਵੇਰਵਾ ਲੋਕਾਂ ਨੂੰ ਉਲਝਾਉਂਦਾ ਹੈ: ਜਦੋਂ ਸੈਸ਼ਨ MAC ਪਤੇ ਨਾਲ ਬੱਝੀ ਹੁੰਦੀ ਹੈ, ਸਾਈਨ-ਇਨ ਪੰਨਾ ਦੁਬਾਰਾ ਲੋਡ ਕਰਨ ਨਾਲ ਮਦਦ ਨਹੀਂ ਹੋ ਸਕਦੀ। ਤੁਹਾਨੂੰ ਜੁੜਾਅ ਛੱਡ ਕੇ ਦੁਬਾਰਾ ਜੁੜਨਾ ਪਵੇਗਾ, ਤਾਂ ਜੋ ਪੋਰਟਲ ਖ਼ਤਮ ਹੋਈ ਕੋਸ਼ਿਸ਼ ਦੀ ਬਜਾਏ ਨਵੀਂ ਮਨਜ਼ੂਰੀ ਕੋਸ਼ਿਸ਼ ਦੇਖੇ।
ਪਹਿਲਾਂ ਸਾਈਨ ਇਨ ਕਰੋ, ਫਿਰ ਟਨਲ ਚੁੱਕੋ
ਜੋ ਕ੍ਰਮ ਕੰਮ ਕਰਦਾ ਹੈ ਉਹ ਇਹ ਹੈ: ਡਿਵਾਈਸ ਨੂੰ ਮਨਜ਼ੂਰੀ ਦਿਓ, ਰਸਤਾ ਸਾਬਤ ਕਰੋ, VPN ਸ਼ੁਰੂ ਕਰੋ, ਟਨਲ ਸਾਬਤ ਕਰੋ, ਅਤੇ ਫਿਰ ਆਪਣਾ ਆਮ ਰੋਕ ਬਹਾਲ ਕਰੋ। ਉਹ ਆਖਰੀ ਕਦਮ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ ਪੋਰਟਲ ਤੱਕ ਪਹੁੰਚਣ ਲਈ ਲੋੜੀਂਦੀ ਅਸਥਾਈ ਹਾਲਤ ਉਹੀ ਹਾਲਤ ਹੈ ਜੋ ਐਮਰਜੈਂਸੀ ਸਵਿੱਚ ਰੋਕਣ ਲਈ ਮੌਜੂਦ ਹੈ।
ਟਨਲ ਤੋਂ ਬਾਹਰ ਰੋਕਣ ਦਾ ਵਿਕਲਪ ਰੱਖਣ ਵਾਲੇ ਡੈਸਕਟਾਪ ਕਲਾਇੰਟ ਨੂੰ ਪੋਰਟਲ ਪੰਨਾ ਲੋਡ ਹੋਣ ਲਈ ਰੋਕਣਾ ਪੈਂਦਾ ਹੈ, ਅਤੇ ਉਸ ਟਨਲ ਤੋਂ ਬਾਹਰ ਵਾਲੀ ਖਿੜਕੀ ਦੌਰਾਨ ਸੰਵੇਦਨਸ਼ੀਲ ਐਪਾਂ ਬੰਦ ਰੱਖਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ; ਸਥਾਨਕ ਟ੍ਰੈਫਿਕ ਬਿਨਾਂ ਸੁਰੱਖਿਆ ਦੇ ਬਾਹਰ ਜਾਣ ਵਾਲਾ ਇਹੀ ਇੱਕੋ ਅੰਤਰਾਲ ਹੈ। ਪ੍ਰਬੰਧਿਤ ਹਮੇਸ਼ਾ-ਚਾਲੂ ਡਿਵਾਈਸ ਨੂੰ ਤੁਹਾਡੇ ਵੱਲੋਂ ਨੀਤੀ ਹਟਾਉਣ ਦੀ ਬਜਾਏ ਇਸਦੇ ਮਾਲਕ ਵੱਲੋਂ ਪ੍ਰਕਾਸ਼ਿਤ ਪ੍ਰਕਿਰਿਆ ਵਰਤਣੀ ਚਾਹੀਦੀ ਹੈ। ਜੇ ਪੋਰਟਲ ਸਰਟੀਫਿਕੇਟ ਚੇਤਾਵਨੀ ਦਿਖਾਏ ਤਾਂ ਰੁਕੋ: ਇਸ ਨੂੰ ਸਵੀਕਾਰ ਕਰਨ ਨਾਲ ਤੁਹਾਡਾ ਸੈਸ਼ਨ ਥਾਂ ਦੇ ਰੋਕਣ ਵਾਲੇ ਪ੍ਰੌਕਸੀ ਰਾਹੀਂ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਉਹ ਪ੍ਰੌਕਸੀ ਤੁਹਾਡੇ ਵੱਲੋਂ ਭੇਜੀ ਹਰ ਚੀਜ਼ ਪੜ੍ਹ ਸਕਦੀ ਹੈ। Android 'ਤੇ ਹਮੇਸ਼ਾ-ਚਾਲੂ VPN ਅਧੀਨ ਲਾਕਡਾਊਨ ਟਨਲ ਚੁੱਕਣ ਤੋਂ ਪਹਿਲਾਂ ਟ੍ਰੈਫਿਕ ਰੋਕਦਾ ਹੈ, ਅਤੇ ਕੁਝ ਬਿਲਡ ਪੋਰਟਲ ਪ੍ਰਵਾਹ ਨੂੰ ਛੋਟ ਨਹੀਂ ਦੇ ਸਕਦੇ; ਜੇ ਤੁਹਾਡਾ ਨਹੀਂ ਦੇ ਸਕਦਾ, ਤਾਂ ਲਾਕਡਾਊਨ ਬੰਦ ਛੱਡਣ ਦੀ ਬਜਾਏ ਥਾਂ ਦੀ ਬਦਲਵੀਂ ਪਹੁੰਚ ਜਾਂ ਹੋਰ ਡਿਵਾਈਸ ਵਰਤੋ। Apple ਦੇ ਆਨ-ਡਿਮਾਂਡ ਨਿਯਮ ਪ੍ਰੋਬ ਸਫਲ ਹੋਣ ਤੱਕ ਟਨਲ ਤੋਂ ਇਨਕਾਰ ਕਰਨ ਲਈ ਲਿਖੇ ਜਾ ਸਕਦੇ ਹਨ, ਅਤੇ ਹੋਟਲ ਨੈੱਟਵਰਕਾਂ 'ਤੇ ਤੁਸੀਂ ਇਹੀ ਵਿਵਹਾਰ ਚਾਹੁੰਦੇ ਹੋ।
ਤੁਹਾਡੇ ਕੋਲ ਪਹਿਲਾਂ ਤੋਂ ਮੌਜੂਦ ਸਾਧਨਾਂ ਨਾਲ ਕ੍ਰਮ ਵਿੱਚ ਜਾਂਚੋ। ਟਨਲ ਤੋਂ ਪਹਿਲਾਂ ਪ੍ਰੋਬ ਨੂੰ ਹੈਡਰ ਅਤੇ ਮੁੱਖ ਹਿੱਸਾ ਦੋਵੇਂ ਦਿਖਦੇ ਹੋਏ ਚਲਾਓ, ਅਤੇ ਦੇਖੋ ਕਿ ਤੁਹਾਡੇ VPN ਆਵਾਜਾਈ ਨੂੰ ਕੋਈ ਜਵਾਬ ਮਿਲਦਾ ਹੈ ਜਾਂ ਨਹੀਂ:
curl -sS -D - http://captive.apple.com/hotspot-detect.html -o -
sudo tcpdump -ni any 'udp port 500 or udp port 4500 or udp port 1194'ਮਨਜ਼ੂਰੀ ਤੋਂ ਪਹਿਲਾਂ ਆਮ ਪੋਰਟਲ ਦੋ ਵਿੱਚੋਂ ਇੱਕ ਜਵਾਬ ਦਿੰਦਾ ਹੈ: 302 ਜਿਸਦਾ Location ਸਾਈਨ-ਇਨ ਪੰਨੇ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ, ਜਾਂ 200 ਜਿਸਦਾ HTML ਮੁੱਖ ਹਿੱਸਾ ਪੋਰਟਲ ਪੰਨਾ ਹੈ। ਲਿਖੋ ਕਿ ਤੁਹਾਨੂੰ ਕਿਹੜਾ ਮਿਲਿਆ। ਸਾਈਨ ਇਨ ਤੋਂ ਪਹਿਲਾਂ ਰੀਡਾਇਰੈਕਟ ਅਸਫਲਤਾ ਨਹੀਂ ਹੈ; ਪੋਰਟਲ ਤੁਹਾਨੂੰ ਦੱਸ ਰਿਹਾ ਹੈ ਕਿ ਕਿੱਥੇ ਜਾਣਾ ਹੈ। ਪੋਰਟਲ ਸਫਲਤਾ ਦੀ ਰਿਪੋਰਟ ਕਰਨ ਤੋਂ ਬਾਅਦ ਕਮਾਂਡ ਦੁਹਰਾਓ ਅਤੇ 200 ਦੀ ਉਮੀਦ ਕਰੋ ਜਿਸਦਾ ਮੁੱਖ ਹਿੱਸਾ ਸ਼ਬਦਸ਼ਃ Success ਸ਼ਬਦ ਹੈ। ਉਹੀ ਸਤਰ ਪ੍ਰੋਬ ਨੂੰ ਅਰਥਪੂਰਨ ਬਣਾਉਂਦੀ ਹੈ। ਜੇ ਤੁਸੀਂ ਕਦੇ ਸਾਈਨ ਇਨ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਹੋਸਟ ਆਮ ਤੌਰ 'ਤੇ ਜਵਾਬ ਦਿੰਦਾ ਹੈ, ਤਾਂ ਇਸ ਨੈੱਟਵਰਕ 'ਤੇ ਕੋਈ ਰੋਕਣ ਵਾਲਾ ਪੋਰਟਲ ਨਹੀਂ ਹੈ। ਕੈਪਚਰ ਵਿੱਚ ਮਨਜ਼ੂਰੀ ਤੋਂ ਪਹਿਲਾਂ ਸੁੱਟਣਾ ਉਹ ਬਾਹਰ ਜਾਂਦੇ ਪੈਕੇਟ ਹਨ ਜਿਨ੍ਹਾਂ ਤੋਂ ਕੁਝ ਵੀ ਵਾਪਸ ਨਹੀਂ ਆਉਂਦਾ, ਜਦੋਂ ਕਿ ਕੰਮ ਕਰਨ ਵਾਲਾ ਰਸਤਾ ਉਸੇ ਪ੍ਰਵਾਹ ਨੂੰ ਲਗਭਗ ਇੱਕ ਸਕਿੰਟ ਵਿੱਚ ਜਵਾਬ ਦਿਖਾਉਂਦਾ ਹੈ। ਜੁੜੋ, ਫਿਰ ਕੈਪਚਰ ਦੁਹਰਾਓ।
ਪੋਰਟਲ ਹਾਂ ਕਹਿਣ ਤੋਂ ਬਾਅਦ ਵੀ ਟਨਲ ਅਸਫਲ ਰਹੇ ਤਾਂ
ਸਾਈਨ ਇਨ ਦੀ ਸਫਲਤਾ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਆਵਾਜਾਈ ਦੇ ਬਰਾਬਰ ਨਹੀਂ ਹੈ। ਕਈ ਥਾਵਾਂ ਪੋਰਟਲ ਅਤੇ ਆਮ ਬ੍ਰਾਊਜ਼ਿੰਗ ਦੀ ਮਨਜ਼ੂਰੀ ਦਿੰਦੀਆਂ ਹਨ ਪਰ UDP ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਰੋਕਦੀਆਂ ਹਨ, ਜਿਸ ਨਾਲ WireGuard ਅਤੇ UDP OpenVPN ਟੁੱਟੇ ਰਹਿੰਦੇ ਹਨ ਅਤੇ TCP 443 ਕੰਮ ਕਰਦਾ ਹੈ। ਜੇ TCP 443 ਲੰਘਦਾ ਹੈ ਪਰ UDP ਨਹੀਂ, ਤਾਂ ਇਹ ਥਾਂ ਦੀ ਨੀਤੀ ਹੈ, ਤੁਹਾਡਾ ਗਲਤ ਸੰਰਚਿਤ ਕੀਤਾ ਕਲਾਇੰਟ ਨਹੀਂ, ਇਸ ਲਈ ਆਵਾਜਾਈ ਬਦਲੋ ਜਾਂ ਸੀਮਾ ਸਵੀਕਾਰ ਕੇ ਅੱਗੇ ਵਧੋ। ਉਸ ਤੋਂ ਬਾਅਦ ਵੀ ਦੁਬਾਰਾ ਜੁੜਨਾ ਅਸਫਲ ਰਹੇ ਤਾਂ ਸਹੀ ਗਲਤੀ ਰੱਖੋ; ਇਹ ਦੱਸਦੀ ਹੈ ਕਿ ਤੁਸੀਂ ਕਿੱਥੇ ਅਟਕੇ ਹੋ।
ਹੋਰ ਅਸਫਲਤਾਵਾਂ ਡਿਵਾਈਸ ਵਿੱਚ ਹੀ ਰਹਿੰਦੀਆਂ ਹਨ। ਪੁਰਾਣੇ MAC ਨਾਲ ਅਜੇ ਵੀ ਬੱਝੀ ਸੈਸ਼ਨ, ਆਪਣੀ ਲੀਜ਼ ਵਾਲਾ ਦੂਜਾ Wi-Fi ਅਡੈਪਟਰ, ਜਾਂ ਪੋਰਟਲ ਦੀ ਸਰਟੀਫਿਕੇਟ ਛੋਟ ਕੈਸ਼ ਕੀਤਾ ਕਲਾਇੰਟ — ਇਹਨਾਂ ਵਿੱਚੋਂ ਹਰ ਇੱਕ ਸਾਫ਼ ਦੁਬਾਰਾ ਮਨਜ਼ੂਰੀ ਤੋਂ ਬਾਅਦ ਵੀ ਅਸਫਲ ਹੁੰਦਾ ਰਹਿ ਸਕਦਾ ਹੈ। ਜੁੜਾਅ ਛੱਡੋ, ਦੁਬਾਰਾ ਮਨਜ਼ੂਰੀ ਦਿਓ, ਅਤੇ ਕਲਾਇੰਟ ਸੈਟਿੰਗਾਂ ਨੂੰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਵਾਰ ਕੋਸ਼ਿਸ਼ ਕਰੋ। ਜੇ ਤੁਸੀਂ ਨਿਗਰਾਨੀ ਕਰ ਰਹੇ ਹਿੱਸਿਆਂ ਪਿੱਛੇ ਦਾ ਢਾਂਚਾ ਚਾਹੁੰਦੇ ਹੋ ਤਾਂ RFC 8952 ਪੜ੍ਹਨ ਯੋਗ ਹੈ।
ਜੇ ਪੋਰਟਲ ਆਪ ਹੀ ਮਨਜ਼ੂਰੀ ਦੇਣ ਤੋਂ ਇਨਕਾਰ ਕਰੇ, ਤਾਂ ਸਮੱਸਿਆ ਖਾਤੇ ਜਾਂ ਡਿਵਾਈਸ ਵੰਡ ਵਿੱਚ ਹੈ ਅਤੇ ਕੋਈ ਵੀ VPN ਸੈਟਿੰਗ ਇਸ ਨੂੰ ਠੀਕ ਨਹੀਂ ਕਰੇਗੀ। VPN ਦਾ ਨਿਕਾਸ ਦੇਸ਼ ਬਦਲਣ ਨਾਲ ਥਾਂ ਦੀ ਸਥਾਨਕ ਪਹੁੰਚ ਹਾਲਤ ਰੀਸੈਟ ਨਹੀਂ ਹੁੰਦੀ; ਉਹ ਸਾਰਣੀ ਤੁਹਾਡੇ ਡਿਵਾਈਸ ਨਾਲ ਜੁੜੀ ਹੈ, ਤੁਹਾਡੇ ਚੁਣੇ ਸਰਵਰ ਨਾਲ ਨਹੀਂ। ਥਾਂ ਦੇ ਆਪਰੇਟਰ ਨੂੰ ਪੁੱਛੋ ਅਤੇ ਸਮਾਂ ਦਿਓ, ਕਿਉਂਕਿ ਉਹ ਸੈਸ਼ਨ ਸਾਰਣੀ ਹੀ ਵੇਖੇਗਾ।
ਅਗਲੀ ਯਾਤਰਾ ਤੋਂ ਪਹਿਲਾਂ ਤਿੰਨ ਗੱਲਾਂ ਲਿਖੋ: ਸਿਫ਼ਰ ਕਦਮ ਵਜੋਂ ਪੋਰਟਲ ਪੰਨਾ, ਤੁਹਾਡੇ ਨਾਲ ਲੈ ਜਾਣ ਵਾਲੇ ਹਰ ਡਿਵਾਈਸ ਲਈ ਰੋਕ ਰੋਕਣ ਦਾ ਕਦਮ, ਅਤੇ ਇੱਕ ਬਦਲਵੀਂ ਆਵਾਜਾਈ ਜਿਸ ਦੀ ਤੁਸੀਂ ਸੱਚਮੁੱਚ ਜਾਂਚ ਕੀਤੀ ਹੋਵੇ। ਦਸ ਮਿੰਟ ਪਹਿਲਾਂ ਕੰਮ ਕਰਦਾ ਟਨਲ ਦੁਬਾਰਾ ਰੁਕੇ ਤਾਂ ਇਸ ਨੂੰ ਖ਼ਤਮ ਹੋਈ ਮਨਜ਼ੂਰੀ ਸਮਝੋ ਅਤੇ VPN ਪਰੋਫ਼ਾਈਲ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਪੋਰਟਲ ਦੁਬਾਰਾ ਜਾਂਚੋ।