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