GVC Acquiring IP 'ਤੇ ਅਟਕ ਗਿਆ: ਇਹ ਪਾਸਵਰਡ ਦੀ ਸਮੱਸਿਆ ਨਹੀਂ

Global VPN Client Acquiring IP 'ਤੇ ਰੁਕ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਪਹਿਲੀ ਪ੍ਰਤੀਕਿਰਿਆ ਪਾਸਵਰਡ ਦੁਬਾਰਾ ਲਿਖਣਾ ਜਾਂ ਕਲਾਇੰਟ ਮੁੜ ਸਥਾਪਿਤ ਕਰਨਾ ਹੁੰਦੀ ਹੈ। ਦੋਵੇਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਉਸ ਪੜਾਅ ਨੂੰ ਨਹੀਂ ਛੂਹਦਾ ਜੋ ਅਸਫਲ ਹੋਇਆ। ਪ੍ਰਮਾਣਿਕਤਾ ਉਦੋਂ ਪੂਰੀ ਹੋ ਚੁੱਕੀ ਸੀ ਜਦੋਂ ਕਲਾਇੰਟ ਨੇ ਪਤਾ ਵੀ ਨਹੀਂ ਸੀ ਮੰਗਿਆ, ਇਸ ਲਈ ਉਸ ਲਾਈਨ 'ਤੇ ਤੁਹਾਨੂੰ ਰੋਕਣ ਵਾਲੇ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਨਹੀਂ ਹਨ। ਉੱਥੇ ਤੁਹਾਨੂੰ ਅਧੂਰੀ DHCP ਅਦਲਾ-ਬਦਲੀ ਰੋਕਦੀ ਹੈ, ਅਤੇ ਇਹ ਤਿੰਨ ਵੱਖ-ਵੱਖ ਥਾਵਾਂ 'ਤੇ ਅਟਕ ਸਕਦੀ ਹੈ।

ਪ੍ਰਮਾਣਿਕਤਾ ਅਤੇ ਪਤਾ ਨਿਰਧਾਰਨ ਵੱਖਰੇ ਪੜਾਅ ਹਨ

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

ਇਹੀ ਕ੍ਰਮ ਦੱਸਦਾ ਹੈ ਕਿ ਪਾਸਵਰਡ ਰੀਸੈਟ, ਨਵਾਂ ਸਥਾਨਕ ਉਪਭੋਗਤਾ ਜਾਂ ਮੁੜ ਸਥਾਪਨਾ ਇੱਥੇ ਕੁਝ ਵੀ ਕਿਉਂ ਨਹੀਂ ਬਦਲਦੇ। ਕਲਾਇੰਟ ਪਹਿਲਾਂ ਹੀ ਅਧਿਕ੍ਰਿਤ ਹੈ; ਹੁਣ ਉਹ ਉਸ ਲੀਜ਼ ਦੀ ਉਡੀਕ ਕਰ ਰਿਹਾ ਹੈ ਜੋ ਗੇਟਵੇ ਜਾਂ ਉਸਦੇ DHCP ਸਾਥੀ ਨੂੰ ਦੇਣੀ ਪੈਂਦੀ ਹੈ। ਉਹ ਨੀਤੀ ਵੀ ਜੋ ਉਪਭੋਗਤਾ ਨੂੰ ਇਜਾਜ਼ਤ ਦਿੰਦੀ ਹੈ ਪਰ ਪਤਾ ਰੇਂਜ ਨਹੀਂ ਦਿੰਦੀ, ਠੀਕ ਇਹੀ ਸਕ੍ਰੀਨ ਬਣਾਉਂਦੀ ਹੈ।

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

ਲੀਜ਼ ਅਸਲ ਵਿੱਚ ਕਿੱਥੋਂ ਆਉਂਦੀ ਹੈ

ਦੋ ਮਾਡਲ ਆਮ ਹਨ। ਫਾਇਰਵਾਲ ਖੁਦ VPN ਕਲਾਇੰਟਾਂ ਲਈ DHCP ਸਕੋਪ ਚਲਾ ਸਕਦਾ ਹੈ, ਜਾਂ ਬੇਨਤੀ ਨੂੰ ਅੰਦਰੂਨੀ ਨੈੱਟਵਰਕ ਦੇ ਬਾਹਰੀ DHCP ਸਰਵਰ ਕੋਲ ਭੇਜ ਸਕਦਾ ਹੈ। ਮਾਡਲ ਹੀ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਕਿਹੜੇ ਲਾਗ ਮਹੱਤਵਪੂਰਨ ਹਨ ਅਤੇ ਕਿਸ ਨੂੰ ਕਾਲ ਕਰਨਾ ਹੈ।

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

