NAT ਪਿੱਛੇ ਪੀਅਰ ਨਾਲ Azure ਸਾਈਟ-ਤੋਂ-ਸਾਈਟ VPN: ਜਾਂਚ ਸੂਚੀ

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

ਕਦਮ 1: ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਪੀਅਰ ਸੱਚਮੁੱਚ NAT ਪਿੱਛੇ ਹੈ

ਡਿਵਾਈਸ ਦੇ WAN ਇੰਟਰਫ਼ੇਸ ਦੇ ਪਤੇ ਦੀ ਤੁਲਨਾ Azure ਉਸ ਲਈ ਜੋ ਪਤਾ ਦੇਖਦਾ ਹੈ ਉਸ ਨਾਲ ਕਰੋ। ਜੇ ਉਹ ਵੱਖਰੇ ਹਨ, ਤਾਂ ਕੁਝ ਅਨੁਵਾਦ ਕਰ ਰਿਹਾ ਹੈ, ਅਤੇ ਉਹ ਅਨੁਵਾਦਕ ਹੁਣ ਤੁਹਾਡੇ VPN ਡਿਜ਼ਾਈਨ ਦਾ ਹਿੱਸਾ ਹੈ। ਪ੍ਰਦਾਤਾ ਨੂੰ ਪੁੱਛੋ ਕਿ ਮੈਪਿੰਗ ਸਥਿਰ ਹੈ ਜਾਂ ਸਾਂਝੀ, ਕਿਉਂਕਿ ਸਾਂਝੀ ਮੈਪਿੰਗ ਬਦਲ ਦਿੰਦੀ ਹੈ ਕਿ ਤੁਸੀਂ ਕੀਸ ’ਤੇ ਭਰੋਸਾ ਕਰ ਸਕਦੇ ਹੋ। ਨਿੱਜੀ WAN ਪਤਾ ਅਤੇ ਫਾਰਵਰਡਿੰਗ ਤੋਂ ਬਿਨਾਂ ਡਿਵਾਈਸ ਸਥਿਰ ਜਨਤਕ ਮੈਪਿੰਗ ਵਾਲੇ ਕੈਰੀਅਰ-ਗ੍ਰੇਡ NAT ਪਿੱਛੇ ਵਾਲੇ ਡਿਵਾਈਸ ਤੋਂ ਵੱਖਰਾ ਕੇਸ ਹੈ।

ਜੇ ਦੋਵੇਂ ਪਤੇ ਮਿਲਦੇ ਹਨ, ਇੱਥੇ ਹੀ ਰੁਕੋ: NAT ਤੁਹਾਡੀ ਸਮੱਸਿਆ ਨਹੀਂ ਹੈ ਅਤੇ ਇਸ ਸੂਚੀ ਦਾ ਬਾਕੀ ਹਿੱਸਾ ਮਦਦ ਨਹੀਂ ਕਰੇਗਾ।

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

ਕਦਮ 2: ਕੌਣ ਸ਼ੁਰੂ ਕਰੇਗਾ ਇਸ ’ਤੇ ਸਹਿਮਤ ਹੋਵੋ

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

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

ਦਸਤੀ ਸ਼ੁਰੂਆਤ ਦੌਰਾਨ ਡਿਵਾਈਸ ’ਤੇ IKE ਦਾ ਆਦਾਨ-ਪ੍ਰਦਾਨ ਦੇਖੋ; ਉੱਥੇ ਚੁੱਪ ਰੂਟਿੰਗ ਜਾਂ ਫਾਇਰਵਾਲ ਦਾ ਜਵਾਬ ਹੈ, Azure ਦਾ ਨਹੀਂ।

ਕਦਮ 3: ਪੀਅਰ ਦਾ ਪਤਾ ਸਹੀ ਲਵੋ

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

ਜੇ ਜਨਤਕ ਪਤਾ ਬਦਲਦਾ ਹੈ, ਤਾਂ ਉਹ ਆਬਜੈਕਟ ਵੀ ਉਸ ਨਾਲ ਬਦਲਣਾ ਚਾਹੀਦਾ ਹੈ। ਪੁਰਾਣੇ ਪਤੇ ’ਤੇ ਰਿਜ਼ੋਲਵ ਹੋਣ ਵਾਲਾ ਨਾਮ ਹੱਥੀਂ ਅੱਪਡੇਟ ਕਰਨ ਵਾਲੇ ਸਥਿਰ ਪਤੇ ਤੋਂ ਵੀ ਮਾੜਾ ਹੈ।

ਤਿੰਨੇ ਮੁੱਲ ਲਿਖੋ: ਡਿਵਾਈਸ ਦਾ ਲੋਕਲ ਪਤਾ, ਅਨੁਵਾਦਿਤ ਜਨਤਕ ਪਤਾ, ਸੰਰਚਿਤ ਪੀਅਰ ਪਛਾਣ।

ਕਦਮ 4: ਸਿਰਫ਼ ਉਹ ਪੋਰਟ ਖੋਲ੍ਹੋ ਜੋ NAT-T ਨੂੰ ਚਾਹੀਦੇ ਹਨ

NAT-T UDP ਦੇ ਅੰਦਰ ESP ਢੋਂਦਾ ਹੈ, ਅਤੇ RFC 3948 ਉਸ ਐਨਕੈਪਸੂਲੇਸ਼ਨ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ ਜਿਸ ਵਿੱਚ ਪੋਰਟ 500 ’ਤੇ ਸ਼ੁਰੂਆਤੀ ਗੱਲਬਾਤ ਤੋਂ ਬਾਅਦ ਪੋਰਟ 4500 ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ। ਤੁਹਾਡੇ ਫਾਇਰਵਾਲ ਅਤੇ ਅਨੁਵਾਦਕ ਦੋਵਾਂ ਨੂੰ ਇਹ ਆਦਾਨ-ਪ੍ਰਦਾਨ ਅਤੇ ਇਸ ਦੀ ਵਾਪਸੀ ਆਵਾਜਾਈ ਦੀ ਆਗਿਆ ਦੇਣੀ ਚਾਹੀਦੀ ਹੈ। ਅਸੰਬੰਧਿਤ TCP ਪੋਰਟ ਦੀ ਆਗਿਆ ਦੇਣ ਨਾਲ ਇਸ ਰਸਤੇ ਬਾਰੇ ਕੁਝ ਸਾਬਤ ਨਹੀਂ ਹੁੰਦਾ, ਅਤੇ ਬਾਹਰ ਜਾਣ ਦੀ ਆਗਿਆ ਦੇਣ ਪਰ ਜਵਾਬ ਦੀ ਨਾ ਦੇਣ ਵਾਲਾ ਨਿਯਮ ਵੀ ਫੇਲ੍ਹ ਹੋਵੇਗਾ।

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

ਅਨੁਵਾਦਕ ਦੇ ਦੋਵੇਂ ਪਾਸਿਆਂ ’ਤੇ ਇੱਕ ਵਾਰ ਕੈਪਚਰ ਕਰੋ; ਐਨਕੈਪਸੂਲੇਸ਼ਨ ਦਾ ਫ਼ਰਕ ਤੁਰੰਤ ਦਿਖਦਾ ਹੈ।

ਕਦਮ 5: ਬਾਹਰਲੀ ਆਵਾਜਾਈ ਨੂੰ ਅੰਦਰਲੀ ਰੂਟਿੰਗ ਤੋਂ ਵੱਖ ਕਰੋ

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

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

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