IP ਪਤੇ ਨਾਲ ਗਲਤੀ 868? Windows ਪਹਿਲਾਂ ਕੀ ਹੱਲ ਕਰਦਾ ਹੈ

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

ਕਲਾਇੰਟ ਡਾਇਲ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਨਾਮ ਹੱਲ ਕਰਦਾ ਹੈ

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

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

ਕਿਹੜਾ ਨਾਮ, ਜਦੋਂ ਖੇਤਰ ਪਤਾ ਦਿਖਾਉਂਦਾ ਹੈ

ਦਿਖਣ ਵਾਲੇ ਨਾਮ ਦੀ ਥਾਂ ਸੰਗ੍ਰਹਿਤ ਮੁੱਲ ਪੜ੍ਹੋ। ਕਨੈਕਸ਼ਨ ਦਾ ਲੇਬਲ ਉਸ ਦਾ ਸਰਵਰ ਪਤਾ ਨਹੀਂ, ਅਤੇ ਮਿਲਦੇ-ਜੁਲਦੇ ਲੇਬਲ ਵਾਲੀਆਂ ਦੋ ਐਂਟਰੀਆਂ ਤੁਹਾਨੂੰ ਗਲਤ ਦੇ ਪਿੱਛੇ ਭੇਜਦੀਆਂ ਹਨ:

Get-VpnConnection -Name "Work VPN" |
    Select-Object Name, ServerAddress, TunnelType

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

Resolve-DnsName vpn.example.com

ਜਦੋਂ ਸੰਗ੍ਰਹਿਤ ਮੁੱਲ ਸੱਚਮੁੱਚ ਸੰਖਿਆਤਮਕ ਹੋਵੇ, ਤਾਂ ਕਲਾਇੰਟ ਨਾਮ ਪੜ੍ਹਦਾ ਹੈ ਅਜਿਹੀ ਦੂਜੀ ਥਾਂ ਲੱਭੋ। EAP ਸੰਰਚਨਾ ਕਿਸੇ ਸਰਵਰ ਦਾ ਹਵਾਲਾ ਦੇ ਸਕਦੀ ਹੈ, ਕਿਸੇ ਹੋਰ ਸਾਧਨ ਤੋਂ ਆਯਾਤ ਕੀਤਾ ਪ੍ਰੋਫਾਈਲ ਆਪਣਾ ਮੁੱਲ ਲੈ ਕੇ ਆ ਸਕਦਾ ਹੈ, ਅਤੇ ਪਿਛਲਾ ਇੰਸਟਾਲਰ ਇੱਕ ਡੁਪਲੀਕੇਟ ਐਂਟਰੀ ਛੱਡ ਸਕਦਾ ਹੈ। ਸੰਵਾਦ ਦਾ ਖੇਤਰ ਹਮੇਸ਼ਾ ਇੱਕੋ-ਇੱਕ ਇਨਪੁਟ ਨਹੀਂ।

Windows 7 ਮੁੜ-ਕਨੈਕਟ ਪੈਟਰਨ

ਇਸ ਗਲਤੀ ਪਿੱਛੇ ਦਾ ਥ੍ਰੈਡ ਅਜਿਹੀਆਂ ਮਸ਼ੀਨਾਂ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ ਜੋ ਇੱਕ ਵਾਰ ਜੁੜੀਆਂ ਅਤੇ ਫਿਰ ਬਾਅਦ ਦੀ ਕੋਸ਼ਿਸ਼ ਵਿੱਚ 868 ਨਾਲ ਅਸਫਲ ਹੋਈਆਂ, ਪ੍ਰੋਫਾਈਲ ਵਿੱਚ ਕੁਝ ਨਾ ਬਦਲਿਆ ਹੋਣ ’ਤੇ। ਯੋਗਦਾਨੀਆਂ ਨੇ ਦੱਸਿਆ ਕਿ Remote Access Connection Manager ਸੇਵਾ ਮੁੜ ਸ਼ੁਰੂ ਕਰਨ ਜਾਂ ਸਾਈਨ ਆਉਟ ਕਰਕੇ ਮੁੜ ਸਾਈਨ ਇਨ ਕਰਨ ਨਾਲ ਕਨੈਕਸ਼ਨ ਅਸਥਾਈ ਤੌਰ ’ਤੇ ਬਹਾਲ ਹੋਇਆ। ਇਹ ਬਦਲਵੇਂ ਉਪਾਅ ਹਨ, ਸਾਬਤ ਮੂਲ ਕਾਰਨ ਨਹੀਂ।

ਉਸ ਪੈਟਰਨ ਨੂੰ ਵੱਖਰੀ ਪਰਿਕਲਪਨਾ ਮੰਨੋ। ਮੁੜ ਸ਼ੁਰੂ ਕਰਨ ਨਾਲ ਕਲਾਇੰਟ ਦੀ ਸਥਿਤੀ ਰੀਸੈਟ ਹੁੰਦੀ ਹੈ, ਇਸ ਲਈ ਬਾਅਦ ਦੀ ਅਸਥਾਈ ਸਫਲਤਾ ਇਹ ਸਾਬਤ ਨਹੀਂ ਕਰਦੀ ਕਿ DNS ਰਿਕਾਰਡ ਗਲਤ ਸੀ:

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

ਪ੍ਰਬੰਧਕ ਲਈ ਕੀ ਇਕੱਠਾ ਕਰਨਾ ਹੈ

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

ਪੁਰਾਣੇ ਬਿਲਡਾਂ ਦਾ ਬਦਲਵਾਂ ਉਪਾਅ ਸਬੂਤ ਹੈ ਕਿ ਵਿਵਹਾਰ ਮੌਜੂਦ ਸੀ, ਇਹ ਵਾਅਦਾ ਨਹੀਂ ਕਿ ਉਹੀ ਸੇਵਾ ਮੁੜ ਸ਼ੁਰੂ ਕਰਨ ਨਾਲ ਮੌਜੂਦਾ ਮਸ਼ੀਨ ਠੀਕ ਹੋ ਜਾਵੇਗੀ। ਦਸਤਾਵੇਜ਼ੀ ਹੋਸਟਨਾਮ ਨੂੰ ਸ਼ਾਬਦਿਕ ਪਤੇ ਨਾਲ ਬਦਲਣਾ ਵੀ ਮੁਰੰਮਤ ਨਹੀਂ।

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