ਕੁਝ ਵੀ ਪਰਖਣ ਤੋਂ ਪਹਿਲਾਂ ਲਿਖੋ ਕਿ ਤੁਹਾਡੀ ਤੈਨਾਤੀ ਕਿਹੜਾ ਮਾਡਲ ਵਰਤਦੀ ਹੈ। ਆਨਲਾਈਨ ਵਿਰੋਧਾਭਾਸੀ ਸਲਾਹਾਂ ਵਿੱਚੋਂ ਅੱਧੀ ਦੂਜੇ ਨੂੰ ਮੰਨ ਲੈਂਦੀ ਹੈ।

ਟਨਲ ਚਾਲੂ ਹੋ ਸਕਦਾ ਹੈ ਅਤੇ ਫਿਰ ਵੀ ਲੀਜ਼ ਗੁਆ ਸਕਦਾ ਹੈ

ਸਥਾਪਿਤ ਕੰਟਰੋਲ ਕਨੈਕਸ਼ਨ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਗੱਲਬਾਤ ਸਫਲ ਹੋਈ, ਇਹ ਨਹੀਂ ਕਿ ਟਨਲ ਦਾ ਡੇਟਾ ਦੋਵੇਂ ਦਿਸ਼ਾਵਾਂ ਵਿੱਚ ਜਾਂਦਾ ਹੈ। DHCP ਅਦਲਾ-ਬਦਲੀ ਨੂੰ ਡੇਟਾ ਮਾਰਗ ਪਾਰ ਕਰਨ ਲਈ ਬੇਨਤੀ ਅਤੇ ਜਵਾਬ ਚਾਹੀਦੇ ਹਨ, ਅਤੇ ਉੱਥੇ ਹੀ ਇਨਕ੍ਰਿਪਸ਼ਨ ਸੈਟਿੰਗਾਂ, VPN ਜ਼ੋਨ ਦੀ ਨੀਤੀ ਅਤੇ MTU ਸਮੱਸਿਆਵਾਂ ਰਹਿੰਦੀਆਂ ਹਨ।

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

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

ਲੀਜ਼ ਦੇ ਰਾਹ ਨੂੰ ਕ੍ਰਮ ਵਿੱਚ ਚੱਲੋ

ਅਡਾਪਟਰ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ ਬਾਹਰ ਵੱਲ ਵਧੋ, ਤਾਂ ਜੋ ਹਰ ਕਦਮ ਸਿਰਫ਼ ਇੱਕ ਕਾਰਨ ਕਰਕੇ ਅਸਫਲ ਹੋ ਸਕੇ:

> Get-NetAdapter | Where-Object Name -like "*GVC*"
> ipconfig /all | findstr /i /c:"GVC" /c:"IPv4" /c:"DHCP"
> Test-NetConnection 10.60.0.1 -Port 443

169.254.x.x ਵਰਗਾ ਪਤਾ ਮਤਲਬ ਹੈ ਕਿ ਅਡਾਪਟਰ ਮੌਜੂਦ ਹੈ ਅਤੇ ਕੋਈ ਜਵਾਬ ਨਹੀਂ ਮਿਲਿਆ, ਜੋ ਲੀਜ਼ ਦੇ ਸਰੋਤ ਜਾਂ ਡੇਟਾ ਮਾਰਗ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ। VPN ਰੇਂਜ ਵਿੱਚ ਸਹੀ ਪਤਾ ਪਰ ਗਲਤ DNS ਐਂਟਰੀਆਂ ਇੱਕ ਹੋਰ ਖਰਾਬੀ ਹੈ: ਲੀਜ਼ ਕੰਮ ਕਰ ਗਈ ਅਤੇ ਨੀਤੀ ਨੇ ਅਧੂਰੀਆਂ ਸੈਟਿੰਗਾਂ ਦਿੱਤੀਆਂ। ਜੋ ਅਡਾਪਟਰ ਕਦੇ ਨਹੀਂ ਦਿਸਦਾ, ਉਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਕਲਾਇੰਟ ਉਸਨੂੰ ਬਣਾਉਣ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚਿਆ।

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

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