Azure VPN ਪ੍ਰੀਫਿਕਸ ਜੋੜਨ ਨਾਲ ਕਨੈਕਸ਼ਨ ਕਿਉਂ ਟੁੱਟਦਾ ਹੈ

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

ਤਿੰਨ ਆਬਜੈਕਟ, ਜਿਨ੍ਹਾਂ ਵਿੱਚੋਂ ਇੱਕ ਪ੍ਰੀਫਿਕਸ ਰੱਖਦਾ ਹੈ

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

ਇੱਕ ਤੀਜੀ ਸ਼ਰਤ ਵੀ ਹੈ ਜੋ ਧਿਆਨ ਵਿੱਚ ਰੱਖਣੀ ਚਾਹੀਦੀ ਹੈ। GatewaySubnet ਪ੍ਰਬੰਧਿਤ ਗੇਟਵੇ ਇੰਸਟੈਂਸ ਹੋਸਟ ਕਰਦਾ ਹੈ, ਬਿਲਕੁਲ ਉਹੀ ਨਾਮ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਗੈਰ-Basic SKU ਲਈ ਘੱਟੋ-ਘੱਟ /27 ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।

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

ਕਨੈਕਸ਼ਨ ਹੀ ਕਿਉਂ ਹਟਾਇਆ ਜਾਂਦਾ ਹੈ

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

ਉਹ ਹਟਾਉਣਾ ਹੀ ਰੁਕਾਵਟ ਹੈ, ਇਸ ਲਈ ਇਸਨੂੰ ਤੇਜ਼ ਸੋਧ ਦੀ ਥਾਂ ਸ਼ੁਰੂਆਤ ਅਤੇ ਉਮੀਦ ਕੀਤੇ ਅੰਤ ਵਾਲੇ ਯੋਜਨਾਬੱਧ ਬਦਲਾਅ ਵਜੋਂ ਲਵੋ। PowerShell ਵਿੱਚ ਕ੍ਰਮ ਛੋਟਾ ਹੈ: Remove-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 -Force, ਫਿਰ Set-AzLocalNetworkGateway ਨਵੇਂ -AddressPrefix ਐਰੇ ਨਾਲ, ਫਿਰ New-AzVirtualNetworkGatewayConnection ਉਸੇ -SharedKey ਅਤੇ ਉਹੀ ਗੇਟਵੇ ਨਾਲ। ਕੁੰਜੀ ਦਾ ਮੁੜ ਉਪਯੋਗ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਕਿਉਂਕਿ ਦੂਰ ਦਾ ਪਾਸਾ ਮੁੜ ਸੰਰਚਿਤ ਨਹੀਂ ਹੁੰਦਾ ਅਤੇ ਨਵੀਂ ਕੁੰਜੀ ਦਾ ਅਰਥ ਦੂਰ ਦੇ ਡਿਵਾਈਸ ਦੇ ਮਾਲਕ ਨਾਲ ਤਾਲਮੇਲ ਹੈ। ਜੇ ਉਹ ਡਿਵਾਈਸ ਕੋਈ ਹੋਰ ਟੀਮ ਚਲਾਉਂਦੀ ਹੈ, ਤਾਂ ਕੁਝ ਵੀ ਹਟਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਉਨ੍ਹਾਂ ਨਾਲ ਸਮਾਂ-ਖਿੜਕੀ ਤੈਅ ਕਰੋ।

ਗੇਟਵੇ ਆਪਣੇ ਆਪ ਕਦੋਂ ਦੁਬਾਰਾ ਬਣਾਉਣਾ ਪੈਂਦਾ ਹੈ

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

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

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

ਸਥਿਤੀ ਪੜ੍ਹੋ, ਪੋਰਟਲ ਦਾ ਬੈਜ ਨਹੀਂ

ਪੋਰਟਲ ਦੇ ਬੈਜ ਦੀ ਥਾਂ ਸਰੋਤ ਤੋਂ ਸਥਿਤੀ ਪੜ੍ਹੋ। Get-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 ਵਾਪਸ ਕਰਦਾ ਹੈ ConnectionStatus ਇਨਗ੍ਰੇਸ ਅਤੇ ਐਗ੍ਰੇਸ ਬਾਈਟ ਕਾਊਂਟਰਾਂ ਨਾਲ, ਅਤੇ ਜੁੜੇ ਹੋਏ ਪਰ ਕੁਝ ਨਾ ਢੋਣ ਵਾਲੇ ਟਨਲ ਨੂੰ ਕਦੇ ਸਥਾਪਿਤ ਨਾ ਹੋਏ ਟਨਲ ਤੋਂ ਵੱਖ ਕਰਨ ਵਾਲੇ ਇਹੀ ਕਾਊਂਟਰ ਹਨ।

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

