ਬੇਕਾਰ ਸਮੇਂ ਵਿੱਚ VPN ਡਿੱਗਣਾ ਠੀਕ ਕਰੋ: Wi-Fi ਪਾਵਰ ਸੇਵ ਲਈ ਜਾਂਚ ਸੂਚੀ

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

ਪਹਿਲੀ ਜਾਂਚ: ਕੀ ਡਿੱਗਣਾ ਬੇਕਾਰੀ ਦਾ ਪਿੱਛਾ ਕਰਦਾ ਹੈ?

ਮੰਨਣ ਦੀ ਬਜਾਏ ਸੰਬੰਧ ਸਿੱਧ ਕਰਕੇ ਸ਼ੁਰੂ ਕਰੋ। ਤੁਹਾਡੇ ਭੇਜੇ ਆਖਰੀ ਪੈਕੇਟ ਦਾ ਦੀਵਾਰ-ਘੜੀ ਸਮਾਂ, ਕਲਾਇੰਟ ਵੱਲੋਂ ਟਨਲ ਹੇਠਾਂ ਹੋਣ ਦੀ ਰਿਪੋਰਟ ਦਾ ਸਮਾਂ, ਅਤੇ ਕੀ ਇਸ ਵਿਚਕਾਰ ਸਕਰੀਨ ਬੰਦ ਹੋਈ ਸੀ, ਲਿਖੋ। ਜੇ ਹਰ ਵਾਰ ਅੰਤਰ ਇੱਕੋ ਹੈ ਤਾਂ ਤੁਹਾਨੂੰ ਬੇਕਾਰੀ ਦੇ ਰਾਹ ਵਿੱਚ ਸਮੱਸਿਆ ਹੈ; ਜੇ ਸਰਗਰਮ ਵਰਤੋਂ ਦੌਰਾਨ ਡਿੱਗਣਾਂ ਬੇਤਰਤੀਬ ਹੁੰਦੀਆਂ ਹਨ ਤਾਂ ਪੰਜਵੀਂ ਜਾਂਚ 'ਤੇ ਜਾਓ।

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

ਦੂਜੀ ਜਾਂਚ: ਕੀ ਇਹ ਸਿਰਫ਼ VPN ਟ੍ਰੈਫਿਕ ਹੈ?

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

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

ਤੀਜੀ ਜਾਂਚ: ਪਾਵਰ ਸੇਵ ਸਥਿਤੀ ਪੜ੍ਹੋ

ਬਹੁਤੇ ਡੈਸਕਟਾਪ ਤੁਹਾਨੂੰ ਚੈੱਕਬਾਕਸ ਦਿੰਦੇ ਹਨ, ਪਰ ਉਹ ਬਾਕਸ ਉਹ ਸਥਿਤੀ ਨਹੀਂ ਜਿਸ ਵਿੱਚ ਡਰਾਈਵਰ ਹੈ। ਪਹਿਲਾਂ ਡਰਾਈਵਰ ਦੀ ਆਪਣੀ ਰਿਪੋਰਟ ਪੜ੍ਹੋ, ਫਿਰ ਫੈਸਲਾ ਕਰੋ। mac80211 ਵਾਲੇ Linux 'ਤੇ ਇੰਟਰਫੇਸ ਸਿੱਧਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ:

iw dev wlan0 get power_save          # on or off, per interface
sudo iw dev wlan0 set power_save off # diagnostic only, lost on reconnect

ਦੂਜਾ ਕਮਾਂਡ ਇੱਕ ਜਾਂਚ ਹੈ, ਸੁਧਾਰ ਨਹੀਂ। ਇਹ ਡਿਸਕਨੈਕਟ, ਸਲੀਪ ਜਾਂ ਰੀਬੂਟ ਨਹੀਂ ਝੱਲਦਾ, ਜੋ ਇਸਨੂੰ ਸਥਾਈ ਬਦਲਾਅ ਛੱਡੇ ਬਿਨਾਂ ਧਾਰਨਾ ਜਾਂਚਣ ਦਾ ਸਾਫ਼ ਤਰੀਕਾ ਬਣਾਉਂਦਾ ਹੈ।

