VPN ਉੱਤੇ RDP ਜੰਮਣਾ: ਇਨਪੁਟ ਅਜੇ ਵੀ ਕੰਮ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਟ੍ਰਾਂਸਪੋਰਟ ਜਾਂਚੋ
ਕੰਮ ਕਰਦੇ ਇਨਪੁਟ ਨਾਲ ਜੰਮੀ RDP ਤਸਵੀਰ ਡਿੱਗੀ ਸੁਰੰਗ ਨਹੀਂ ਹੈ। ਰੂਟ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਕਲਾਇੰਟ ਟ੍ਰਾਂਸਪੋਰਟ, UDP ਨੀਤੀ ਅਤੇ ਇੱਕ-ਹੋਸਟ ਮਾਮਲਾ ਜਾਂਚੋ।
ਜਦੋਂ ਤਸਵੀਰ ਅਪਡੇਟ ਹੋਣਾ ਬੰਦ ਹੋ ਜਾਂਦਾ ਹੈ ਪਰ ਮਾਊਸ ਦੂਰ ਦੇ ਡੈਸਕਟਾਪ ਉੱਤੇ ਫਿਸਲਦਾ ਰਹਿੰਦਾ ਹੈ, ਤਾਂ ਸਪਸ਼ਟ ਸਿੱਟਾ ਇਹ ਹੁੰਦਾ ਹੈ ਕਿ VPN ਡਿੱਗ ਗਿਆ। ਇਹ ਸਿੱਟਾ ਆਮ ਤੌਰ ਉੱਤੇ ਗਲਤ ਹੁੰਦਾ ਹੈ। ਕੰਮ ਕਰਦੇ ਇਨਪੁਟ ਨਾਲ ਜੰਮਿਆ ਫਰੇਮ ਦਾ ਅਰਥ ਹੈ ਕਿ ਸੈਸ਼ਨ ਅਤੇ ਉਸ ਦਾ ਇਨਪੁਟ ਚੈਨਲ ਜੀਵਤ ਹਨ, ਜੋ ਖਰਾਬੀ ਨੂੰ ਰੂਟਿੰਗ ਜਾਂ ਕਰੈਡੈਂਸ਼ੀਅਲ ਵੱਲ ਨਹੀਂ ਬਲਕਿ ਗ੍ਰਾਫਿਕਸ ਟ੍ਰਾਂਸਪੋਰਟ ਵੱਲ ਧੱਕਦਾ ਹੈ। ਦੋ ਤੇਜ਼ ਨਿਰੀਖਣ ਉਹਨਾਂ ਤਿੰਨ ਅਸਫਲਤਾਵਾਂ ਨੂੰ ਵੱਖ ਕਰਦੇ ਹਨ ਜਿਨ੍ਹਾਂ ਨੂੰ ਵਰਤੋਂਕਾਰ ਇੱਕੋ ਸ਼ਬਦ ਨਾਲ ਬਿਆਨ ਕਰਦੇ ਹਨ।
ਜੰਮਣਾ ਤੁਹਾਨੂੰ ਕੀ ਨਹੀਂ ਦੱਸਦਾ
ਦੂਰ ਦਾ ਡੈਸਕਟਾਪ ਇਨਪੁਟ ਅਤੇ ਸਕ੍ਰੀਨ ਅਪਡੇਟ TCP 3389 ਉੱਤੇ ਲੈ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਮੌਜੂਦਾ Windows ਕਲਾਇੰਟ ਸਟ੍ਰੀਮ ਦੇ ਗ੍ਰਾਫਿਕਸ-ਭਾਰੀ ਹਿੱਸੇ ਲਈ UDP ਟ੍ਰਾਂਸਪੋਰਟ ਜੋੜ ਸਕਦੇ ਹਨ। ਜਿਹੜੀ ਸੁਰੰਗ ਵੱਡੇ ਡੇਟਾਗ੍ਰਾਮ ਟੁਕੜੇ ਕਰਦੀ ਹੈ ਜਾਂ ਸੁੱਟ ਦਿੰਦੀ ਹੈ, ਉਸ ਵਿੱਚ ਭਰੋਸੇਯੋਗ ਚੈਨਲ ਕੀਸਟ੍ਰੋਕ ਲੈ ਜਾਂਦਾ ਰਹਿੰਦਾ ਹੈ ਜਦੋਂ ਕਿ ਗ੍ਰਾਫਿਕਸ ਚੈਨਲ ਰੁਕ ਜਾਂਦਾ ਹੈ। ਨਤੀਜਾ ਅਟਕੀ ਤਸਵੀਰ ਅਤੇ ਜਵਾਬ ਦੇਣ ਵਾਲੇ ਕੀਬੋਰਡ ਦਾ ਅਜੀਬ ਮੇਲ ਹੈ। ਇਹ ਇਹ ਵੀ ਸਮਝਾਉਂਦਾ ਹੈ ਕਿ ਦੁਬਾਰਾ ਕਨੈਕਟ ਕਰਨਾ ਕਈ ਵਾਰ ਲੱਛਣ ਨੂੰ ਇੱਕ ਮਿੰਟ ਲਈ ਠੀਕ ਕਰ ਦਿੰਦਾ ਹੈ ਅਤੇ ਫਿਰ ਵਾਪਸ ਲੈ ਆਉਂਦਾ ਹੈ।
ਜੋ ਸੈਸ਼ਨ ਡਿਸਕਨੈਕਟ ਹੋ ਕੇ ਦੁਬਾਰਾ ਜੁੜਦਾ ਹੈ ਉਹ ਦੂਜੀ ਖਰਾਬੀ ਹੈ, ਅਤੇ ਜੋ ਬਿਲਕੁਲ ਨਹੀਂ ਖੁੱਲ੍ਹਦਾ ਉਹ ਤੀਜੀ ਹੈ। ਪਹਿਲਾਂ ਆਕਾਰ ਦਾ ਨਾਮ ਦੇਣਾ ਤੁਹਾਨੂੰ ਗਲਤ ਪਰਤ ਜਾਂਚਣ ਤੋਂ ਰੋਕਦਾ ਹੈ।
ਦੋ ਕਮਾਂਡਾਂ ਨਾਲ ਤਿੰਨ ਅਸਫਲਤਾਵਾਂ ਵੱਖ ਕਰੋ
ਪਹੁੰਚਯੋਗਤਾ ਨੂੰ ਬਾਹਰ ਕਰਨਾ ਸਸਤਾ ਹੈ। ਕਲਾਇੰਟ ਤੋਂ RDP ਪੋਰਟ ਜਾਂਚੋ, ਫਿਰ ਹੋਸਟ ਉੱਤੇ ਸੈਸ਼ਨ ਦੀ ਸਥਿਤੀ ਪੜ੍ਹੋ।
Test-NetConnection rdp-host.example.com -Port 3389
query user /server:rdp-hostਅਸਫਲ TCP ਟੈਸਟ ਦਾ ਅਰਥ ਹੈ ਸੈਸ਼ਨ ਕਦੇ ਨਹੀਂ ਖੁੱਲ੍ਹਿਆ, ਇਸ ਲਈ ਇਸਨੂੰ ਜੰਮਣਾ ਨਹੀਂ ਬਲਕਿ ਫਾਇਰਵਾਲ, ਦਾਇਰਾ ਜਾਂ ਸੇਵਾ ਦੀ ਸਮੱਸਿਆ ਮੰਨੋ। ਸਰਗਰਮ ਸੈਸ਼ਨ ਨਾਲ ਸਫਲ ਟੈਸਟ ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ ਕਿ ਨਿਯੰਤਰਣ ਚੈਨਲ ਮੌਜੂਦ ਹੈ, ਜੋ ਬਿਲਕੁਲ ਜੰਮੀ ਤਸਵੀਰ ਦਾ ਮਾਮਲਾ ਹੈ। ਹੋਸਟ ਕੁਐਰੀ ਉਸ ਖਾਤੇ ਤੋਂ ਚਲਾਓ ਜਿਸਨੂੰ ਸੈਸ਼ਨ ਦੇਖਣ ਦੀ ਇਜਾਜ਼ਤ ਹੈ, ਕਿਉਂਕਿ ਇਜਾਜ਼ਤ ਦੀ ਗਲਤੀ ਖਾਲੀ ਸੂਚੀ ਵਾਂਗ ਦਿਖਦੀ ਹੈ। ਸੈਸ਼ਨ ID ਅਤੇ ਸਥਿਤੀ ਦਰਜ ਕਰੋ, ਕਿਉਂਕਿ ਆਪਣੀ ID ਰੱਖਣ ਵਾਲਾ ਡਿਸਕਨੈਕਟ ਹੋਇਆ ਸੈਸ਼ਨ ਸਰਗਰਮ ਸੈਸ਼ਨ ਵਰਗਾ ਨਹੀਂ ਹੁੰਦਾ।
UDP ਟ੍ਰਾਂਸਪੋਰਟ ਬੰਦ ਕਰੋ ਅਤੇ ਤੁਲਨਾ ਕਰੋ
ਜੇ ਸਿਰਫ਼ ਡਿਸਪਲੇ ਅਟਕਦਾ ਹੈ, ਤਾਂ ਇੱਕ ਵਾਰ ਵਿੱਚ ਇੱਕ ਬਦਲਾਅ ਕਰਕੇ ਕਲਾਇੰਟ ਟ੍ਰਾਂਸਪੋਰਟ ਦੀ ਤੁਲਨਾ ਕਰੋ। ਬਿਲਟ-ਇਨ ਕਲਾਇੰਟ ਅਤੇ Store ਕਲਾਇੰਟ ਇੱਕੋ ਸਟੈਕ ਸਾਂਝਾ ਨਹੀਂ ਕਰਦੇ, ਅਤੇ ਹੇਠਾਂ ਦੀ ਨੀਤੀ ਬਿਲਟ-ਇਨ ਕਲਾਇੰਟ ਤੋਂ UDP ਹਟਾ ਦਿੰਦੀ ਹੈ।
reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services\Client" /v fClientDisableUDPਮੁੱਲ 1 ਦਾ ਅਰਥ ਹੈ ਕਿ ਉਸ ਕਲਾਇੰਟ ਲਈ UDP ਪਹਿਲਾਂ ਹੀ ਬੰਦ ਹੈ, ਇਸ ਲਈ ਇਸ ਸੈਟਿੰਗ ਤੋਂ ਬਾਅਦ ਵੀ ਰਹਿਣ ਵਾਲਾ ਜੰਮਣਾ UDP ਰਾਹ ਦੀ ਸਮੱਸਿਆ ਨਹੀਂ ਹੈ। ਜਦੋਂ ਮੁੱਲ ਗੈਰਹਾਜ਼ਰ ਹੋਵੇ, ਨੀਤੀ ਸਮਰੱਥ ਕਰੋ, ਦੁਬਾਰਾ ਕਨੈਕਟ ਕਰੋ ਅਤੇ ਪਹਿਲਾਂ ਜੰਮੀ ਬਿਲਕੁਲ ਉਹੀ ਕਿਰਿਆ ਦੁਹਰਾਓ। ਦੋਵੇਂ ਬਦਲਾਅ ਨਾ ਮਿਲਾਓ ਬਲਕਿ Store ਕਲਾਇੰਟ ਨੂੰ ਵੱਖਰੇ ਕਦਮ ਵਜੋਂ ਜਾਂਚੋ, ਨਹੀਂ ਤਾਂ ਤੁਹਾਨੂੰ ਪਤਾ ਨਹੀਂ ਲੱਗੇਗਾ ਕਿ ਕਿਹੜਾ ਜ਼ਰੂਰੀ ਸੀ। Windows ਸੰਸਕਰਣਾਂ ਵਿੱਚ ਟ੍ਰਾਂਸਪੋਰਟ ਵਿਵਹਾਰ ਬਦਲਿਆ ਹੈ, ਇਸ ਲਈ ਕਲਾਇੰਟ ਸੰਸਕਰਣ ਆਪਣੇ ਨੋਟਾਂ ਵਿੱਚ ਰੱਖੋ।
ਜਦੋਂ ਇੱਕ ਹੋਸਟ ਜੰਮਦਾ ਹੈ ਪਰ ਬਾਕੀ ਠੀਕ ਹੁੰਦੇ ਹਨ
ਬਾਕੀ ਸਿਹਤਮੰਦ ਸਬਨੈੱਟ ਉੱਤੇ ਇੱਕੋ ਅਸਫਲ ਹੋਸਟ ਸੁਰੰਗ ਤੋਂ ਦੂਰ ਸੰਕੇਤ ਕਰਦਾ ਹੈ। VPN ਸੈਟਿੰਗਾਂ ਨੂੰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਰਾਹ ਦਾ MTU ਅਤੇ ਦੂਰ ਦੇ ਡਿਸਪਲੇ ਦਾ ਸਟੈਕ ਜਾਂਚੋ।
ping -f -l 1472 rdp-host.example.comਇੱਕ ਜਵਾਬ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਰਾਹ ਉਸ ਆਕਾਰ ਉੱਤੇ ਟੁਕੜਿਆਂ ਤੋਂ ਬਿਨਾਂ ਪੂਰੇ ਆਕਾਰ ਦਾ ਪੈਕਟ ਲੈ ਜਾਂਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਨਾ-ਟੁਕੜੋ ਝੰਡੇ ਨਾਲ ਅਸਫਲਤਾ ਦੱਸਦੀ ਹੈ ਕਿ ਸੁਰੰਗ ਦੇ MTU ਉੱਤੇ ਧਿਆਨ ਦੇਣ ਦੀ ਲੋੜ ਹੈ। ਜੇ 1472 ਬਾਈਟ ਲੰਘ ਜਾਣ ਅਤੇ ਸਿਰਫ਼ ਉਹ ਹੋਸਟ ਜੰਮੇ, ਤਾਂ ਨੈੱਟਵਰਕ ਦੀ ਥਾਂ ਉਸ ਦੇ ਗ੍ਰਾਫਿਕਸ ਡਰਾਈਵਰ ਅਤੇ ਲੋਡ ਵੱਲ ਦੇਖੋ। ਉਸੇ ਮਸ਼ੀਨ ਉੱਤੇ ਤੇਜ਼ ਫਾਇਲ ਕਾਪੀ ਥ੍ਰੂਪੁਟ ਬਾਰੇ ਦੱਸਦੀ ਹੈ, RDP ਗ੍ਰਾਫਿਕਸ ਚੈਨਲ ਬਾਰੇ ਨਹੀਂ। ਇੱਕ ਵਾਰ ਵਿੱਚ ਇੱਕ ਚਲ ਬਦਲੋ ਅਤੇ ਉਹੀ ਸਕ੍ਰੀਨ ਕਿਰਿਆ ਦੁਹਰਾਓ ਤਾਂ ਜੋ ਤੁਲਨਾ ਦਾ ਅਰਥ ਹੋਵੇ।
ਜੇ ਸੈਸ਼ਨ ਬਿਲਕੁਲ ਨਹੀਂ ਖੁੱਲ੍ਹਦਾ, ਤਾਂ ਇੱਥੇ ਰੁਕੋ, ਕਿਉਂਕਿ ਇਹ ਜੰਮਣਾ ਨਹੀਂ ਬਲਕਿ ਪਹੁੰਚਯੋਗਤਾ ਹੈ। ਨਹੀਂ ਤਾਂ ਜਿਸ ਟ੍ਰਾਂਸਪੋਰਟ ਸੈਟਿੰਗ ਨੇ ਲੱਛਣ ਬਦਲਿਆ ਉਹ ਰੱਖੋ ਅਤੇ ਕਲਾਇੰਟ ਸੰਸਕਰਣ ਨਾਲ ਦਰਜ ਕਰੋ।