L2TP/IPsec ਗਲਤੀ 789, 720 ਜਾਂ 691: ਪਹਿਲਾਂ ਸਹੀ ਪੜਾਅ ਠੀਕ ਕਰੋ
Windows L2TP/IPsec ਦੇ ਵੱਖ-ਵੱਖ ਪੜਾਵਾਂ 'ਤੇ 789, 720 ਜਾਂ 691 ਦੀ ਰਿਪੋਰਟ ਕਰਦਾ ਹੈ। ਦੁਬਾਰਾ ਸਥਾਪਤ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ NAT ਨੀਤੀ, ਅਡੈਪਟਰ ਸਟੈਕ ਜਾਂ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਠੀਕ ਕਰਨ ਦਾ ਫ਼ੈਸਲਾ ਕਰੋ।
Windows 11 ਹਰ L2TP/IPsec ਪੜਾਅ ਲਈ ਵੱਖਰਾ ਨੰਬਰ ਦੀ ਰਿਪੋਰਟ ਕਰਦਾ ਹੈ, ਅਤੇ ਉਹ ਨੰਬਰ ਨਾਕਾਮੀ ਦਾ ਮੁਲਾਂਕਣ ਕਰਨ ਦੀ ਥਾਂ ਪੜਾਅ ਦਰਸਾਉਂਦਾ ਹੈ। 789 PPP ਲਿੰਕ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ, 720 ਲਿੰਕ ਚੁੱਕਦੇ ਸਮੇਂ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ, ਅਤੇ 691 ਲਿੰਕ ਚੁੱਕਣ ਅਤੇ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਰੱਦ ਹੋਣ ਤੋਂ ਬਾਅਦ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ। ਲਾਹੇਵੰਦ ਫ਼ੈਸਲਾ ਇਹ ਨਹੀਂ ਕਿ ਕਿਹੜਾ ਸੁਧਾਰ ਸਭ ਤੋਂ ਮਸ਼ਹੂਰ ਹੈ; ਇਹ ਹੈ ਕਿ ਕੋਡ ਕਿਹੜਾ ਪੜਾਅ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਪਹੁੰਚੇ ਹੋ। ਪਹਿਲਾਂ ਉਹ ਪੜ੍ਹੋ, ਫਿਰ ਹਰ ਕੋਸ਼ਿਸ਼ ਵਿੱਚ ਇੱਕ ਪਰਤ ਬਦਲੋ ਤਾਂ ਜੋ ਅਗਲਾ ਕੋਡ ਤੁਹਾਨੂੰ ਕੁਝ ਹੋਰ ਦੱਸ ਸਕੇ।
ਕੋਡ ਨੂੰ ਪੜਾਅ ਵਜੋਂ ਪੜ੍ਹੋ, ਖਰਾਬੀਆਂ ਦੀ ਸੂਚੀ ਵਜੋਂ ਨਹੀਂ
L2TP ਕਨੈਕਸ਼ਨ ਨਿਸ਼ਚਿਤ ਕ੍ਰਮ ਵਿੱਚ ਤਿੰਨ ਸੀਮਾਵਾਂ ਪਾਰ ਕਰਦਾ ਹੈ। IKE UDP 500 'ਤੇ ਸੁਰੱਖਿਆ ਸੰਗਠਨਾਂ 'ਤੇ ਗੱਲਬਾਤ ਕਰਦਾ ਹੈ, NAT ਟ੍ਰੈਵਰਸਲ ਉਹ ਟ੍ਰੈਫਿਕ UDP 4500 'ਤੇ ਲੈ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਉਸ ਤੋਂ ਬਾਅਦ ਹੀ L2TP ਟਨਲ PPP ਸੈਸ਼ਨ ਢੋਂਦੀ ਹੈ ਜੋ ਵਰਤੋਂਕਾਰ ਦੀ ਪਛਾਣ ਕਰਦਾ ਹੈ ਅਤੇ ਪਤਾ ਦਿੰਦਾ ਹੈ।
ਇਹੀ ਕ੍ਰਮ ਬਦਲਦੇ ਗਲਤੀ ਕੋਡ ਨੂੰ ਲਾਹੇਵੰਦ ਸਬੂਤ ਬਣਾਉਂਦਾ ਹੈ। 789 ਤੋਂ 720 'ਤੇ ਜਾਣਾ ਮਤਲਬ IPsec ਹੁਣ ਗੱਲਬਾਤ ਕਰ ਰਿਹਾ ਹੈ ਅਤੇ ਨਾਕਾਮੀ ਲਿੰਕ ਸਥਾਪਨਾ ਵੱਲ ਚਲੀ ਗਈ ਹੈ। 720 ਤੋਂ 691 'ਤੇ ਜਾਣਾ ਮਤਲਬ ਲਿੰਕ ਚੁੱਕ ਗਿਆ ਅਤੇ ਗੇਟਵੇ ਨੇ ਪਛਾਣ ਰੱਦ ਕਰ ਦਿੱਤੀ। ਜੇ ਤੁਸੀਂ ਪੰਜ ਸੁਧਾਰ ਇਕੱਠੇ ਲਾਗੂ ਕਰਦੇ ਹੋ, ਤਾਂ ਉਹ ਸੰਕੇਤ ਗੁਆ ਦਿੰਦੇ ਹੋ ਅਤੇ ਨਹੀਂ ਦੱਸ ਸਕਦੇ ਕਿ ਕਿਹੜਾ ਬਦਲਾਅ ਕੰਮ ਕੀਤਾ।
789: ਰਾਹ ਅਤੇ ਸਥਾਨਕ ਨੀਤੀ ਵਿੱਚੋਂ ਚੁਣੋ
ਕੋਡ 789 ਸ਼ੁਰੂਆਤੀ ਸੁਰੱਖਿਆ ਗੱਲਬਾਤਾਂ ਦੌਰਾਨ ਪ੍ਰੋਸੈਸਿੰਗ ਗਲਤੀ ਹੈ। IPsec ਨੇ ਕਦੇ ਵੀ ਵਰਤੋਂਯੋਗ ਸੰਗਠਨ ਨਹੀਂ ਬਣਾਇਆ, ਇਸ ਲਈ ਖਾਤੇ ਦੀ ਅਜੇ ਜਾਂਚ ਨਹੀਂ ਹੋਈ। ਖਾਤੇ ਨਾਲ ਨਹੀਂ, ਰਾਹ ਅਤੇ ਸਾਂਝੀ ਕੁੰਜੀ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ।
ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ UDP 500 ਅਤੇ UDP 4500 ਸਰਵਰ ਤੱਕ ਪਹੁੰਚਦੇ ਹਨ ਅਤੇ ਪਹਿਲਾਂ ਸਾਂਝੀ ਕੀਤੀ ਕੁੰਜੀ ਬਾਈਟ-ਬਾਈਟ ਮੇਲ ਖਾਂਦੀ ਹੈ, ਜਿਸ ਵਿੱਚ ਅੱਖਰਾਂ ਦਾ ਆਕਾਰ ਅਤੇ ਅੰਤ ਦੀਆਂ ਖਾਲੀ ਥਾਵਾਂ ਸ਼ਾਮਲ ਹਨ। ਜੇ ਸਰਵਰ NAT ਪਿੱਛੇ ਹੈ, ਤਾਂ Windows ਨੂੰ ਦਰਜ ਕੀਤਾ ਰਜਿਸਟਰੀ ਮੁੱਲ ਵੀ ਲੋੜੀਂਦਾ ਹੋ ਸਕਦਾ ਹੈ। ਸਰਵਰ NAT ਪਿੱਛੇ ਹੋਣ 'ਤੇ 1 ਅਤੇ ਦੋਵੇਂ ਸਿਰੇ ਇਸੇ ਤਰ੍ਹਾਂ ਹੋਣ 'ਤੇ 2 ਵਰਤੋ, ਫਿਰ ਦੁਬਾਰਾ ਸ਼ੁਰੂ ਕਰੋ ਕਿਉਂਕਿ ਨੀਤੀ ਏਜੰਟ ਮੁੱਲ ਨੂੰ ਸ਼ੁਰੂ ਵੇਲੇ ਪੜ੍ਹਦਾ ਹੈ:
reg add "HKLM\SYSTEM\CurrentControlSet\Services\PolicyAgent" /v AssumeUDPEncapsulationContextOnSendRule /t REG_DWORD /d 1 /f
ਭਾਰੀ ਅਡੈਪਟਰ ਮੁਰੰਮਤ ਦੂਜੀ ਸ਼ਾਖਾ ਦੀ ਹੈ। Wi-Fi ਜੰਤਰ ਅਤੇ WAN ਮਿਨੀਪੋਰਟ ਹਟਾ ਕੇ ਫਿਰ ਹਾਰਡਵੇਅਰ ਲਈ ਦੁਬਾਰਾ ਸਕੈਨ ਕਰਨਾ ਤਦ ਜਾਇਜ਼ ਹੈ ਜਦੋਂ ਸਥਾਨਕ IPsec ਸਟੈਕ ਆਪ ਹੀ ਖਰਾਬ ਹੋਵੇ ਅਤੇ ਹੋਰ VPN ਕਿਸਮਾਂ ਵੀ ਉਸੇ ਤਰ੍ਹਾਂ ਫੇਲ੍ਹ ਹੋਣ। ਜਦੋਂ ਸਿਰਫ਼ ਇੱਕ L2TP ਸਰਵਰ ਫੇਲ੍ਹ ਹੋਵੇ ਅਤੇ ਬਾਕੀ ਸਾਰੇ ਨੈੱਟਵਰਕ ਰਾਹ ਚੱਲਦੇ ਹੋਣ, ਇਹ ਵਿਅਰਥ ਯਤਨ ਹੈ।
720: ਇਸ ਅਡੈਪਟਰ ਅਤੇ ਸਰਵਰ ਪੂਲ ਵਿੱਚੋਂ ਚੁਣੋ
ਗਲਤੀ 720 ਦੱਸਦੀ ਹੈ ਕਿ ਦੂਰ ਦੇ ਕੰਪਿਊਟਰ ਨਾਲ ਕਨੈਕਸ਼ਨ ਸਥਾਪਤ ਨਹੀਂ ਹੋ ਸਕਿਆ, ਅਤੇ ਇਹ IPsec ਸਫਲ ਹੋਣ ਤੋਂ ਬਾਅਦ ਦਿਖਦੀ ਹੈ। ਟਨਲ ਇੰਟਰਫ਼ੇਸ ਚੁੱਕਣ ਜਾਂ ਪਤਾ ਲੈਣ ਵਾਲੇ ਬਿੰਦੂ ਤੱਕ ਪਹੁੰਚੀ ਅਤੇ ਫਿਰ ਰੁਕ ਗਈ। ਇਸ ਨਾਲ ਇਹ ਸਥਾਨਕ ਅਡੈਪਟਰ ਦਾ ਸਵਾਲ ਜਾਂ ਸਰਵਰ ਸਮਰੱਥਾ ਦਾ ਸਵਾਲ ਬਣ ਜਾਂਦੀ ਹੈ।
ਫ਼ੈਸਲੇ ਲਈ ਪ੍ਰਭਾਵ ਤ੍ਰਿਜਿਆ ਵਰਤੋ। ਇੱਕ Windows ਮਸ਼ੀਨ ਦਾ ਫੇਲ੍ਹ ਹੋਣਾ ਖਰਾਬ WAN ਮਿਨੀਪੋਰਟ, ਰੁਕੀ Remote Access ਸੇਵਾ ਜਾਂ ਖਰਾਬ ਕਨੈਕਸ਼ਨ ਪ੍ਰੋਫ਼ਾਈਲ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ। ਕਈ ਕਲਾਇੰਟਾਂ ਦਾ ਇੱਕੋ ਸਮੇਂ ਫੇਲ੍ਹ ਹੋਣਾ ਸਰਵਰ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ: ਖ਼ਤਮ ਹੋਇਆ ਪਤਾ ਪੂਲ, ਰੁਕੀ RRAS ਸੇਵਾ ਜਾਂ ਅਜਿਹਾ ਪੂਲ ਜੋ ਹੁਣ ਕਲਾਇੰਟ ਸਬਨੈੱਟ ਨਾਲ ਨਹੀਂ ਮਿਲਦਾ। ਦੂਜਾ ਪਾਸਾ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਉਹ ਪਾਸਾ ਠੀਕ ਕਰੋ ਜਿਸ ਵੱਲ ਪੈਟਰਨ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ।
ਇੱਕ-ਕਲਾਇੰਟ ਸ਼ਾਖਾ ਵਿੱਚ, WAN ਮਿਨੀਪੋਰਟ ਇੱਕ ਵਾਰ ਹਟਾਓ ਅਤੇ ਹਾਰਡਵੇਅਰ ਬਦਲਾਵਾਂ ਲਈ ਸਕੈਨ ਕਰੋ, ਫਿਰ ਦੁਬਾਰਾ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ ਮੁੜ ਕੋਸ਼ਿਸ਼ ਕਰੋ। ਸਰਵਰ ਸ਼ਾਖਾ ਵਿੱਚ, ਕਲਾਇੰਟ ਦੀ ਥਾਂ ਪੂਲ ਅਤੇ ਸੇਵਾ ਦੀ ਸਥਿਤੀ ਜਾਂਚੋ, ਕਿਉਂਕਿ ਚੱਲ ਰਿਹਾ ਅਡੈਪਟਰ ਦੁਬਾਰਾ ਸਥਾਪਤ ਕਰਨ ਨਾਲ ਅਜਿਹਾ ਪਤਾ ਨਹੀਂ ਬਣ ਸਕਦਾ ਜੋ ਸਰਵਰ ਕੋਲ ਨਹੀਂ ਹੈ।
691: ਪ੍ਰਮਾਣ-ਪੱਤਰ ਅਤੇ ਰੁਕੇ ਸਹਾਇਕ ਵਿੱਚੋਂ ਚੁਣੋ
ਕੋਡ 691 ਪ੍ਰਮਾਣੀਕਰਨ ਦਾ ਇਨਕਾਰ ਹੈ, ਅਤੇ ਇਹ ਉਹ ਕੋਡ ਹੈ ਜਿਸ ਨੂੰ ਸਭ ਤੋਂ ਵੱਧ ਗਲਤ ਪਾਸਵਰਡ ਵਜੋਂ ਗਲਤ ਪੜ੍ਹਿਆ ਜਾਂਦਾ ਹੈ। ਟਨਲ ਉੱਪਰ ਹੈ, ਗੇਟਵੇ ਨੇ ਪਛਾਣ ਵੇਖੀ ਅਤੇ ਉਹ ਪਛਾਣ ਰੱਦ ਕਰ ਦਿੱਤੀ। ਕਾਰਨ ਅਜੇ ਵੀ ਪਾਸਵਰਡ ਖੇਤਰ ਤੋਂ ਬਾਹਰ ਹੋ ਸਕਦਾ ਹੈ।
ਪਹਿਲਾਂ ਡੋਮੇਨ ਖੇਤਰ ਜਾਂਚੋ, ਫਿਰ ਪਾਸਵਰਡ ਦੇ ਸਹੀ ਅੱਖਰ। ਖਾਲੀ ਥਾਂ, ਹਵਾਲਾ ਚਿੰਨ੍ਹ ਜਾਂ ਸ਼ੈੱਲ-ਵਿਸ਼ੇਸ਼ ਅੱਖਰ ਵਾਲਾ ਪਾਸਵਰਡ ਸਰਵਰ ਤੱਕ ਪਹੁੰਚਣ ਤੋਂ ਪਹਿਲਾਂ ਖਰਾਬ ਹੋ ਸਕਦਾ ਹੈ; Linux 'ਤੇ, pppd ਹਵਾਲਾ ਚਿੰਨ੍ਹਾਂ ਤੋਂ ਬਿਨਾਂ ਮੁੱਲ ਜਾਂ ਗੁੰਮ ਡੋਮੇਨ ਲਈ E=691 ਵਰਗਾ ਹੀ ਇਨਕਾਰ ਦੱਸਦਾ ਹੈ। ਭੇਤ ਨੂੰ ਚੇਪਣ ਦੀ ਥਾਂ ਦੁਬਾਰਾ ਟਾਈਪ ਕਰੋ, ਅਤੇ ਪੁਰਾਣਾ ਮੁੱਲ ਰੱਖ ਸਕਣ ਵਾਲੇ ਕਿਸੇ ਵੀ ਸੰਭਾਲੇ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਨੂੰ ਸਾਫ਼ ਕਰੋ।
ਲੋਕ ਜਿਹੜੀ ਸ਼ਾਖਾ ਛੱਡ ਦਿੰਦੇ ਹਨ ਉਹ ਰੁਕੀ ਸਹਾਇਕ ਸੇਵਾ ਹੈ। ਜਦੋਂ ਵਿਕਰੇਤਾ ਦਾ ਕਲਾਇੰਟ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਗੇਟਵੇ ਤੱਕ ਪਹੁੰਚਾਉਣ ਲਈ ਆਪਣੀ ਸੇਵਾ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ, ਤਾਂ ਅਯੋਗ ਜਾਂ ਕ੍ਰੈਸ਼ ਹੋਈ ਸੇਵਾ ਪਾਸਵਰਡ ਸਹੀ ਹੋਣ 'ਤੇ ਵੀ 691 ਪੈਦਾ ਕਰਦੀ ਹੈ। ਖਾਤਾ ਰੀਸੈਟ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਖ਼ਾਸ ਕਰਕੇ ਦੁਬਾਰਾ ਸ਼ੁਰੂ ਜਾਂ ਅੱਪਡੇਟ ਤੋਂ ਬਾਅਦ ਵਿਕਰੇਤਾ ਦੀ ਸੇਵਾ ਦੀ ਸਥਿਤੀ ਜਾਂਚੋ।
ਸ਼ਾਖਾਵਾਂ ਵੱਖ ਕਰਨ ਲਈ, ਉਹੀ ਵਰਤੋਂਕਾਰ ਨਾਮ ਕਿਸੇ ਹੋਰ ਚੱਲ ਰਹੇ VPN ਪ੍ਰੋਫ਼ਾਈਲ ਜਾਂ RADIUS ਜਾਂਚ ਖਾਤੇ 'ਤੇ ਅਜ਼ਮਾਓ। ਜੇ ਉਹ ਸਫਲ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਠੀਕ ਹੈ ਅਤੇ ਸਥਾਨਕ ਕਲਾਇੰਟ ਰਾਹ ਸ਼ੱਕੀ ਹੈ। ਜੇ ਉਹ ਉਸੇ ਤਰ੍ਹਾਂ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਸਮੱਸਿਆ ਖਾਤਾ ਜਾਂ ਗੇਟਵੇ ਨੀਤੀ ਹੈ।
ਹਰ ਕੋਸ਼ਿਸ਼ ਵਿੱਚ ਇੱਕ ਪਰਤ ਬਦਲੋ
ਬਾਹਰ ਤੋਂ ਅੰਦਰ ਕੰਮ ਕਰੋ: ਪਹੁੰਚ ਅਤੇ NAT ਟ੍ਰੈਵਰਸਲ, ਫਿਰ ਪਹਿਲਾਂ ਸਾਂਝੀ ਕੀਤੀ ਕੁੰਜੀ, ਫਿਰ ਸਥਾਨਕ ਅਡੈਪਟਰ ਸਟੈਕ, ਫਿਰ ਪ੍ਰਮਾਣ-ਪੱਤਰ, ਫਿਰ ਸਰਵਰ ਪੂਲ ਅਤੇ ਸੇਵਾਵਾਂ। ਇਹ ਕ੍ਰਮ ਉਨ੍ਹਾਂ ਪੜਾਵਾਂ ਦੀ ਪਾਲਣਾ ਕਰਦਾ ਹੈ ਜੋ ਕੋਡ ਦੱਸਦੇ ਹਨ ਅਤੇ ਹਰ ਨਤੀਜੇ ਨੂੰ ਇੱਕ ਬਦਲਾਅ ਨਾਲ ਜੋੜਨਯੋਗ ਰੱਖਦਾ ਹੈ।
ਹਰ ਕੋਸ਼ਿਸ਼ ਤੋਂ ਪਹਿਲਾਂ ਅਤੇ ਬਾਅਦ ਦੇ ਕੋਡ, ਕਲਾਇੰਟ ਬਿਲਡ, ਅਤੇ ਸਰਵਰ ਜਾਂ ਕਲਾਇੰਟ ਬਦਲਿਆ ਗਿਆ ਜਾਂ ਨਹੀਂ ਦਾ ਛੋਟਾ ਲੌਗ ਰੱਖੋ। 789, ਫਿਰ 720, ਫਿਰ 691 ਵਰਗਾ ਕ੍ਰਮ ਤਰੱਕੀ ਦਾ ਨਕਸ਼ਾ ਹੈ; ਉਹੀ ਕੋਡ ਦੋ ਵਾਰ ਆਉਣ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਆਖਰੀ ਬਦਲਾਅ ਨੇ ਉਸ ਪੜਾਅ ਨੂੰ ਨਹੀਂ ਸੰਬੋਧਿਤ ਕੀਤਾ। Windows ਦੁਬਾਰਾ ਸਥਾਪਤ ਕਰਨ ਨਾਲ ਇਹ ਨਕਸ਼ਾ ਮਿਟ ਜਾਂਦਾ ਹੈ ਅਤੇ ਗੇਟਵੇ 'ਤੇ ਰਹਿਣ ਵਾਲੀ ਨਾਕਾਮੀ ਘੱਟ ਹੀ ਠੀਕ ਹੁੰਦੀ ਹੈ।
ਜਦੋਂ ਕੋਡ ਬਦਲਣਾ ਬੰਦ ਹੋ ਜਾਵੇ, ਤਾਂ ਚੀਜ਼ਾਂ ਬਦਲਣਾ ਬੰਦ ਕਰੋ। ਮੌਜੂਦਾ ਕੋਡ, ਸਰਵਰ ਪਤਾ, ਪ੍ਰਮਾਣੀਕਰਨ ਢੰਗ ਅਤੇ ਕੋਸ਼ਿਸ਼ ਦਾ ਸਮਾਂ ਦਰਜ ਕਰੋ, ਫਿਰ ਉਸ ਰਿਕਾਰਡ ਦੀ ਤੁਲਨਾ ਚੱਲ ਰਹੇ ਕਲਾਇੰਟ ਨਾਲ ਕਰੋ। ਦੋਵਾਂ ਰਿਕਾਰਡਾਂ ਵਿਚਕਾਰ ਫ਼ਰਕ ਆਮ ਤੌਰ 'ਤੇ ਉਨ੍ਹਾਂ ਸੁਧਾਰਾਂ ਦੀ ਸੂਚੀ ਨਾਲੋਂ ਛੋਟਾ ਹੁੰਦਾ ਹੈ ਜੋ ਲੋਕ ਡਿਫ਼ੌਲਟ ਵਜੋਂ ਅਜ਼ਮਾਉਂਦੇ ਹਨ।