ਦੋ ਆਨ-ਪ੍ਰੈਮ VPN ਪਤੇ: ਦੋ Azure ਪੀਅਰ, ਇੱਕ ਨਹੀਂ
ਦੂਜਾ ਆਨ-ਪ੍ਰੈਮ VPN ਪਤਾ ਇੱਕ ਹੋਰ ਪੀਅਰ ਹੈ, ਦੂਜਾ ਫੀਲਡ ਮੁੱਲ ਨਹੀਂ। ਹਰ ਡਿਵਾਈਸ ਲਈ ਇੱਕ ਸਥਾਨਕ ਨੈੱਟਵਰਕ ਗੇਟਵੇ ਅਤੇ ਇੱਕ ਕਨੈਕਸ਼ਨ, ਫਿਰ ਟਨਲ ਗਿਣੋ।
ਡਾਇਗ੍ਰਾਮ ਵਿੱਚ ਸ਼ਾਖਾ ਵਿੱਚ ਦੋ ਇੰਟਰਨੈੱਟ ਲਿੰਕ ਅਤੇ Azure ਵਿੱਚ ਇੱਕ VPN ਗੇਟਵੇ ਹੈ, ਇਸ ਲਈ ਸਥਾਨਕ ਨੈੱਟਵਰਕ ਗੇਟਵੇ ਨੂੰ ਦੋਵੇਂ ਜਨਤਕ ਪਤੇ ਮਿਲਦੇ ਹਨ। ਇਹ ਸਾਫ਼ ਦਿਖਦਾ ਹੈ, ਅਤੇ ਡਾਇਗ੍ਰਾਮ ਜਿਵੇਂ ਸੰਕੇਤ ਦਿੰਦਾ ਹੈ ਉਸ ਤਰ੍ਹਾਂ ਕੰਮ ਨਹੀਂ ਕਰਦਾ। ਹਰ ਆਨ-ਪ੍ਰੈਮ VPN ਡਿਵਾਈਸ ਇੱਕ ਵੱਖਰਾ ਪੀਅਰ ਸੰਬੰਧ ਹੈ, ਅਤੇ Microsoft ਦਾ ਬਹੁ-ਡਿਵਾਈਸ ਡਿਜ਼ਾਈਨ ਹਰ ਇੱਕ ਨੂੰ ਆਪਣਾ ਸਥਾਨਕ ਨੈੱਟਵਰਕ ਗੇਟਵੇ ਸਰੋਤ ਅਤੇ ਆਪਣਾ ਕਨੈਕਸ਼ਨ ਦਿੰਦਾ ਹੈ। ਇੱਕੋ ਸਰੋਤ ਵਿੱਚ ਦੂਜਾ ਪਤਾ ਜੋੜਨ ਨਾਲ ਦੂਜਾ ਪੀਅਰ ਨਹੀਂ ਬਣਦਾ। ਇਹ ਅਜਿਹਾ ਸਰੋਤ ਬਣਾਉਂਦਾ ਹੈ ਜੋ ਕਿਸੇ ਵੀ ਡਿਵਾਈਸ ਦਾ ਠੀਕ ਵਰਣਨ ਨਹੀਂ ਕਰਦਾ।
ਮਿੱਥ: ਇੱਕ ਗੇਟਵੇ, ਦੋ ਪਤੇ
ਸਥਾਨਕ ਨੈੱਟਵਰਕ ਗੇਟਵੇ ਦੂਰ ਦੇ ਪੀਅਰ ਦਾ ਵਰਣਨ ਹੈ: ਇੱਕ ਜਨਤਕ ਐਂਡਪੌਇੰਟ ਅਤੇ ਇਸਦੇ ਪਿੱਛੇ ਦੇ ਨਿੱਜੀ ਪ੍ਰੀਫਿਕਸ। ਉਸ ਸਰੋਤ ਨੂੰ «ਇਹਨਾਂ ਦੋਵਾਂ ਡਿਵਾਈਸਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ» ਦਾ ਅਰਥ ਦੇਣ ਦਾ ਕੋਈ ਸਮਰਥਿਤ ਤਰੀਕਾ ਨਹੀਂ ਹੈ।
ਇਹੀ ਉਲਝਣ ਉਲਟ ਦਿਸ਼ਾ ਵਿੱਚ ਵੀ ਹੈ, ਜਿੱਥੇ Azure ਦੇ ਦੋ ਜਨਤਕ IP ਨੂੰ ਦੋ Azure ਗੇਟਵੇ ਹੋਣ ਦੇ ਸਬੂਤ ਵਜੋਂ ਪੜ੍ਹਿਆ ਜਾਂਦਾ ਹੈ।
ਪਹਿਲਾਂ ਵਸਤੂਆਂ ਗਿਣੋ, ਫਿਰ ਟਨਲ
ਇੱਕੋ ਨਿੱਜੀ ਨੈੱਟਵਰਕ ਤੱਕ ਪਹੁੰਚ ਅਤੇ ਆਪਣਾ ਜਨਤਕ ਪਤਾ ਰੱਖਣ ਵਾਲੇ ਦੋ ਸੁਤੰਤਰ ਤੌਰ 'ਤੇ ਚਲਾਏ ਜਾਂਦੇ ਆਨ-ਪ੍ਰੈਮ ਡਿਵਾਈਸ ਲਓ, ਨਾਲ ਹੀ ਸਰਗਰਮ-ਸਰਗਰਮ ਮੋਡ ਵਿੱਚ ਇੱਕ ਰੂਟ-ਅਧਾਰਿਤ Azure ਗੇਟਵੇ। Azure ਗੇਟਵੇ ਵਿੱਚ ਵੱਖਰੇ ਜਨਤਕ IP ਵਾਲੇ ਦੋ ਸਰਗਰਮ ਇੰਸਟੈਂਸ ਹਨ। ਹਰ ਆਨ-ਪ੍ਰੈਮ ਡਿਵਾਈਸ ਦੋਵੇਂ ਇੰਸਟੈਂਸਾਂ ਨਾਲ ਜੁੜਦਾ ਹੈ। ਇਹੀ ਪੂਰੀ ਜਾਲੀ ਹੈ, ਅਤੇ ਵਸਤੂਆਂ ਦੀ ਗਿਣਤੀ ਡਾਇਗ੍ਰਾਮ ਤੋਂ ਨਹੀਂ, ਇਸ ਤੋਂ ਆਉਂਦੀ ਹੈ।
ਗਣਨਾ ਡਿਜ਼ਾਈਨ ਦਸਤਾਵੇਜ਼ ਵਿੱਚ ਪੇਸਟ ਕਰਨ ਲਈ ਕਾਫ਼ੀ ਛੋਟੀ ਹੈ:
2 on-premises VPN devices
2 local network gateway resources
2 connection resources
4 IPsec tunnels in the complete 2 x 2 mesh
ਇੱਕ ਕਨੈਕਸ਼ਨ ਸਰੋਤ ਇੱਕ ਤੋਂ ਵੱਧ ਅਧਾਰਭੂਤ ਟਨਲ ਲੈ ਕੇ ਜਾ ਸਕਦਾ ਹੈ, ਇਸ ਲਈ ਚਾਰ ਟਨਲ ਦਾ ਮਤਲਬ ਚਾਰ ਵਰਚੁਅਲ ਨੈੱਟਵਰਕ ਗੇਟਵੇ ਨਹੀਂ ਹੈ। Azure ਦੇ ਦੋ ਜਨਤਕ IP ਵੀ ਦੂਰ ਦੀ ਸਾਈਟ ਦਾ ਵਰਣਨ ਕਰਨ ਵਾਲੇ ਦੋ ਸਥਾਨਕ ਨੈੱਟਵਰਕ ਗੇਟਵੇ ਵਰਗੇ ਉਹੀ ਵਸਤੂਆਂ ਨਹੀਂ ਹਨ।
Azure ਪਾਸੇ ਸਰਗਰਮ-ਸਰਗਰਮ ਕੀ ਜੋੜਦਾ ਹੈ
ਸਰਗਰਮ-ਸਰਗਰਮ Azure ਗੇਟਵੇ ਨੂੰ ਇੱਕ ਸਰਗਰਮ ਇੰਸਟੈਂਸ ਤੋਂ ਦੋ ਵਿੱਚ ਬਦਲਦਾ ਹੈ, ਹਰ ਇੱਕ ਦਾ ਆਪਣਾ ਜਨਤਕ IP ਹੁੰਦਾ ਹੈ, ਅਤੇ ਇਹੀ ਪੂਰੀ ਜਾਲੀ ਨੂੰ ਬਿਲਕੁਲ ਸੰਭਵ ਬਣਾਉਂਦਾ ਹੈ। ਇਹ ਇੱਕ ਫਲੋ ਦੀ ਥਰੂਪੁਟ ਦੁੱਗਣੀ ਨਹੀਂ ਕਰਦਾ। ਜੇ ਦੋਵੇਂ ਡਿਵਾਈਸ ਇਕੱਠੇ ਫਾਰਵਰਡ ਕਰਦੇ ਹਨ ਤਾਂ ਇਹ ਆਨ-ਪ੍ਰੈਮ ਪਾਸੇ ਨੂੰ ਸਮਾਨ-ਲਾਗਤ ਮਲਟੀਪਾਥ ਸਮਰਥਨ ਕਰਨ ਦੀ ਲੋੜ ਵੀ ਨਹੀਂ ਹਟਾਉਂਦਾ। ਕੁਝ ਵੀ ਪ੍ਰੋਵਿਜ਼ਨ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਗੇਟਵੇ ਮੋਡ, SKU ਅਤੇ ਦੂਰ ਦੇ ਡਿਵਾਈਸ ਦੀ ਸਮਰੱਥਾ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ।
ਨਿਸ਼ਕਿਰਿਆ-ਸਟੈਂਡਬਾਏ ਗੇਟਵੇ ਪੂਰੀ ਤਰ੍ਹਾਂ ਵੈਧ ਡਿਜ਼ਾਈਨ ਹੈ; ਇਹ ਸਿਰਫ਼ ਵੱਖਰੀ ਟਨਲ ਗਿਣਤੀ ਦਿੰਦਾ ਹੈ।
BGP ਦੋਵੇਂ ਮਾਰਗਾਂ ਨੂੰ ਵਰਤਣਯੋਗ ਬਣਾਉਂਦਾ ਹੈ
ਬਹੁ-ਡਿਵਾਈਸ ਡਿਜ਼ਾਈਨ ਲਈ ਦੋਵੇਂ ਆਨ-ਪ੍ਰੈਮ ਡਿਵਾਈਸ BGP ਚਲਾਉਂਦੇ ਹਨ। ਹਰ ਇੱਕ ਨੂੰ ਵਿਲੱਖਣ BGP ਪੀਅਰ ਪਤਾ ਦਿਓ ਅਤੇ ਸੰਬੰਧਿਤ ਮਾਰਗਾਂ 'ਤੇ ਉਹੀ ਇੱਛਤ ਨਿੱਜੀ ਪ੍ਰੀਫਿਕਸ ਐਲਾਨੋ। ਨਿੱਜੀ ਪ੍ਰੀਫਿਕਸ ਸੁਰੱਖਿਅਤ ਨੈੱਟਵਰਕ ਦੀ ਪਛਾਣ ਕਰਦੇ ਹਨ, ਜਦੋਂ ਕਿ ਜਨਤਕ ਪਤੇ ਦੱਸਦੇ ਹਨ ਕਿ ਐਨਕ੍ਰਿਪਟਿਡ ਕੈਰੀਅਰ ਕਨੈਕਸ਼ਨ ਕਿੱਥੇ ਖਤਮ ਹੁੰਦੇ ਹਨ। ਇਹਨਾਂ ਦੋਵਾਂ ਨੂੰ ਮਿਲਾਉਣ ਨਾਲ ਅਜਿਹਾ ਡਿਜ਼ਾਈਨ ਬਣਦਾ ਹੈ ਜਿਸ ਵਿੱਚ ਹਰ ਟਨਲ ਉੱਪਰ ਹੈ ਅਤੇ ਰੂਟ ਗਲਤ ਹਨ।
ਵਾਪਸੀ ਰੂਟਿੰਗ ਅਤੇ ਕੋਈ ਵੀ ਸਟੇਟਫੁਲ ਜਾਂਚ ਦੀ ਯੋਜਨਾ ਬਣਾਓ ਜਿਸ ਨੂੰ ਦੋਵਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਮਾਰਗ ਸਹਿਣਾ ਪਵੇ। ਹਰ ਐਂਡਪੌਇੰਟ 'ਤੇ ਸਿਹਤਮੰਦ IKE ਸੈਸ਼ਨ ਇਹ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ ਕਿ ਕੋਈ ਵਰਕਲੋਡ ਹਰ ਐਲਾਨੇ ਮਾਰਗ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦਾ ਹੈ।
ਫਲੋ-ਅਧਾਰਿਤ ਚੋਣ ਬੈਂਡਵਿਡਥ ਪੂਲਿੰਗ ਨਹੀਂ ਹੈ
Azure ਫਲੋ ਦੇ ਪਤੇ ਅਤੇ ਪੋਰਟਾਂ 'ਤੇ ਹੈਸ਼ ਵਰਤ ਕੇ ਹਰ ਫਲੋ ਲਈ ਇੱਕ ਮਾਰਗ ਚੁਣਦਾ ਹੈ। ਸਥਿਰ ਸਥਿਤੀ ਵਿੱਚ, ਕਿਸੇ ਦਿੱਤੇ TCP ਜਾਂ UDP ਫਲੋ ਦੇ ਪੈਕਟ ਆਮ ਤੌਰ 'ਤੇ ਉਹੀ ਟਨਲ ਲੈਂਦੇ ਹਨ, ਅਤੇ ਆਨ-ਪ੍ਰੈਮ ਪਾਸਾ ਵਾਪਸੀ ਦਿਸ਼ਾ ਲਈ ਵੱਖਰੀ ਟਨਲ ਚੁਣ ਸਕਦਾ ਹੈ। ਇਸ ਲਈ ਦੋ ਡਿਵਾਈਸ ਅਤੇ ਚਾਰ ਟਨਲ ਉਪਲਬਧਤਾ ਸੁਧਾਰਦੇ ਹਨ, ਇੱਕ ਟ੍ਰਾਂਸਫਰ ਦੀ ਗਤੀ ਨਹੀਂ। ਜਦੋਂ ਵਿਕਰੇਤਾ ਦੀ ਸਲਾਈਡ ਐਗਰੀਗੇਸ਼ਨ ਦਾ ਵਾਅਦਾ ਕਰਦੀ ਹੈ, ਤਾਂ ਉਹ ਕੋਈ ਹੋਰ ਵਿਸ਼ੇਸ਼ਤਾ ਜਾਂ ਗਲਤਫਹਿਮੀ ਦੱਸ ਰਹੀ ਹੁੰਦੀ ਹੈ।
ਮਾਰਗ ਕਿਵੇਂ ਫੈਲਦੇ ਹਨ ਦੇਖਣਾ ਚਾਹੁੰਦੇ ਹੋ ਤਾਂ ਸਮਾਨਾਂਤਰ ਫਲੋ ਨਾਲ ਜਾਂਚ ਕਰੋ, ਅਤੇ ਸੀਮਾ ਦੇਖਣੀ ਚਾਹੁੰਦੇ ਹੋ ਤਾਂ ਇੱਕ ਫਲੋ ਨਾਲ।
ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਕਿਹੜੀ ਰਿਡੰਡੈਂਸੀ ਹਟਾਈ
ਇੱਕ ਡਿਵਾਈਸ 'ਤੇ ਦੋ WAN ਪਤੇ ਪਹੁੰਚ-ਲਿੰਕ ਵਿਕਲਪ ਸੁਧਾਰਦੇ ਹਨ, ਪਰ ਉਸ ਡਿਵਾਈਸ ਦੀ ਸ਼ਕਤੀ, ਸੌਫਟਵੇਅਰ ਅਤੇ ਅਸਫਲਤਾ ਸਥਿਤੀ ਸਾਂਝੀ ਕਰਦੇ ਹਨ। ਉਹ ਦੋ ਡਿਵਾਈਸਾਂ ਵਰਗੇ ਨਹੀਂ ਹਨ, ਅਤੇ Azure ਪਾਸੇ ਦਾ ਕੋਈ ਵੀ ਸੰਰਚਨਾ ਇਸ ਨੂੰ ਨਹੀਂ ਬਦਲਦਾ। ਪਤਿਆਂ ਦੀ ਗਿਣਤੀ ਤੋਂ ਰਿਡੰਡੈਂਸੀ ਦਾ ਅਨੁਮਾਨ ਲਗਾਉਣ ਦੀ ਬਜਾਏ ਵਿਕਰੇਤਾ ਦੇ ਸਮਰਥਿਤ ਡਿਊਲ-WAN ਜਾਂ ਕਲਸਟਰ ਡਿਜ਼ਾਈਨ ਦੀ ਪਾਲਣਾ ਕਰੋ। ਫਿਰ ਇਸ ਦੀ ਜਾਂਚ ਕਰੋ: ਇੱਕ ਸਮੇਂ ਵਿੱਚ ਇੱਕ ਮਾਰਗ ਹਟਾਓ ਅਤੇ ਬਾਕੀ ਰੂਟ ਤੇ ਦੋਵੇਂ ਦਿਸ਼ਾਵਾਂ ਵਿੱਚ ਅਸਲ ਐਪਲੀਕੇਸ਼ਨ ਵਟਾਂਦਰੇ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ।
ਖੋਜ ਅਤੇ ਕਨਵਰਜੈਂਸ ਦੇਰੀ ਦੀ ਉਮੀਦ ਕਰੋ, ਅਤੇ ਕੁਝ ਮੌਜੂਦਾ ਸੈਸ਼ਨਾਂ ਦੇ ਖਤਮ ਹੋਣ ਦੀ ਉਮੀਦ ਕਰੋ।