VPN 'ਤੇ ਗਲਤ ਤਰੀਕੇ ਨਾਲ ਲਾਇਆ ਜਾਣ ਵਾਲਾ ਟੁੱਟਣ ਦਾ ਇੱਕ ਵਰਗ ਟਾਈਮਰ ਸਮਝਾਉਂਦੇ ਹਨ। Azure ਦਾ ਲੋਡ ਬੈਲੰਸਰ ਸੰਰਚਿਤ ਸਮਾਂ-ਸੀਮਾ ਤੋਂ ਬਾਅਦ ਨਿਸ਼ਕਿਰਿਆ ਪ੍ਰਵਾਹ ਬੰਦ ਕਰਦਾ ਹੈ, ਇਹ ਨੋਟ ਲਿਖੇ ਜਾਣ ਵੇਲੇ ਡਿਫਾਲਟ ਚਾਰ ਮਿੰਟ ਅਤੇ ਉੱਪਰ ਵੱਲ ਸੰਰਚਿਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਇਸ ਲਈ keepalive ਤੋਂ ਬਿਨਾਂ VM 'ਤੇ OpenVPN ਸਰਵਰ ਹਰ ਕੁਝ ਮਿੰਟਾਂ ਬਾਅਦ ਡਿੱਗ ਸਕਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਬਾਕੀ ਸਭ ਕੁਝ ਸਿਹਤਮੰਦ ਦਿਖਦਾ ਹੈ। ਪਲੇਟਫਾਰਮ ਜਿਸ ਗੇਟਵੇ ਨੂੰ ਚੱਕਰੀ ਤੌਰ 'ਤੇ ਮੁੜ ਚਾਲੂ ਕਰਦਾ ਹੈ, ਉਹ ਵੀ VNet ਕਨੈਕਸ਼ਨ ਨੂੰ Web App ਨਾਲ ਰੋਕ ਸਕਦਾ ਹੈ, ਅਤੇ ਉਹ ਅਸਫਲਤਾ ਕਲਾਇੰਟ ਸੰਰਚਨਾ ਵਿੱਚ ਨਹੀਂ, ਪਲੇਟਫਾਰਮ ਦੇ ਪਾਸੇ ਹੈ। ਸੰਕੇਤ ਇਹ ਹੈ ਕਿ ਟੁੱਟਣਾ ਨਿਸ਼ਚਿਤ ਅੰਤਰਾਲ ਦੀ ਪਾਲਣਾ ਕਰਦਾ ਹੈ ਜਾਂ ਤੁਹਾਡੇ ਕੀਤੇ ਬਦਲਾਅ ਦੀ।

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

ਫਿਰ ਉਸੇ ਕ੍ਰਮ ਵਿੱਚ ਜਾਂਚ ਕਰੋ ਜਿਸ ਵਿੱਚ ਤੁਸੀਂ ਬਦਲਿਆ: ਸਥਾਨਕ ਨੈੱਟਵਰਕ ਗੇਟਵੇ ਨਵੀਂ ਪ੍ਰੀਫਿਕਸ ਸੂਚੀ ਦਿਖਾਉਂਦਾ ਹੈ, ਕਨੈਕਸ਼ਨ ਦੁਬਾਰਾ Connected ਹੈ, ਅਤੇ ਨਵੀਂ ਰੇਂਜ ਦੇ ਹੋਸਟ 'ਤੇ ਟ੍ਰੈਫਿਕ ਭੇਜਣ 'ਤੇ ਕਾਊਂਟਰ ਹਿੱਲਦੇ ਹਨ। ਜੇ ਪਹਿਲੇ ਦੋ ਪਾਸ ਹੋਣ 'ਤੇ ਤੀਜਾ ਕਦਮ ਅਸਫਲ ਹੋਵੇ, ਤਾਂ ਦੂਰ ਦੇ ਪਾਸੇ ਨੇ ਨਵਾਂ ਟ੍ਰੈਫਿਕ ਚੋਣਕਾਰ ਸਵੀਕਾਰ ਨਹੀਂ ਕੀਤਾ ਅਤੇ ਦੂਰ ਦੇ ਡਿਵਾਈਸ ਨੂੰ ਮਿਲਦੀ ਪੜਾਅ 2 ਐਂਟਰੀ ਚਾਹੀਦੀ ਹੈ। ਇਹ ਟਨਲ ਦੇ ਦੂਜੇ ਸਿਰੇ ਨਾਲ ਗੱਲਬਾਤ ਹੈ, Azure ਵਿੱਚ ਇੱਕ ਹੋਰ ਬਦਲਾਅ ਨਹੀਂ।