Windows NAT-T ਰਜਿਸਟਰੀ ਮੁੱਲ: ਪਹਿਲਾਂ ਟੋਪੋਲੋਜੀ ਜਾਂਚੋ

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

ਮੁੱਲ ਅਸਲ ਵਿੱਚ ਕੀ ਚੁਣਦਾ ਹੈ

AssumeUDPEncapsulationContextOnSendRule ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ Windows ਦਾ IPsec ਕਾਰਜਾਨਵਿਆਨ NAT ਡਿਵਾਈਸ ਪਿੱਛੇ ਬੈਠੇ ਸਾਥੀ ਨਾਲ ਸੰਬੰਧ ਬਣਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੇਗਾ ਜਾਂ ਨਹੀਂ। ਦਸਤਾਵੇਜ਼ਬੱਧ ਡਿਫਾਲਟ 0 ਉਸ ਸਥਿਤੀ ਦੀ ਆਗਿਆ ਨਹੀਂ ਦਿੰਦਾ, 1 ਉਦੋਂ ਆਗਿਆ ਦਿੰਦਾ ਹੈ ਜਦੋਂ ਸਰਵਰ NAT ਪਿੱਛੇ ਵਾਲਾ ਪਾਸਾ ਹੋਵੇ, ਅਤੇ 2 ਦੋਵੇਂ ਸਿਰਿਆਂ ਦੇ ਅਨੁਵਾਦ ਹੋਣ ਨੂੰ ਸ਼ਾਮਲ ਕਰਦਾ ਹੈ। ਇਹ ਟੋਪੋਲੋਜੀ ਬਾਰੇ ਬਿਆਨ ਹਨ—ਕੌਣ ਕਿੱਥੇ ਹੈ।

ਕ੍ਰਮ ਵਜੋਂ ਪੜ੍ਹਨ 'ਤੇ ਸੰਖਿਆਵਾਂ ਵਧਦੀ ਭਰੋਸੇਯੋਗਤਾ ਨਹੀਂ, ਸਗੋਂ ਵਧਦਾ ਅਨੁਵਾਦ ਦਰਸਾਉਂਦੀਆਂ ਹਨ। ਜਿੱਥੇ ਕੁਝ ਵੀ ਅਨੁਵਾਦ ਨਹੀਂ ਹੁੰਦਾ ਅਜਿਹੇ ਨੈੱਟਵਰਕ 'ਤੇ 2 ਸੈੱਟ ਕਰਨਾ ਕਨੈਕਸ਼ਨ ਨੂੰ ਤੇਜ਼ ਜਾਂ ਵਧੇਰੇ ਸਥਿਰ ਨਹੀਂ ਬਣਾਉਂਦਾ, ਅਤੇ ਪ੍ਰਮਾਣਿਕਤਾ ਫੇਲ੍ਹਤਾ ਨੂੰ ਵੀ ਠੀਕ ਨਹੀਂ ਕਰਦਾ। Microsoft ਦੀ L2TP/IPsec ਲਈ NAT ਮਾਰਗਦਰਸ਼ਿਕਾ ਨੀਤੀ ਅਤੇ ਇਸਦੇ ਇਤਿਹਾਸਕ ਪਲੇਟਫਾਰਮ ਸੰਦਰਭ ਦਾ ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਕਰਦੀ ਹੈ। ਉਸ ਸੰਦਰਭ ਨੂੰ ਉਸ Windows ਸੰਸਕਰਣ ਅਤੇ ਭੂਮਿਕਾ ਨਾਲ ਮਿਲਾਓ ਜੋ ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਚਲਾਉਂਦੇ ਹੋ, ਕਿਉਂਕਿ ਕਈ ਸੰਸਕਰਣਾਂ ਤੱਕ ਟਿਕਿਆ ਦਸਤਾਵੇਜ਼ ਹਰ ਮੌਜੂਦਾ ਬਿਲਡ ਬਾਰੇ ਬਿਆਨ ਨਹੀਂ ਹੈ।

ਸੰਖਿਆ ਤੋਂ ਪਹਿਲਾਂ ਟੋਪੋਲੋਜੀ ਮਿਲਾਓ

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