Windows 'ਤੇpowercfg /q SCHEME_CURRENT ਸਰਗਰਮ ਸਕੀਮ ਛਾਪਦਾ ਹੈ, ਅਤੇ ਵਾਇਰਲੈਸ ਅਡਾਪਟਰ ਦੀ ਉਪਸ਼ਾਖਾ ਦਿਖਾਉਂਦੀ ਹੈ ਕਿ ਅਡਾਪਟਰ ਨੂੰ ਊਰਜਾ ਬਚਾਉਣ ਦਾ ਹੁਕਮ ਦਿੱਤਾ ਜਾ ਸਕਦਾ ਹੈ ਜਾਂ ਨਹੀਂ; ਉਹੀ ਚੋਣ ਅਡਾਪਟਰ ਦੇ ਪਾਵਰ ਮੈਨੇਜਮੈਂਟ ਟੈਬ 'ਤੇ Device Manager ਵਿੱਚ ਵੀ ਹੈ। macOS 'ਤੇ ਹਰ ਇੰਟਰਫੇਸ ਲਈ 802.11 ਪਾਵਰ ਸੇਵ ਤੁਹਾਨੂੰ ਨਹੀਂ ਦਿਖਾਇਆ ਜਾਂਦਾ, ਇਸ ਲਈ ਇਸਦੀ ਥਾਂpmset -g ਸਲੀਪ ਅਤੇ ਸਟੈਂਡਬਾਏ ਵਿਵਹਾਰ ਲਈ ਵੇਖੋ। ਉੱਥੇ ਨਾਕਾਮੀ ਆਮ ਤੌਰ 'ਤੇ ਰੇਡੀਓ ਦੇ ਬੇਕਾਰ ਵਿਵਹਾਰ ਵਿੱਚ ਨਹੀਂ, ਸਗੋਂ ਸਲੀਪ ਅਤੇ ਜਾਗਣ ਦੇ ਰਾਹ ਵਿੱਚ ਮਿਲਦੀ ਹੈ।

ਚੌਥੀ ਜਾਂਚ: ਇੱਕ ਚੀਜ਼ ਬਦਲੋ, ਫਿਰ ਦੁਬਾਰਾ ਜਾਂਚੋ

ਹਰ ਦੌੜ ਵਿੱਚ ਠੀਕ ਇੱਕ ਚਲ ਬਦਲੋ ਅਤੇ ਉਹੀ ਕੰਮ ਦਾ ਭਾਰ ਦੁਹਰਾਓ। ਜੇ ਪਾਵਰ ਸੇਵ ਬੰਦ ਹੋਣ 'ਤੇ ਟਨਲ ਹੁਣ ਇੱਕ ਘੰਟੇ ਦੀ ਬੇਕਾਰੀ ਝੱਲ ਲੈਂਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਕੁਝ ਅਸਲੀ ਸਿੱਖਿਆ। ਜੇ ਉਹ ਅਜੇ ਵੀ ਡਿੱਗਦਾ ਹੈ, ਤਾਂ ਅਗਲਾ ਵਿਚਾਰ ਜਾਂਚਣ ਤੋਂ ਪਹਿਲਾਂ ਬਦਲਾਅ ਵਾਪਸ ਕਰੋ, ਨਹੀਂ ਤਾਂ ਤਿੰਨ ਓਵਰਲੈਪਿੰਗ ਸੈਟਿੰਗਾਂ ਅਤੇ ਇਹ ਪਤਾ ਨਾ ਹੋਣ ਨਾਲ ਰਹਿ ਜਾਓਗੇ ਕਿ ਕਿਹੜੀ ਮਾਇਨੇ ਰੱਖਦੀ ਹੈ।

ਕਨੈਕਸ਼ਨ ਨੂੰ ਜੀਵਿਤ ਰੱਖਣਾ ਦੂਜਾ ਸੁਤੰਤਰ ਚਲ ਹੈ ਅਤੇ ਇਸਨੂੰ ਲਗਾਤਾਰ ਪਾਵਰ ਸੇਵ ਨਾਲ ਮਿਲਾ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ। WireGuard ਦਾPersistentKeepalive = 25 NAT ਮੈਪਿੰਗ ਨੂੰ ਗਰਮ ਰੱਖਦਾ ਹੈ;OpenVPN ਦੋਵੇਂ ਸਿਰਿਆਂ 'ਤੇkeepalive ਅਤੇping-restart ਵਰਤਦਾ ਹੈ। ਦੋਵੇਂ ਬਾਕੀ ਸਮੇਂ ਚੁੱਪ ਟਨਲ 'ਤੇ ਟ੍ਰੈਫਿਕ ਪੈਦਾ ਕਰਦੇ ਹਨ, ਇਸ ਲਈ ਜੋ ਜੀਵਿਤ-ਰੱਖਣਾ ਡਿੱਗਣਾ ਠੀਕ ਕਰਦਾ ਜਾਪਦਾ ਹੈ ਉਹ ਰੇਡੀਓ ਦੀ ਸਮੱਸਿਆ ਹੱਲ ਕਰਨ ਦੀ ਥਾਂ ਲੁਕਾ ਸਕਦਾ ਹੈ। ਇਹਨਾਂ ਨੂੰ ਵੱਖਰੇ ਤੌਰ 'ਤੇ, ਇੱਕ ਵਾਰ ਵਿੱਚ ਇੱਕ ਜਾਂਚੋ:

[Peer]
PublicKey = ...
Endpoint = vpn.example.net:51820
PersistentKeepalive = 25

ਪੰਜਵੀਂ ਜਾਂਚ: ਜਦੋਂ ਰੇਡੀਓ ਨਿਰਦੋਸ਼ ਹੈ

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

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

ਇਸਨੂੰ ਸਥਾਈ ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ

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

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

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