NVA ਤੋਂ ਬਿਨਾਂ ExpressRoute 'ਤੇ Azure ਪ੍ਰਾਈਵੇਟ IP VPN
Azure VPN Gateway ExpressRoute 'ਤੇ ਇੱਕ ਪ੍ਰਾਈਵੇਟ ਪਤੇ 'ਤੇ IPsec ਖਤਮ ਕਰ ਸਕਦਾ ਹੈ। ਦੋਵੇਂ ਫਲੈਗ ਸਮਰੱਥ ਕਰੋ, ਫਿਰ ਸਿੱਧੇ peering ਰਸਤਿਆਂ ਨੂੰ ਟਨਲ ਬਾਈਪਾਸ ਕਰਨ ਤੋਂ ਰੋਕੋ।
ਮਿੱਥ ਇਹ ਹੈ ਕਿ ExpressRoute ਪ੍ਰਾਈਵੇਟ peering ਉੱਤੇ ਟ੍ਰੈਫਿਕ ਨੂੰ ਐਨਕ੍ਰਿਪਟ ਕਰਨ ਲਈ ਨੈੱਟਵਰਕ ਵਰਚੁਅਲ ਉਪਕਰਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਇਹ ਨਹੀਂ ਹੈ। Azure Site-to-Site VPN Gateway ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ ਜਿਸਦਾ ਟਨਲ ਅੰਤ ਬਿੰਦੂ ਸਰਕਟ ਰਾਹੀਂ ਲਿਜਾਇਆ ਜਾਂਦਾ ਪ੍ਰਾਈਵੇਟ RFC1918 ਪਤਾ ਹੈ, ਅਤੇ ਉਪਕਰਣ ਢਾਂਚਾਗਤ ਨਹੀਂ ਸਗੋਂ ਵਿਕਲਪਿਕ ਹੈ। ਜੋ ਉਪਕਰਣ ਦੀ ਮਿੱਥ ਲੁਕਾਉਂਦੀ ਹੈ ਉਹ ਭਾਗ ਅਸਲ ਵਿੱਚ ਦੁਖਾਉਂਦਾ ਹੈ: ਪ੍ਰਾਈਵੇਟ ਅੰਤ ਬਿੰਦੂ ਨੂੰ ਦੋ ਵਸਤੂਆਂ ਦੀ ਬਜਾਏ ਇੱਕ 'ਤੇ ਸਮਰੱਥ ਕਰਨਾ, ਅਤੇ ਸਿੱਧੇ peering ਰਸਤੇ ਨੂੰ ਐਨਕ੍ਰਿਪਟਿਡ ਮਾਰਗ 'ਤੇ ਚੁੱਪਚਾਪ ਜਿੱਤਣ ਦੇਣਾ।
ਮਿੱਥ ਕਿੱਥੋਂ ਆਈ
ਇਸ ਦਾਅਵੇ ਦੀ ਇੱਕ ਸਤਿਕਾਰਯੋਗ ਪਿਛੋਕੜ ਹੈ। ਸਾਲਾਂ ਤੱਕ ਪ੍ਰਾਈਵੇਟ peering ਉੱਤੇ IPsec ਲਈ ਵਿਹਾਰਕ ਵਿਧੀ NVA ਸੀ, ਕਿਉਂਕਿ ਪ੍ਰਬੰਧਿਤ ਗੇਟਵੇ ਸਿਰਫ਼ ਜਨਤਕ ਅੰਤ ਬਿੰਦੂ ਦਿਖਾਉਂਦਾ ਸੀ। ਇਹ ਬਦਲ ਗਿਆ, ਅਤੇ ਬਦਲਾਅ ਤੋਂ ਪਹਿਲਾਂ ਲਿਖੇ ਜਵਾਬ ਅਜੇ ਵੀ ਅਜਿਹੇ ਥ੍ਰੈਡਾਂ ਵਿੱਚ ਹਵਾਲਾ ਦਿੱਤੇ ਜਾਂਦੇ ਹਨ ਜਿੱਥੇ ਕੋਈ ਤਾਰੀਖ ਨਹੀਂ ਜਾਂਚਦਾ। ਸੁਧਾਰ ਸੰਕੁਚਿਤ ਹੈ: ਪ੍ਰਾਈਵੇਟ ਪਤੇ ਵਾਲਾ VPN ਗੇਟਵੇ ਮੌਜੂਦ ਹੈ, ਅਤੇ ਇਹ ਅੰਤ ਬਿੰਦੂ ਬਦਲਦਾ ਹੈ, ਇਸਦੇ ਆਲੇ-ਦੁਆਲੇ ਦਾ ਰਾਊਟਿੰਗ ਤਰਕ ਨਹੀਂ।
ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ NVA ਨੂੰ ਸੇਵਾਮੁਕਤ ਨਹੀਂ ਕਰਦਾ। ਇਹ ਇਸ ਧਾਰਨਾ ਨੂੰ ਸੇਵਾਮੁਕਤ ਕਰਦਾ ਹੈ ਕਿ ਉਪਕਰਣ ਹੀ ਲੋੜ ਦਾ ਇੱਕੋ ਇੱਕ ਰਸਤਾ ਹੈ।
ਦੋਵਾਂ ਪੱਧਰਾਂ 'ਤੇ ਪ੍ਰਾਈਵੇਟ ਅੰਤ ਬਿੰਦੂ ਸਮਰੱਥ ਕਰੋ
VPN ਗੇਟਵੇ ਵਾਲੇ VNet ਨਾਲ ਜੁੜੇ ਕੰਮ ਕਰਦੇ ExpressRoute ਪ੍ਰਾਈਵੇਟ peering ਕਨੈਕਸ਼ਨ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ। ਆਨ-ਪ੍ਰੈਮਾਈਜ਼ ਪਾਸੇ ਨੂੰ ਪਹਿਲਾਂ ਹੀ ਉਸ ਸਰਕਟ ਰਾਹੀਂ ਸੰਬੰਧਿਤ ਪ੍ਰਾਈਵੇਟ ਪਤਿਆਂ ਤੱਕ ਪਹੁੰਚਿਆ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਕਿਉਂਕਿ ਟਨਲ ਉਹਨਾਂ ਪਤਿਆਂ ਨੂੰ ਆਵਾਜਾਈ ਵਜੋਂ ਵਰਤੇਗਾ। ਫਿਰ ਗੇਟਵੇ ਦੀ ਪੂਰਵ ਸ਼ਰਤ: ਪ੍ਰਾਈਵੇਟ-IP VPN ਲਈ Microsoft ਦੀ ਪ੍ਰਕਿਰਿਆ ਨੂੰ Standard ਜਨਤਕ IP ਸਰੋਤ 'ਤੇ ਬਣਿਆ ਗੇਟਵੇ ਲੋੜੀਂਦਾ ਹੈ। ਪ੍ਰਾਈਵੇਟ ਟਨਲ ਐਡਰੈਸਿੰਗ ਉਹ ਸ਼ਰਤ ਹਟਾਉਂਦੀ ਨਹੀਂ, ਜੋ „ਪ੍ਰਾਈਵੇਟ“ ਦਾ ਅਰਥ „ਕਿਤੇ ਵੀ ਜਨਤਕ IP ਨਹੀਂ“ ਸਮਝਣ ਵਾਲਿਆਂ ਨੂੰ ਹੈਰਾਨ ਕਰਦੀ ਹੈ।
ਹੁਣ ਦੋਵੇਂ ਥਾਵਾਂ 'ਤੇ ਫਲੈਗ ਸਮਰੱਥ ਕਰੋ। ਗੇਟਵੇ ਕਨਫਿਗਰੇਸ਼ਨ ਦਾ ਪ੍ਰਾਈਵੇਟ IP ਲਈ ਆਪਣਾ ਸਵਿੱਚ ਹੈ, ਅਤੇ ਵੱਖਰੇ Site-to-Site ਕਨੈਕਸ਼ਨ ਦਾ ਦੂਜਾ ਹੈ ਜੋ ਉਸ ਕਨੈਕਸ਼ਨ ਨੂੰ ਪ੍ਰਾਈਵੇਟ ਪਤਾ ਵਰਤਣ ਲਈ ਮਜਬੂਰ ਕਰਦਾ ਹੈ। ਇੱਕ ਸੈੱਟ ਕਰਨਾ ਅਤੇ ਦੂਜਾ ਨਾ ਕਰਨਾ ਸਭ ਤੋਂ ਆਮ ਅਧੂਰਾ ਕਨਫਿਗਰੇਸ਼ਨ ਹੈ; ਟਨਲ ਜਾਂ ਤਾਂ ਸਥਾਪਿਤ ਨਹੀਂ ਹੁੰਦਾ ਜਾਂ ਗਲਤ ਅੰਤ ਬਿੰਦੂ 'ਤੇ ਸਥਾਪਿਤ ਹੁੰਦਾ ਹੈ।
az network vnet-gateway update -g rg-net -n vpngw-prod --set enablePrivateIpAddress=true
az network vpn-connection update -g rg-net -n conn-onprem --set enablePrivateIpAddress=true
az network vnet-gateway show -g rg-net -n vpngw-prod \
--query '{sku:sku,priv:enablePrivateIpAddress,active:activeActive}'
ਤੁਹਾਡੇ ਇੰਸਟਾਲ ਕੀਤੇ CLI ਸੰਸਕਰਣ ਦੇ ਸਾਮ੍ਹਣੇ ਵਿਸ਼ੇਸ਼ਤਾ ਨਾਮ ਜਾਂਚੋ, ਕਿਉਂਕਿ ਪੋਰਟਲ ਲੇਬਲ ਅਤੇ CLI ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਇੱਕੋ ਸ਼ਬਦਾਵਲੀ ਨਹੀਂ ਵਰਤਦੀਆਂ। ਸਰਗਰਮ-ਸਰਗਰਮ ਗੇਟਵੇ ਦੋ ਪ੍ਰਾਈਵੇਟ ਟਨਲ ਪਤੇ ਦਿਖਾਉਂਦਾ ਹੈ, ਅਤੇ ਉਹ ਰੀਡੰਡੈਂਸੀ ਅਰਥਪੂਰਨ ਹੋਣ ਲਈ ਆਨ-ਪ੍ਰੈਮਾਈਜ਼ ਡਿਵਾਈਸ ਵਿੱਚ ਦੋਵੇਂ ਪੀਅਰ ਕਨਫਿਗਰ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ। ਸਿਰਫ਼ ਇਸ ਪ੍ਰਾਈਵੇਟ ਪਤੇ ਵਾਲੇ ਟਨਲ ਨੂੰ ਚੁੱਕਣ ਲਈ BGP ਲੋੜੀਂਦਾ ਨਹੀਂ, ਹਾਲਾਂਕਿ ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਪ੍ਰੀਫਿਕਸ ਵੰਡਣ ਦੇ ਤਰੀਕੇ ਦਾ ਹਿੱਸਾ ਹੁੰਦਾ ਹੈ।
ਦੂਜੀ ਮਿੱਥ: ਸਥਾਪਿਤ ਟਨਲ ਤੁਹਾਡਾ ਟ੍ਰੈਫਿਕ ਐਨਕ੍ਰਿਪਟ ਕਰਦਾ ਹੈ
ਹੁਣ ਐਪਲੀਕੇਸ਼ਨ ਨੈੱਟਵਰਕ ਤੱਕ ਦੋ ਰਸਤੇ ਪਹੁੰਚਦੇ ਹਨ: ਸਿੱਧਾ ਪ੍ਰਾਈਵੇਟ peering ਰਸਤਾ ਅਤੇ VPN ਰਾਹੀਂ ਰਸਤਾ। ਦੋਵੇਂ ਕੰਮ ਕਰਦੇ ਹਨ। ਸਿਰਫ਼ ਇੱਕ ਹੀ ਇਹ IPsec ਪਰਤ ਲਾਗੂ ਕਰਦਾ ਹੈ। Microsoft ਦਸਤਾਵੇਜ਼ ਕਰਦਾ ਹੈ ਕਿ ਜਦੋਂ ਇੱਕੋ ਪ੍ਰੀਫਿਕਸ ExpressRoute ਅਤੇ VPN ਦੋਵਾਂ 'ਤੇ ਘੋਸ਼ਿਤ ਹੁੰਦੇ ਹਨ, ਤਾਂ Azure ਸਿੱਧੇ ExpressRoute ਰਸਤੇ ਨੂੰ ਤਰਜੀਹ ਦਿੰਦਾ ਹੈ, ਇਸ ਲਈ ਸਿਹਤਮੰਦ ਟਨਲ ਅਤੇ ਸਿਹਤਮੰਦ ਕਾਊਂਟਰ ਇਸ ਬਾਰੇ ਕੁਝ ਸਾਬਤ ਨਹੀਂ ਕਰਦੇ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਪੈਕਟ ਕਿੱਥੇ ਗਏ।
ਦਸਤਾਵੇਜ਼ੀ ਸਟੀਅਰਿੰਗ ਢੰਗ ExpressRoute 'ਤੇ ਢਕਣ ਵਾਲੀ ਰੇਂਜ ਅਤੇ VPN 'ਤੇ ਹੋਰ ਖਾਸ ਸੁਰੱਖਿਅਤ ਰੇਂਜ, ਜਾਂ ਦੋਵੇਂ ਰਸਤਿਆਂ 'ਤੇ ਅਲੱਗ ਪ੍ਰੀਫਿਕਸ ਹਨ। ਉਦਾਹਰਣ ਲਈ, ਪ੍ਰਾਈਵੇਟ peering 10.40.0.0/16 ਲੈ ਜਾ ਸਕਦਾ ਹੈ ਅਤੇ VPN 10.40.12.0/24 ਘੋਸ਼ਿਤ ਕਰਦਾ ਹੈ। ਵਧੇਰੇ ਖਾਸ ਪ੍ਰੀਫਿਕਸ ਜਿੱਤਦਾ ਹੈ ਅਤੇ ਰੇਂਜ ਦਾ ਬਾਕੀ ਹਿੱਸਾ ਸਿੱਧਾ ਰਹਿੰਦਾ ਹੈ।
az network vnet-gateway list-advertised-routes -g rg-net -n vpngw-prod
az network vnet-gateway list-learned-routes -g rg-net -n vpngw-prod
az network vpn-connection show -g rg-net -n conn-onprem --query connectionStatus
ਆਨ-ਪ੍ਰੈਮਾਈਜ਼ ਦਿਸ਼ਾ ਵਿੱਚ ਵੀ ਉਹੀ ਜਾਂਚ ਕਰੋ, ਕਿਉਂਕਿ ਤੁਹਾਡੇ ਰਾਊਟਰ ਦੀ ਤਰਜੀਹ ਤੈਅ ਕਰਦੀ ਹੈ ਕਿ ਬਾਹਰ ਜਾਣ ਵਾਲਾ ਟ੍ਰੈਫਿਕ ਕਿਸ ਪਾਸੇ ਨਿਕਲਦਾ ਹੈ। ਅਤੇ ਟਨਲ ਦੀ ਆਪਣੀ ਆਵਾਜਾਈ ExpressRoute ਰਸਤੇ 'ਤੇ ਰੱਖੋ; ਜੋ ਰਸਤਾ ਗੇਟਵੇ ਦੇ ਪ੍ਰਾਈਵੇਟ ਅੰਤ ਬਿੰਦੂ ਨੂੰ ਟਨਲ ਵਿੱਚ ਖਿੱਚਦਾ ਹੈ ਉਹ ਟਨਲ ਨੂੰ ਆਪਣੇ ਆਪ 'ਤੇ ਨਿਰਭਰ ਬਣਾਉਂਦਾ ਹੈ।
ਤੈਅ ਕਰੋ ਕਿ ਟਨਲ ਡਿੱਗਣ 'ਤੇ ਕੀ ਹੁੰਦਾ ਹੈ
ਟਨਲ ਡਿੱਗਣ 'ਤੇ ਵਧੇਰੇ ਖਾਸ VPN ਰਸਤਾ ਗਾਇਬ ਹੋ ਜਾਂਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਚੌੜਾ ਸਿੱਧਾ ਰਸਤਾ ਰਹਿੰਦਾ ਹੈ। ਫਿਰ ਟ੍ਰੈਫਿਕ ਬਿਨਾਂ ਐਨਕ੍ਰਿਪਸ਼ਨ ਦੇ ਵਗਦਾ ਹੈ ਅਤੇ ਸਭ ਕੁਝ ਸਿਹਤਮੰਦ ਦਿਖਦਾ ਹੈ, ਜੋ ਐਨਕ੍ਰਿਪਸ਼ਨ ਦੀ ਗਰੰਟੀ ਲਈ ਮੌਜੂਦ ਲੋੜ ਲਈ ਸਭ ਤੋਂ ਮਾੜਾ ਅਸਫਲਤਾ ਢੰਗ ਹੈ। ਜੇ ਲੋੜ ਉਸ ਫਾਲਬੈਕ ਨੂੰ ਮਨਾਹੀ ਕਰਦੀ ਹੈ, ਤਾਂ ਰਾਊਟਿੰਗ ਅਤੇ ਪਹੁੰਚ ਨੀਤੀ ਨੂੰ ਟਨਲ ਦੀ ਉਪਲਬਧਤਾ 'ਤੇ ਨਿਰਭਰ ਕਰਨ ਦੀ ਬਜਾਏ ਇਹ ਸਪੱਸ਼ਟ ਕਹਿਣਾ ਚਾਹੀਦਾ ਹੈ।
ਲਿਖੋ ਕਿ ਕਿਹੜੇ ਪ੍ਰੀਫਿਕਸ ਸਿੱਧੇ ਪਹੁੰਚਯੋਗ ਰਹਿ ਸਕਦੇ ਹਨ ਅਤੇ ਕਿਹੜੇ ਐਨਕ੍ਰਿਪਟਿਡ ਰਸਤਾ ਨਾ ਹੋਣ 'ਤੇ ਰੁਕਣੇ ਚਾਹੀਦੇ ਹਨ। ਫਿਰ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਕੇਸ ਨੂੰ ਅਸਲੀ ਟ੍ਰੈਫਿਕ ਨਾਲ ਪਰਖੋ ਅਤੇ ਕਨੈਕਸ਼ਨ ਕਾਊਂਟਰਾਂ ਦੀ ਤੁਲਨਾ ਕਰੋ, ਕਿਉਂਕਿ ਸਿਰਫ਼ ਰੂਟ ਟੇਬਲ ਤੁਹਾਨੂੰ ਇਹ ਨਹੀਂ ਦੱਸੇਗਾ ਕਿ ਐਨਕ੍ਰਿਪਸ਼ਨ ਲੋੜ ਅਜੇ ਵੀ ਲਾਗੂ ਹੈ ਜਾਂ ਨਹੀਂ।
ਇਹ ਢਾਂਚਾ ਤੁਹਾਨੂੰ NVA ਦਾ ਮੁਲਾਂਕਣ ਇਸਦੀਆਂ ਅਸਲੀ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੇ ਆਧਾਰ 'ਤੇ ਕਰਨ ਦੀ ਵੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ, ਜਿਵੇਂ ਕਿ ਕਈ ਟਨਲ, ਥ੍ਰੂਪੁੱਟ ਜਾਂ ਵਿਕਰੇਤਾ ਜਾਂਚ, ਸਿਰਫ਼ ਇਸ ਲਈ ਇੱਕ ਖਰੀਦਣ ਦੀ ਬਜਾਏ ਕਿ ਅੰਤ ਬਿੰਦੂ ਪ੍ਰਾਈਵੇਟ ਹੈ।