ਇਹ ਦਾਅਵਾ ਕਿ ਮੌਜੂਦਾ Windows Server ਸੰਸਕਰਣ ਸਿੱਧੇ NAT traversal ਬੰਦ ਨਾਲ ਆਉਂਦੇ ਹਨ, ਕਾਰਵਾਈ ਲਈ ਬਹੁਤ ਵਿਆਪਕ ਹੈ। ਮਹੱਤਵਪੂਰਨ ਇਹ ਹੈ ਕਿ ਤੁਹਾਡੇ ਸਿਸਟਮ 'ਤੇ ਨੀਤੀ ਕੀ ਹੈ, ਉਸ ਅੱਗੇ ਦੀ ਟੋਪੋਲੋਜੀ ਕੀ ਹੈ ਅਤੇ ਕਿਹੜਾ ਆਦਾਨ-ਪ੍ਰਦਾਨ ਫੇਲ੍ਹ ਹੋਇਆ—ਇਸੇ ਕ੍ਰਮ ਵਿੱਚ। ਜੇ ਦੋਵੇਂ ਸਿਰਿਆਂ ਦੇ ਪਤੇ ਜਨਤਕ ਹਨ, ਤਾਂ ਸੈਟਿੰਗ ਤੁਹਾਡੀ ਸਮੱਸਿਆ ਨਹੀਂ ਹੈ। ਇਸ ਦੀ ਬਜਾਏ ਪ੍ਰਸਤਾਵ, ਸਰਟੀਫਿਕੇਟ ਜਾਂ ਖਾਤਾ ਵੇਖੋ, ਅਤੇ ਰਜਿਸਟਰੀ ਛੱਡ ਦਿਓ।

ਪਹਿਲਾਂ ਫੇਲ੍ਹਤਾ ਦਾ ਪੜਾਅ ਜਾਂਚੋ

L2TP/IPsec ਘੱਟੋ-ਘੱਟ ਤਿੰਨ ਵੱਖਰੀਆਂ ਫੇਲ੍ਹਤਾਵਾਂ ਪੈਦਾ ਕਰਦਾ ਹੈ: ਸਾਥੀ ਤੱਕ ਪਹੁੰਚ ਨਹੀਂ, IPsec ਸੁਰੱਖਿਆ ਸਥਾਪਿਤ ਨਹੀਂ ਹੋ ਸਕਦੀ, ਅਤੇ ਸੁਰੰਗ ਬਣਨ ਤੋਂ ਬਾਅਦ PPP ਵਰਤੋਂਕਾਰ ਪ੍ਰਮਾਣਿਕਤਾ ਰੱਦ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਰੱਦ ਕੀਤਾ ਖਾਤਾ NAT ਨੀਤੀ ਬਦਲ ਕੇ ਠੀਕ ਨਹੀਂ ਹੁੰਦਾ, ਅਤੇ ਪ੍ਰਸਤਾਵ ਦੀ ਅਸੰਗਤੀ ਰੀਬੂਟ ਨਾਲ ਠੀਕ ਨਹੀਂ ਹੁੰਦੀ।

Get-VpnConnection -Name "Corp L2TP" | Format-List Name, ServerAddress, TunnelType, EncryptionLevel
Get-WinEvent -LogName System -MaxEvents 40 | Where-Object Id -in 20227,20226,20274
netsh interface ipv4 show interfaces

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

HTTPS ਉੱਤੇ SSTP ਅਤੇ ਮੂਲ IKEv2 ਦੇ ਆਪਣੇ ਲਾਗ ਅਤੇ ਆਪਣੇ ਨਿਯੰਤਰਣ ਹਨ। ਸਿਰਫ਼ Windows ਉੱਤੇ ਚੱਲਣ ਕਾਰਨ ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ NAT-traversal ਮਾਮਲਾ ਨਹੀਂ ਬਣਦਾ।

ਵਾਪਸੀ ਦਾ ਰਾਹ ਰੱਖ ਕੇ ਬਦਲਾਅ ਕਰੋ

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

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