Azure VPN NAT ਓਵਰਲੈਪਿੰਗ VNet ਪਤਿਆਂ ਨੂੰ ਠੀਕ ਨਹੀਂ ਕਰਦਾ
ਇੱਕੋ ਨਿੱਜੀ ਰੇਂਜ ਵਾਲੇ ਦੋ VNet ਸਿਰਫ਼ NAT ਹੋਣ ਕਰਕੇ ਨਹੀਂ ਜੁੜਨਗੇ। ਪਹਿਲਾਂ ਕਨੈਕਸ਼ਨ ਦੀ ਕਿਸਮ ਵੇਖੋ, ਫਿਰ ਦੁਬਾਰਾ ਨੰਬਰ ਦਿਓ ਜਾਂ ਅਨੁਵਾਦ ਉਪਨਾਮ ਦੀ ਮਾਲਕੀ ਰੱਖੋ।
ਦੋਵੇਂ VNet 10.40.1.0/24 ਵਰਤਦੇ ਹਨ, ਟਨਲ ਉੱਪਰ ਆਉਂਦੇ ਹਨ, ਅਤੇ ਕੁਝ ਵੀ ਕੰਮ ਨਹੀਂ ਕਰਦਾ। ਦੂਜਾ VPN ਗੇਟਵੇ ਜੋੜਨ ਨਾਲ ਇਹ ਨਹੀਂ ਬਦਲਦਾ, ਅਤੇ ਨਾ ਹੀ ਘੱਟ ਰੂਟ ਮੈਟ੍ਰਿਕ ਨਾਲ, ਕਿਉਂਕਿ ਸਮੱਸਿਆ ਪਾਥ ਚੋਣ ਵਿੱਚ ਨਹੀਂ ਹੈ। ਇੱਕੋ ਨਿੱਜੀ ਪਤੇ ਨੂੰ ਜਵਾਬ ਦੇਣ ਵਾਲੇ ਦੋ ਵਰਕਲੋਡ ਹਰ ਪੈਕੇਟ ਨੂੰ ਅਸਪਸ਼ਟ ਮੰਜ਼ਿਲ ਅਤੇ ਪੁਸ਼ਟੀ ਨਾ ਹੋਣ ਵਾਲੇ ਵਾਪਸੀ ਰਾਹ ਨਾਲ ਛੱਡਦੇ ਹਨ। ਕਿਸੇ ਵੀ ਅਨੁਵਾਦ ਦੀ ਯੋਜਨਾ ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਪਤਾ ਲਗਾਓ ਕਿ ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਕਿਹੜੀ ਕਨੈਕਸ਼ਨ ਕਿਸਮ ਬਣਾਈ ਹੈ, ਕਿਉਂਕਿ ਉਹੀ ਇੱਕ ਚੋਣ ਤੈਅ ਕਰਦੀ ਹੈ ਕਿ Azure ਦੀ NAT ਸਹੂਲਤ ਬਿਲਕੁਲ ਉਪਲਬਧ ਹੈ ਜਾਂ ਨਹੀਂ।
ਇਹ ਲੱਛਣ ਅਸਲ ਵਿੱਚ ਤੁਹਾਨੂੰ ਕੀ ਦੱਸ ਰਿਹਾ ਹੈ
ਜਦੋਂ VNet A ਦਾ ਹੋਸਟ 10.40.1.10 ਤੇ ਭੇਜਦਾ ਹੈ, ਰੂਟਿੰਗ ਟੇਬਲ ਇਸਨੂੰ ਸਿਰਫ਼ ਕਿਤੇ ਹੀ ਇਸ਼ਾਰਾ ਕਰ ਸਕਦਾ ਹੈ। ਜੇ VNet B ਵਿੱਚ ਵੀ 10.40.1.10 ਹੈ, ਤਾਂ ਉਹ ਪਤਾ ਉਹ ਮੰਜ਼ਿਲ ਨਹੀਂ ਜੋ ਪਾਥ ਵੱਖ ਕਰ ਸਕੇ; ਇਹ ਦੋ ਮਾਲਕਾਂ ਵਾਲਾ ਇੱਕ ਪਤਾ ਹੈ।
ਲੋਕ ਆਮ ਤੌਰ ਤੇ ਜੋ ਦੂਜਾ ਗੇਟਵੇ ਤੈਨਾਤ ਕਰਦੇ ਹਨ ਉਹ ਮਦਦ ਨਹੀਂ ਕਰਦਾ। ਇਹ ਦੂਜੀ ਟਨਲ ਦਿੰਦਾ ਹੈ, ਦੂਜਾ ਪਤਾ ਨਹੀਂ, ਅਤੇ ਨਕਲੀ ਰੇਂਜ ਟਨਲ ਦੇ ਅੰਦਰ ਬਿਨਾਂ ਬਦਲਾਅ ਯਾਤਰਾ ਕਰਦੀ ਹੈ। ਇਹ ਉਸ ਕਨਫਿਗਰੇਸ਼ਨ ਨੂੰ ਵੀ ਦੁੱਗਣਾ ਕਰਦਾ ਹੈ ਜੋ ਤੁਹਾਨੂੰ ਇਕਸਾਰ ਰੱਖਣੀ ਪੈਂਦੀ ਹੈ। ਜੋ ਇਹ ਨਹੀਂ ਕਰ ਸਕਦਾ ਉਹ ਹੈ ਇੱਕ ਪਤੇ ਦਾ ਅਰਥ ਦੋ ਹੋਸਟ ਬਣਾਉਣਾ।
VPN ਪੀਅਰਾਂ ਦੇ ਜਨਤਕ ਪਤੇ ਬਦਲਣ ਨਾਲ ਵੀ ਕੁਝ ਨਹੀਂ ਹੁੰਦਾ। ਉਹ ਪਤੇ ਟਨਲ ਦੇ ਸਿਰੇ ਚਿੰਨ੍ਹਿਤ ਕਰਦੇ ਹਨ, ਜਦੋਂ ਕਿ ਟਕਰਾਅ ਅੰਦਰ ਲਿਜਾਈ ਜਾਣ ਵਾਲੀ ਨਿੱਜੀ ਰੇਂਜ ਵਿੱਚ ਹੈ।
NAT ਉਪਲਬਧ ਹੈ ਜਾਂ ਨਹੀਂ ਇਹ ਕਨੈਕਸ਼ਨ ਕਿਸਮ ਤੈਅ ਕਰਦੀ ਹੈ
Azure VPN Gateway ਵਿੱਚ ਸੱਚਮੁੱਚ NAT ਸਮਰੱਥਾ ਹੈ, ਅਤੇ ਇਹ ਖਾਸ ਗੇਟਵੇ SKU ਤੇ ਰੂਟ-ਆਧਾਰਿਤ IPsec ਅੰਤਰ-ਸਾਈਟ ਕਨੈਕਸ਼ਨਾਂ ਲਈ ਦਸਤਾਵੇਜ਼ਬੱਧ ਹੈ। ਉਹੀ ਦਸਤਾਵੇਜ਼ VNet-to-VNet ਅਤੇ point-to-site ਕਨੈਕਸ਼ਨਾਂ ਨੂੰ ਬਾਹਰ ਰੱਖਦਾ ਹੈ, ਇਸ ਲਈ ਇਹ ਸਹੂਲਤ ਹਰ ਗੇਟਵੇ ਸੰਬੰਧ ਤੇ ਦਿਖਣ ਵਾਲਾ ਚੈਕਬਾਕਸ ਨਹੀਂ ਹੈ।
| Connection type | NAT support | Overlap workaround |
|---|---|---|
| Site-to-Site (route-based IPsec, documented SKUs) | Supported with configured NAT rules | Translate the range in the rules |
VNet-to-VNet (Vnet2Vnet) | Not supported | Renumber, or redesign as a site-to-site connection |
| Point-to-site | Not supported | Choose client address pools that do not collide |
ਮੂਲ VNet-to-VNet ਲਈ ਵੀ ਸ਼ੁਰੂ ਤੋਂ ਹੀ VNet ਅਤੇ ਸਥਾਨਕ-ਨੈੱਟਵਰਕ ਰੇਂਜਾਂ ਦਾ ਓਵਰਲੈਪ ਨਾ ਹੋਣਾ ਜ਼ਰੂਰੀ ਹੈ, ਜੋ ਇਸ ਬਾਹਰਕਾਵ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ। ਇਸੇ ਕਾਰਨ VNet ਪੀਅਰਿੰਗ ਵੀ ਓਵਰਲੈਪ ਦਾ ਹੱਲ ਨਹੀਂ ਹੈ।
ਇੱਕ ਸਮਰਥਿਤ ਬਦਲ ਹੈ ਜਿਸਨੂੰ ਲੋਕ ਮੂਲ ਕਿਸਮ ਨਾਲ ਉਲਝਾ ਦਿੰਦੇ ਹਨ: ਦੂਜੇ VNet ਨੂੰ ਸਥਾਨਕ ਨੈੱਟਵਰਕ ਵਜੋਂ ਮਾਡਲ ਕਰੋ ਅਤੇ ਇਸਨੂੰ ਸਾਈਟ-ਤੋਂ-ਸਾਈਟ ਕਨੈਕਸ਼ਨ ਵਜੋਂ ਜੋੜੋ। ਇਹ ਵੱਖਰਾ ਸਰੋਤ ਅਤੇ ਵੱਖਰਾ ਡਿਜ਼ਾਈਨ ਹੈ, ਇਸ ਲਈ ਨਾਮ ਬਦਲੇ ਕਨੈਕਸ਼ਨ ਨੂੰ ਸਿਰਫ਼ ਨਾਮ ਬਦਲਣਾ ਨਹੀਂ, ਸਗੋਂ ਤਸਦੀਕ ਕਰਨ ਯੋਗ ਬਦਲਾਅ ਮੰਨੋ।
ਦੁਬਾਰਾ ਨੰਬਰ ਦਿਓ, ਜਾਂ ਉਸ ਚੀਜ਼ ਨਾਲ ਅਨੁਵਾਦ ਕਰੋ ਜੋ ਉਪਨਾਮ ਦੀ ਮਾਲਕ ਹੈ
ਜੇ ਦੋਵੇਂ VNet ਤੁਹਾਡੇ ਹਨ, ਤਾਂ ਯੋਜਨਾਬੱਧ ਦੁਬਾਰਾ-ਨੰਬਰਿੰਗ ਦੀ ਤੁਲਨਾ ਅਨੁਵਾਦ ਦੀ ਲਗਾਤਾਰ ਲਾਗਤ ਨਾਲ ਕਰੋ। ਦੁਬਾਰਾ-ਨੰਬਰਿੰਗ ਐਪਲੀਕੇਸ਼ਨ ਕਨਫਿਗਰੇਸ਼ਨ, DNS ਰਿਕਾਰਡ, ਸੁਰੱਖਿਆ ਨਿਯਮ ਅਤੇ ਹਰ ਮੌਜੂਦਾ ਕਨੈਕਸ਼ਨ ਨੂੰ ਛੂੰਹਦੀ ਹੈ, ਪਰ ਬਾਅਦ ਵਿੱਚ ਆਮ ਤਰੀਕੇ ਨਾਲ ਪੜ੍ਹੇ ਜਾਣ ਵਾਲਾ ਨੈੱਟਵਰਕ ਛੱਡਦੀ ਹੈ। ਇੱਕ ਵਾਰ ਵਿੱਚ ਇੱਕ ਸਬਨੈੱਟ ਕਰੋ, DNS ਬਦਲਾਅ ਸਭ ਤੋਂ ਅੰਤ ਵਿੱਚ। ਅੱਧ-ਦੁਬਾਰਾ-ਨੰਬਰ ਕੀਤੀ ਰੇਂਜ ਦੋਵਾਂ ਵਿਕਲਪਾਂ ਨਾਲੋਂ ਮਾੜੀ ਹੈ, ਕਿਉਂਕਿ ਫਿਰ ਦੋਵੇਂ ਪ੍ਰੀਫਿਕਸ ਅਗਲੀ ਵਾਰ ਟੇਬਲ ਪੜ੍ਹਨ ਵਾਲੇ ਨੂੰ ਅਧਿਕਾਰਕ ਲੱਗਦੇ ਹਨ।
ਜਿੱਥੇ ਦੁਬਾਰਾ-ਨੰਬਰਿੰਗ ਅਮਲੀ ਨਹੀਂ ਹੈ, ਉਥੇ ਉਪਨਾਮ ਦੇ ਅਸਲ ਮਾਲਕ ਵਾਲਾ ਅਨੁਵਾਦਿਤ ਡਿਜ਼ਾਈਨ ਵਰਤੋ। VNet A ਦੇ ਕਾਲਰ VNet B ਦੇ 10.40.1.10 ਤੱਕ 10.140.1.10 ਵਜੋਂ ਪਹੁੰਚ ਸਕਦੇ ਹਨ, ਪਰ ਉਸ ਉਪਨਾਮ ਲਈ ਅਨੁਵਾਦ ਕਰਨ ਵਾਲਾ ਯੰਤਰ, ਉਸ ਵੱਲ ਰੂਟ ਅਤੇ ਜਵਾਬ ਲਈ ਮੇਲ ਖਾਂਦਾ ਵਿਵਹਾਰ ਚਾਹੀਦਾ ਹੈ। ਸਿਰਫ਼ DNS ਵਿੱਚ ਜੋੜਿਆ ਪਤਾ ਅਨੁਵਾਦ ਨਹੀਂ ਹੈ।
ਦੋਵੇਂ ਰੇਂਜਾਂ ਨੂੰ ਦੋਵਾਂ ਦਿਸ਼ਾਵਾਂ ਵਿੱਚ ਦਰਜ ਕਰੋ: ਕਾਲਰ ਕੀ ਡਾਇਲ ਕਰਦਾ ਹੈ, ਮੰਜ਼ਿਲ ਸਰੋਤ ਵਜੋਂ ਕੀ ਵੇਖਦੀ ਹੈ, ਅਤੇ ਕਿਹੜਾ ਪਾਸਾ ਸ਼ੁਰੂ ਕਰ ਸਕਦਾ ਹੈ। Azure ਦੇ ਆਪਣੇ NAT ਨਿਯਮ ਆਪਣੇ SNAT ਮੈਪਿੰਗਾਂ ਲਈ ਉਲਟ ਅਨੁਵਾਦ ਸ਼ਾਮਲ ਕਰਦੇ ਹਨ, ਇਸ ਲਈ ਤੁਸੀਂ ਹੱਥੀਂ ਮੇਲ ਖਾਂਦਾ DNAT ਨਿਯਮ ਨਹੀਂ ਲਿਖਦੇ, ਪਰ ਉਹ ਸੁਵਿਧਾ ਉਹਨਾਂ ਕਨੈਕਸ਼ਨ ਕਿਸਮਾਂ ਤੇ ਖਤਮ ਹੁੰਦੀ ਹੈ ਜਿਨ੍ਹਾਂ ਨੂੰ ਇਹ ਸਹੂਲਤ ਸਮਰਥਨ ਦਿੰਦੀ ਹੈ।
ਕੀ ਕੰਮ ਨਹੀਂ ਕਰੇਗਾ
ਵਰਤੋਂਕਾਰ-ਨਿਰਧਾਰਿਤ ਰੂਟ ਜਾਂ ਰੂਟ ਮੈਟ੍ਰਿਕ ਗੁੰਮ ਪਤਾ-ਭੇਦ ਪੈਦਾ ਨਹੀਂ ਕਰ ਸਕਦੇ। ਦੋਵੇਂ ਅਜੇ ਵੀ ਅਸਪਸ਼ਟ ਮੰਜ਼ਿਲ ਤੇ ਕੰਮ ਕਰਦੇ ਹਨ, ਅਤੇ ਪੈਕੇਟ ਉਸੇ ਅਗਲੇ ਹੌਪ ਤੇ ਪਹੁੰਚਦਾ ਹੈ ਜਿਸਨੂੰ ਟੇਬਲ ਤਰਜੀਹ ਦਿੰਦੀ ਹੈ।
ਨਕਲੀ ਰੇਂਜ ਨੂੰ ਵਧੇਰੇ ਖਾਸ ਪ੍ਰੀਫਿਕਸ ਵਜੋਂ ਰੂਟ ਟੇਬਲ ਵਿੱਚ ਜੋੜਨ ਨਾਲ ਅਸਪਸ਼ਟਤਾ ਸਿਰਫ਼ ਇੱਕ ਕਦਮ ਹਿੱਲਦੀ ਹੈ। ਇਹ ਦੂਜੀ ਦਿਸ਼ਾ ਨੂੰ ਤੋੜਨ ਦੀ ਪ੍ਰਵਿਰਤੀ ਵੀ ਰੱਖਦਾ ਹੈ, ਜਿੱਥੇ ਜਵਾਬ ਦੇ ਹੁਣ ਦੋ ਸੰਭਾਵੀ ਸਰੋਤ ਹਨ।
ਦੋਵਾਂ ਦਿਸ਼ਾਵਾਂ ਵਿੱਚ ਟ੍ਰੈਫਿਕ ਨਾਲ ਡਿਜ਼ਾਈਨ ਸਵੀਕਾਰ ਕਰੋ
ਟਨਲ ਸਥਿਤੀ ਨਾਲ ਨਹੀਂ, ਹਰ ਪਾਸੇ ਤੋਂ ਨਵੀਂ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਕਾਰਵਾਈ ਨਾਲ ਡਿਜ਼ਾਈਨ ਸਾਬਤ ਕਰੋ। ਜੁੜੀ IPsec ਟਨਲ ਕਹਿੰਦੀ ਹੈ ਕਿ ਪੀਅਰ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫੀ ਤੇ ਸਹਿਮਤ ਹਨ; ਇਹ ਨਹੀਂ ਦੱਸਦੀ ਕਿ ਮੰਜ਼ਿਲਾਂ ਵੱਖਰੀਆਂ ਹੋਈਆਂ ਜਾਂ ਨਹੀਂ।
ਫਿਰ ਰੱਦ ਕੀਤੇ ਰਾਹ ਚਲਾਓ: ਇੱਕ ਪਤਾ ਜੋ ਅਪਹੁੰਚ ਰਹਿਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਇੱਕ ਸੇਵਾ ਜਿਸਨੂੰ ਨੀਤੀ ਨੇ ਰੋਕਣਾ ਚਾਹੀਦਾ ਹੈ। ਜੇ ਦੋਵੇਂ ਅਜੇ ਵੀ ਸਫਲ ਹੁੰਦੇ ਹਨ, ਤਾਂ ਅਨੁਵਾਦ ਡਿਜ਼ਾਈਨ ਦੇ ਇਰਾਦੇ ਨਾਲੋਂ ਵਿਆਪਕ ਹੈ।
ਉਹਨਾਂ ਤੱਥਾਂ ਨਾਲ ਸਮਾਪਤ ਕਰੋ ਜੋ ਬਾਅਦ ਵਿੱਚ ਇਹ ਸੈੱਟਅੱਪ ਸਮਝਾਉਣਗੇ: ਮੂਲ ਰੇਂਜ, ਪੇਸ਼ ਕੀਤੀ ਰੇਂਜ, ਅਨੁਵਾਦ ਕਰਨ ਵਾਲਾ ਯੰਤਰ, ਅਤੇ ਹਰ ਪਾਸਾ ਜਿਸ ਦਿਸ਼ਾ ਵਿੱਚ ਸ਼ੁਰੂ ਕਰ ਸਕਦਾ ਹੈ। ਜੇ ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਗੁੰਮ ਹੈ, ਤਾਂ ਅਗਲੇ ਇੰਜੀਨੀਅਰ ਨੂੰ ਅਜਿਹਾ ਨੈੱਟਵਰਕ ਵਿਰਾਸਤ ਵਿੱਚ ਮਿਲਦਾ ਹੈ ਜਿੱਥੇ ਦੋ ਹੋਸਟ ਇੱਕ ਨਾਮ ਸਾਂਝਾ ਕਰਦੇ ਹਨ ਅਤੇ ਕਿਸੇ ਨੂੰ ਯਾਦ ਨਹੀਂ ਕਿ ਇਹਨਾਂ ਵਿੱਚੋਂ ਇੱਕ ਜਵਾਬ ਕਿਉਂ ਦਿੰਦਾ ਹੈ।