ਕੀ ਪੀਅਰ ਕੀਤੇ Azure VNet ਨੂੰ ਆਪਣਾ VPN ਗੇਟਵੇ ਚਾਹੀਦਾ ਹੈ?
ਪੀਅਰ ਕੀਤੇ VNet ਲਈ ਸਮਰਥਿਤ SKU ਅਤੇ ਹਰ ਪੀਅਰਿੰਗ ਦਿਸ਼ਾ ਵਿੱਚ ਇੱਕ ਸੈਟਿੰਗ ਨਾਲ ਹਬ ਦਾ VPN ਗੇਟਵੇ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਪੀਅਰਿੰਗ ਸਥਿਤੀ ਨਹੀਂ, ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਰੂਟ ਜਾਂਚੋ।
ਇੱਕ ਨਵਾਂ spoke VNet ਆਉਂਦਾ ਹੈ, hub ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਕੰਮ ਕਰਦਾ site-to-site ਗੇਟਵੇ ਹੈ, ਅਤੇ ਸਪਸ਼ਟ ਸਵਾਲ ਇਹ ਹੈ ਕਿ ਕੀ ਤੁਹਾਨੂੰ ਦੂਜੇ ਗੇਟਵੇ ਲਈ ਭੁਗਤਾਨ ਕਰਨਾ ਪਵੇਗਾ। ਆਮ ਤੌਰ 'ਤੇ ਨਹੀਂ: ਗੇਟਵੇ ਟ੍ਰਾਂਜ਼ਿਟ spoke ਨੂੰ peering ਰਾਹੀਂ hub ਦੇ ਗੇਟਵੇ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ। ਤਿੰਨ ਸ਼ਰਤਾਂ ਤੈਅ ਕਰਦੀਆਂ ਹਨ ਕਿ ਇਹ ਕੰਮ ਕਰੇਗਾ ਜਾਂ ਨਹੀਂ, ਅਤੇ ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ peering ਸਥਿਤੀ ਬੈਜ ਤੋਂ ਨਹੀਂ ਦਿਸਦੀ। peering ਕਨੈਕਟੀਵਿਟੀ ਅਤੇ ਕਿਸੇ ਹੋਰ ਦੇ ਗੇਟਵੇ ਦੀ ਵਰਤੋਂ ਦੀ ਆਗਿਆ ਵੱਖਰੀਆਂ ਸੈਟਿੰਗਾਂ ਹਨ, ਇਸ ਲਈ ਪਹਿਲਾਂ ਹੀ ਇੱਕ ਦੂਜੇ ਨੂੰ ping ਕਰ ਸਕਣ ਵਾਲੇ ਦੋ VM VPN ਰਾਹ ਬਾਰੇ ਕੁਝ ਵੀ ਸਾਬਤ ਨਹੀਂ ਕਰਦੇ।
ਪਹਿਲੀ ਸ਼ਰਤ: ਗੇਟਵੇ, ਅਤੇ spoke ਵਿੱਚ ਇਸ ਦੀ ਗੈਰਹਾਜ਼ਰੀ
Azure Basic ਤੋਂ ਇਲਾਵਾ ਹੋਰ VPN Gateway SKU ਲਈ ਗੇਟਵੇ ਟ੍ਰਾਂਜ਼ਿਟ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ, ਅਤੇ ਖੇਤਰੀ ਅਤੇ ਵਿਸ਼ਵਵਿਆਪੀ ਦੋਵੇਂ peering ਇਸ ਨੂੰ ਲੈ ਜਾ ਸਕਦੇ ਹਨ। spoke ਉਹ ਗੇਟਵੇ ਵਰਤਦਾ ਹੈ ਜੋ ਉਸਦਾ ਨਹੀਂ ਹੈ, ਇਸ ਲਈ ਉਸਦਾ ਆਪਣਾ ਗੇਟਵੇ ਨਹੀਂ ਹੋ ਸਕਦਾ: ਜੇ spoke ਵਿੱਚ ਪਹਿਲਾਂ ਹੀ ਗੇਟਵੇ ਮੌਜੂਦ ਹੈ, ਜਾਂ ਦੂਰਸਥ ਗੇਟਵੇ ਵਿਕਲਪ ਪਹਿਲਾਂ ਹੀ ਚੁਣਿਆ ਗਿਆ ਹੈ, ਤਾਂ ਤੁਹਾਡੀ ਲੋੜੀਂਦੀ ਟ੍ਰਾਂਜ਼ਿਟ ਸੈਟਿੰਗ ਉਪਲਬਧ ਨਹੀਂ ਹੋਵੇਗੀ ਜਾਂ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਨਹੀਂ ਹੋਵੇਗੀ। ਕੁਝ ਵੀ ਡੀਬੱਗ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇਹ ਜਾਂਚੋ, ਕਿਉਂਕਿ ਬੰਦ ਚੈੱਕਬਾਕਸ ਲੱਛਣ ਹੈ, ਖਰਾਬੀ ਨਹੀਂ। ਪਹਿਲਾਂ SKU ਅਤੇ ਮੌਜੂਦਾ ਗੇਟਵੇ ਪੜ੍ਹੋ, ਫਿਰ peering ਸੈਟਿੰਗਾਂ ਵੇਖੋ।
ਵਿਕਲਪ ਦਿਖਾਉਣ ਲਈ ਮੌਜੂਦਾ spoke ਗੇਟਵੇ ਨੂੰ ਨਾ ਹਟਾਓ, ਜਦੋਂ ਤੱਕ ਤੁਸੀਂ ਨਹੀਂ ਜਾਣਦੇ ਕਿ ਇਸ ਉੱਤੇ ਕੀ ਨਿਰਭਰ ਹੈ। ਮਾਈਗ੍ਰੇਸ਼ਨ ਕ੍ਰਮ ਚੈੱਕਬਾਕਸ ਤੋਂ ਵੱਧ ਮਹੱਤਵਪੂਰਨ ਹੈ।
ਦੂਜੀ ਸ਼ਰਤ: ਹਰ peering ਦਿਸ਼ਾ ਵਿੱਚ ਇੱਕ ਸੈਟਿੰਗ
peering ਦੋ ਆਬਜੈਕਟ ਹਨ, ਹਰ VNet ਉੱਤੇ ਇੱਕ, ਅਤੇ ਟ੍ਰਾਂਜ਼ਿਟ ਸੈਟਿੰਗਾਂ ਉਸ ਜੋੜੀ ਦੇ ਵੱਖਰੇ ਪਾਸਿਆਂ ਉੱਤੇ ਰਹਿੰਦੀਆਂ ਹਨ। hub ਦਾ spoke ਵੱਲ peering, hub ਗੇਟਵੇ ਨੂੰ spoke ਦੀ ਸੇਵਾ ਕਰਨ ਦੀ ਆਗਿਆ ਦੇਣੀ ਚਾਹੀਦੀ ਹੈ; spoke ਦਾ hub ਵੱਲ peering, hub ਦੇ ਗੇਟਵੇ ਨੂੰ ਸਵੀਕਾਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। Microsoft ਦੀ ਗੇਟਵੇ-ਟ੍ਰਾਂਜ਼ਿਟ ਗਾਈਡ ਦਿਸ਼ਾ ਅਨੁਸਾਰ ਉਹਨਾਂ ਦੇ ਨਾਮ ਦਿੰਦੀ ਹੈ, ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਸਹੀ ਰੱਖਣ ਦਾ ਇਹੀ ਇੱਕੋ ਤਰੀਕਾ ਹੈ:
| Peering direction | What to enable |
|---|---|
| Hub → spoke | Allow gateway transit on the hub's peering |
| Spoke → hub | Use remote gateways on the spoke's peering |
remote ਲੇਬਲ ਵਾਲਾ ਨਿਯੰਤਰਣ ਤੁਹਾਡੇ ਦੁਆਰਾ ਕਿਸ VNet ਦੀ peering ਸੰਪਾਦਿਤ ਕਰਨ 'ਤੇ ਨਿਰਭਰ ਕਰਦਿਆਂ ਅਰਥ ਬਦਲਦਾ ਹੈ, ਇਸ ਲਈ ਸ਼ਬਦ ਨਹੀਂ, ਦਿਸ਼ਾ ਪੜ੍ਹੋ। ਦੋਵੇਂ ਪਾਸੇ ਸੈੱਟ ਕਰੋ, ਸੰਭਾਲੋ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ peering ਦੋਵੇਂ ਥਾਵਾਂ 'ਤੇ ਜੁੜੀ ਹੋਣ ਦੀ ਰਿਪੋਰਟ ਕਰਦੀ ਹੈ।
ਤੀਜੀ ਸ਼ਰਤ: ਪਤਾ ਸਥਾਨ ਅਤੇ ਆਗਿਆ ਸੀਮਾਵਾਂ
ਟ੍ਰਾਂਜ਼ਿਟ ਇੱਕੋ ਗੰਤਵ ਪ੍ਰੀਫਿਕਸ ਨੂੰ ਦੋ ਨੈੱਟਵਰਕ ਦਾ ਅਰਥ ਨਹੀਂ ਦੇ ਸਕਦਾ, ਇਸ ਲਈ hub, spoke ਅਤੇ ਸਥਾਨਕ ਨੈੱਟਵਰਕ ਦੀਆਂ ਰੇਂਜਾਂ ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੁਝ ਵੀ ਕੰਮ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਵੱਖਰੀਆਂ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ। VNet ਭਿੰਨ ਗਾਹਕੀਆਂ ਜਾਂ ਭਿੰਨ ਟੈਨੈਂਟਾਂ ਵਿੱਚ ਵੀ ਹੋ ਸਕਦੇ ਹਨ; ਇਹ ਵਰਜਨਾ ਨਹੀਂ, ਪਰ ਹਰ peering ਬਣਾਉਣ ਜਾਂ ਅੱਪਡੇਟ ਕਰਨ ਵਾਲੀ ਪਛਾਣ ਕੋਲ ਉਸ ਨੈੱਟਵਰਕ 'ਤੇ ਲੋੜੀਂਦੀਆਂ ਆਗਿਆਵਾਂ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ। ਗਾਹਕੀਆਂ ਦਰਮਿਆਨ ਤਬਦੀਲੀਆਂ ਅਕਸਰ ਆਗਿਆ 'ਤੇ ਅਸਫਲ ਹੁੰਦੀਆਂ ਹਨ, ਅਤੇ ਗਲਤੀ ਨੂੰ ਟੋਪੋਲੋਜੀ ਸਮੱਸਿਆ ਵਜੋਂ ਗਲਤ ਪੜ੍ਹਨਾ ਆਸਾਨ ਹੈ।
ਤਬਦੀਲੀ ਤੋਂ ਪਹਿਲਾਂ ਰੇਂਜਾਂ ਅਤੇ ਮਾਲਕ ਲਿਖੋ। ਦੋਵਾਂ ਵਿੱਚੋਂ ਕਿਸੇ ਦਾ ਅੰਦਾਜ਼ਾ ਲਗਾਉਣ ਨਾਲ ਅਜਿਹੀ peering ਬਣਦੀ ਹੈ ਜੋ ਜੁੜਦੀ ਹੈ ਪਰ ਕੁਝ ਵੀ ਰੂਟ ਨਹੀਂ ਕਰਦੀ।
peering ਸਥਿਤੀ ਨਾਲ ਨਹੀਂ, ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਰੂਟਾਂ ਨਾਲ ਪੁਸ਼ਟੀ ਕਰੋ
spoke ਵਰਕਲੋਡ ਦੇ ਨੈੱਟਵਰਕ ਇੰਟਰਫੇਸ 'ਤੇ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਰੂਟ ਵੇਖੋ ਅਤੇ ਅਸਲ ਸਥਾਨਕ ਪ੍ਰੀਫਿਕਸ ਲੱਭੋ। ਸਬਨੈੱਟ ਦੀ ਰੂਟ ਟੇਬਲ ਅਤੇ ਗੇਟਵੇ ਰੂਟ ਪ੍ਰਸਾਰ ਬੰਦ ਹੈ ਜਾਂ ਨਹੀਂ ਇਹ ਜਾਂਚੋ, ਕਿਉਂਕਿ ਉਪਭੋਗਤਾ-ਪਰਿਭਾਸ਼ਿਤ ਰੂਟ ਜਾਂ ਨਿਰੀਖਣ ਉਪਕਰਣ peering ਫਲੈਗਾਂ ਵੱਲੋਂ ਸੁਝਾਏ ਰਾਹ ਨੂੰ ਓਵਰਰਾਈਡ ਕਰ ਸਕਦੇ ਹਨ। ਫਿਰ ਦੂਜੀ ਦਿਸ਼ਾ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ: ਸਥਾਨਕ ਨੈੱਟਵਰਕ ਨੂੰ site-to-site ਕਨੈਕਸ਼ਨ ਰਾਹੀਂ spoke ਪ੍ਰੀਫਿਕਸ ਤੱਕ ਪਹੁੰਚਣ ਦਾ ਤਰੀਕਾ ਪਤਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਭਾਵੇਂ ਸਿੱਖੇ ਇਸ਼ਤਿਹਾਰਾਂ ਰਾਹੀਂ ਜਾਂ ਸਪਸ਼ਟ ਰੂਟ ਅਤੇ ਗਾਹਕ ਡਿਵਾਈਸ 'ਤੇ ਮੇਲ ਖਾਂਦੀ ਸੁਰੱਖਿਅਤ-ਨੈੱਟਵਰਕ ਐਂਟਰੀ ਰਾਹੀਂ। ਜੇ ਪ੍ਰੀਫਿਕਸ ਕਿਸੇ ਵੀ ਪਾਸੇ ਗਾਇਬ ਹੈ, ਤਾਂ ਬਦਲਣ ਵਾਲੀ ਚੀਜ਼ peering ਫਲੈਗ ਨਹੀਂ ਹਨ।
spoke ਵਰਕਲੋਡ ਤੋਂ ਇੱਕ ਸੇਵਾ ਦੀ ਜਾਂਚ ਕਰੋ ਅਤੇ ਜਵਾਬ ਦਾ ਪਿੱਛਾ ਕਰੋ। VPN ਗੇਟਵੇ ਜਾਂ hub VM ਤੋਂ ਜਾਂਚ ਵੱਖਰਾ ਸਰੋਤ ਪ੍ਰੀਫਿਕਸ ਅਤੇ ਵੱਖਰਾ ਰਾਹ ਵਰਤਦੀ ਹੈ।
ਜੇ ਟੋਪੋਲੋਜੀ point-to-site ਗਾਹਕਾਂ ਦੀ ਵੀ ਸੇਵਾ ਕਰਦੀ ਹੈ, ਤਾਂ ਉਹਨਾਂ ਦੇ ਸਥਾਪਿਤ ਰੂਟ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਪ੍ਰਮਾਣਿਤ ਕਰੋ। ਟੋਪੋਲੋਜੀ ਤਬਦੀਲੀ ਤੋਂ ਬਾਅਦ Windows ਗਾਹਕ ਪੈਕੇਜ ਦੁਬਾਰਾ ਬਣਾਉਣ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ, ਅਤੇ ਇਹ ਗੇਟਵੇ ਸਾਂਝਾਕਰਨ ਅਸਫਲ ਹੋਣ ਦਾ ਸਬੂਤ ਨਹੀਂ, ਗਾਹਕ ਰੂਟਿੰਗ ਦਾ ਕੰਮ ਹੈ।
ਗੇਟਵੇ ਸਾਂਝਾ ਕਰਨ ਨਾਲ ਕੀ ਨਹੀਂ ਮਿਲਦਾ
ਗੇਟਵੇ ਟ੍ਰਾਂਜ਼ਿਟ ਰੂਟਿੰਗ ਸੁਵਿਧਾ ਹੈ, ਪ੍ਰਮਾਣਿਕਤਾ ਨਹੀਂ। ਨੈੱਟਵਰਕ ਸੁਰੱਖਿਆ ਸਮੂਹ, ਸਥਾਨਕ ਫਿਲਟਰ ਅਤੇ ਸੇਵਾ-ਪੱਧਰ ਦੇ ਨਿਯਮ ਅਜੇ ਵੀ ਤੈਅ ਕਰਦੇ ਹਨ ਕਿ spoke ਵਰਕਲੋਡ ਕਿੱਥੇ ਤੱਕ ਪਹੁੰਚ ਸਕਦਾ ਹੈ, ਇਸ ਲਈ ਸਾਂਝੇ ਟਨਲ ਇਸਦੇ ਪਿੱਛੇ ਸਭ ਕੁਝ ਮਨਜ਼ੂਰ ਕਰਦਾ ਹੈ ਇਹ ਮੰਨਣ ਦੀ ਬਜਾਏ ਖਾਸ ਸਰੋਤ-ਤੋਂ-ਗੰਤਵ ਸੇਵਾ ਨੂੰ ਸਮਰੱਥ ਕਰੋ।
peering ਵੀ ਉਸ ਤਰੀਕੇ ਨਾਲ ਪਾਰਗਾਮੀ ਨਹੀਂ ਜਿਵੇਂ ਲੋਕ ਆਸ ਕਰਦੇ ਹਨ। ਇੱਕ ਹੋਰ spoke ਜਾਂ ਨਿੱਜੀ ਐਂਡਪੌਇੰਟ ਜੋੜਨ ਨਾਲ ਇਸ ਦੀਆਂ ਆਪਣੀਆਂ ਰੂਟਿੰਗ ਅਤੇ ਪਹੁੰਚ ਲੋੜਾਂ ਆਉਂਦੀਆਂ ਹਨ ਜੋ ਮੌਜੂਦਾ ਟ੍ਰਾਂਜ਼ਿਟ ਸੈਟਿੰਗ ਕਵਰ ਨਹੀਂ ਕਰਦੀ।