ExpressRoute ਨਾਲ VPN: ਤੁਸੀਂ ਕਿਹੜੇ ਅਸਫਲਤਾ-ਡੋਮੇਨ ਕਵਰ ਕਰਦੇ ਹੋ?
ਦੂਜੀ IPsec ਸੁਰੰਗ ਇੱਕ ਸਿਰੇ ਨੂੰ ਕਵਰ ਕਰਦੀ ਹੈ, ਉਸ ਹੇਠਲੇ ਸਰਕਟ ਨੂੰ ਨਹੀਂ। ਹਰ ਅਸਫਲਤਾ-ਡੋਮੇਨ ਦਾ ਨਕਸ਼ਾ ਬਣਾਓ, ਫਿਰ ਫੈਸਲਾ ਕਰੋ ਕਿ ਬਿਨਾਂ ਐਨਕ੍ਰਿਪਸ਼ਨ ਵਾਲਾ ਬਦਲਵਾਂ ਰਾਹ ਮਨਜ਼ੂਰ ਹੈ ਜਾਂ ਨਹੀਂ।
ExpressRoute ਦੀ ਨਿੱਜੀ ਪੀਅਰਿੰਗ ਉੱਤੇ ਚੱਲਣ ਵਾਲੀ IPsec ਸੁਰੰਗ ਪਹਿਲਾਂ ਤੋਂ ਮੌਜੂਦ ਟਰਾਂਸਪੋਰਟ ਵਿੱਚ ਐਨਕ੍ਰਿਪਸ਼ਨ ਜੋੜਦੀ ਹੈ। ਦੂਜੀ ਸੁਰੰਗ ਸਿਰੇ ਦੀ ਉਪਲਬਧਤਾ ਸੁਧਾਰਦੀ ਹੈ, ਅਤੇ ਦੋਵਾਂ ਦੇ ਹੇਠਲੇ ਕੈਰੀਅਰ ਰਾਹ ਲਈ ਇਹ ਕੁਝ ਵੀ ਨਹੀਂ ਕਰਦੀ। ਇਹ ਫ਼ਰਕ ਗੁਆਉਣਾ ਸੌਖਾ ਹੈ ਜਦੋਂ ਡੈਸ਼ਬੋਰਡ ਦੋ ਹਰੀਆਂ ਸੁਰੰਗਾਂ ਦਿਖਾਉਂਦੇ ਹਨ ਅਤੇ ਡਿਜ਼ਾਈਨ ਸਮੀਖਿਆ ਕੋਈ ਹੋਰ ਸਵਾਲ ਪੁੱਛਦੀ ਹੈ: ਇਸ ਕਨੈਕਸ਼ਨ ਨੂੰ ਕਿਹੜੀਆਂ ਅਸਫਲਤਾਵਾਂ ਸਹਿਣੀਆਂ ਪੈਣਗੀਆਂ? ਪਹਿਲਾਂ ਇਸ ਦਾ ਜਵਾਬ ਦਿਓ, ਫਿਰ ਸੁਰੰਗਾਂ ਗਿਣੋ, ਕਿਉਂਕਿ ਹਰੇ ਸੰਕੇਤਕਾਂ ਦੀ ਗਿਣਤੀ ਐਨਕ੍ਰਿਪਸ਼ਨ ਪਰਤ ਦੀ ਵਿਸ਼ੇਸ਼ਤਾ ਹੈ ਅਤੇ ਅਸਫਲਤਾ-ਡੋਮੇਨਾਂ ਦੀ ਗਿਣਤੀ ਪੂਰੇ ਰਾਹ ਦੀ ਵਿਸ਼ੇਸ਼ਤਾ ਹੈ।
ਹਰੀਆਂ ਸੁਰੰਗਾਂ ਨਾਲ ਨਹੀਂ, ਅਸਫਲਤਾਵਾਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ
ਕੁਝ ਵੀ ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਚਾਰ ਲਾਈਨਾਂ ਲਿਖੋ: ਇੱਕ VPN ਸਿਰਾ ਜਾਂ ਪੀਅਰ ਇੰਸਟੈਂਸ ਅਸਫਲ ਹੋਣਾ, ਇੱਕ ਸਥਾਨਕ ਰਾਊਟਰ ਜਾਂ ਪਹਿਲੀ ਮੀਲ ਦਾ ਕਨੈਕਸ਼ਨ ਅਸਫਲ ਹੋਣਾ, ਸਾਂਝਾ ExpressRoute ਰਾਹ ਅਸਫਲ ਹੋਣਾ, ਅਤੇ ਨਿੱਜੀ ਪੀਅਰਿੰਗ ਦੇ ਅਜੇ ਵੀ ਟਰੈਫਿਕ ਢੋਂਦੇ ਹੋਏ IPsec ਦਾ ਉਪਲਬਧ ਨਾ ਰਹਿਣਾ। ਹਰ ਲਾਈਨ ਦੱਸਦੀ ਹੈ ਕਿ ਡਿਜ਼ਾਈਨ ਨੂੰ ਕੀ ਬਚਾਉਣਾ ਹੈ, ਅਤੇ ਹਰ ਇੱਕ ਦਾ ਜਵਾਬ ਵੱਖਰਾ ਵਿਧੀ ਦਿੰਦੀ ਹੈ।
| Failure | What must survive | What does not cover it |
|---|---|---|
| One VPN endpoint or instance | An alternate encryption endpoint and a route to it | A second tunnel terminating on the same instance |
| One local router or first mile | Independent local equipment and transport reachability | Any number of logical tunnels |
| The ExpressRoute path | A separately designed surviving underlay | An IPsec tunnel layered on the same circuit |
| IPsec unavailable, peering up | The intended encrypted-only or approved fallback policy | Assuming the tunnel is the only route |
Microsoft, ExpressRoute ਦੀ ਨਿੱਜੀ ਪੀਅਰਿੰਗ ਉੱਤੇ ਨਿੱਜੀ IP ਵਾਲੀ ਸਾਈਟ-ਤੋਂ-ਸਾਈਟ VPN ਅਤੇ ਇੰਟਰਨੈੱਟ-ਅਧਾਰਿਤ ਸਾਈਟ-ਤੋਂ-ਸਾਈਟ ਕਨੈਕਸ਼ਨਾਂ ਨਾਲ ਸਮਰਥਿਤ ਸਹਿ-ਮੌਜੂਦਗੀ ਦਾ ਦਸਤਾਵੇਜ਼ ਬਣਾਉਂਦਾ ਹੈ। ਉਹ ਸਹਿ-ਮੌਜੂਦਗੀ ਵੱਖਰਾ ਹੇਠਲੀ ਪਰਤ ਦਾ ਡਿਜ਼ਾਈਨ ਹੈ, ਅਤੇ ਇਹ ਸਿਰਫ਼ ਇਸ ਲਈ ਪ੍ਰਗਟ ਨਹੀਂ ਹੁੰਦੀ ਕਿ ਤੁਸੀਂ ਇੱਕ ਹੋਰ ਨਿੱਜੀ ਸੁਰੰਗ ਦਾ ਸਿਰਾ ਜੋੜਿਆ ਹੈ।
ਅਸਫਲਤਾ-ਡੋਮੇਨ 1: VPN ਸਿਰਾ
ਇੱਕ ਗੇਟਵੇ ਉੱਤੇ ਦੋ ਸੁਰੰਗਾਂ ਆਮ ਤੌਰ 'ਤੇ active-active ਜੋੜੇ ਹੁੰਦੀਆਂ ਹਨ ਜੋ ਉਸੇ Azure ਪਾਸੇ ਦੇ ਸਰੋਤ ਉੱਤੇ ਖਤਮ ਹੁੰਦੀਆਂ ਹਨ। ਉਹ ਇੱਕ ਸੁਰੰਗ ਜਾਂ ਇੰਸਟੈਂਸ ਦੀ ਸਮੱਸਿਆ ਤੋਂ ਬਚਾਉਂਦੀਆਂ ਹਨ, ਅਤੇ ਉਸ ਸਰੋਤ ਦੇ ਉਪਲਬਧ ਨਾ ਰਹਿਣ, ਮੁੜ-ਸੰਰਚਿਤ ਹੋਣ ਜਾਂ ਸਮਰੱਥਾ ਖ਼ਤਮ ਹੋਣ ਤੋਂ ਨਹੀਂ ਬਚਾਉਂਦੀਆਂ। ਸਿਰੇ ਦੀ ਰਿਡੰਡੈਂਸੀ ਦਾ ਮਤਲਬ ਹੈ ਆਪਣੇ ਰਾਹ ਅਤੇ ਆਪਣੀ ਸੰਰਚਨਾ ਵਾਲਾ ਦੂਜਾ ਸਮਰਥਿਤ ਸਿਰਾ, ਨਾਲ ਹੀ ਇੱਕ ਰੂਟ ਜੋ ਉੱਥੇ ਪਹੁੰਚ ਸਕੇ।
ਡਾਇਗ੍ਰਾਮ ਕੀ ਕਹਿੰਦਾ ਹੈ ਦੀ ਥਾਂ ਜੋ ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਤੈਨਾਤ ਕੀਤਾ ਹੈ ਦੀ ਜਾਂਚ ਕਰੋ, ਕਿਉਂਕਿ ਪੋਰਟਲ ਇਹਨਾਂ ਸਰੋਤਾਂ ਨੂੰ ਉਹਨਾਂ ਦੇ ਸਬੰਧ ਲੁਕਾਉਣ ਵਾਲੇ ਢੰਗ ਨਾਲ ਸਮੂਹਿਤ ਕਰਦਾ ਹੈ:
az network vpn-connection show -g rg-connectivity -n vpn-to-hub --query '{conn:connectionStatus,tunnels:tunnelConnectionStatus}'
az network vnet-gateway show -g rg-connectivity -n gw-hub --query '{sku:sku.name,activeActive:enableBgp,peers:bgpSettings.peers}'ਜੇ ਦੋਵੇਂ ਸੁਰੰਗਾਂ ਇੱਕ ਪਬਲਿਕ IP ਵਾਲੇ ਇੱਕ ਗੇਟਵੇ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੀਆਂ ਹਨ, ਤਾਂ ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਖਾਸ ਅਤੇ ਸੀਮਤ ਕਿਸਮ ਦੀ ਸਿਰਾ-ਰਿਡੰਡੈਂਸੀ ਹੈ। ਇਹ ਠੀਕ ਉਹੀ ਹੋ ਸਕਦੀ ਹੈ ਜੋ ਲੋੜ ਮੰਗਦੀ ਹੈ, ਅਤੇ ਇਸਨੂੰ ਰਿਡੰਡੈਂਟ ਕਨੈਕਸ਼ਨ ਵਜੋਂ ਬਿਆਨ ਕਰਨ ਦੀ ਥਾਂ ਇੰਝ ਹੀ ਕਿਹਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।
ਅਸਫਲਤਾ-ਡੋਮੇਨ 2: ਸਥਾਨਕ ਰਾਹ ਅਤੇ ਕੈਰੀਅਰ
ਐਨਕ੍ਰਿਪਸ਼ਨ ਹੇਠ ਭੌਤਿਕ ਅਤੇ ਵਪਾਰਕ ਹਕੀਕਤ ਹੈ: ਗਾਹਕ-ਕਿਨਾਰੇ ਦਾ ਯੰਤਰ, ਇੱਕ ਕ੍ਰਾਸ-ਕਨੈਕਟ, ਇੱਕ ਪ੍ਰਦਾਤਾ ਨੈੱਟਵਰਕ ਅਤੇ ਇੱਕ ਪੀਅਰਿੰਗ ਸਥਾਨ। ExpressRoute ਉਪਲਬਧਤਾ ਦਿਸ਼ਾ-ਨਿਰਦੇਸ਼ ਸਪਸ਼ਟ ਕਹਿੰਦੇ ਹਨ ਕਿ ਸਿਰੇ-ਤੋਂ-ਸਿਰੇ ਦੀ ਰਿਡੰਡੈਂਸੀ ਵਿੱਚ ਗਾਹਕ ਅਤੇ ਸੇਵਾ-ਪ੍ਰਦਾਤਾ ਹਿੱਸੇ ਸ਼ਾਮਲ ਹਨ, ਸਿਰਫ਼ Microsoft ਪਾਸਾ ਨਹੀਂ। ਇੱਕ ਰਾਊਟਰ, ਇੱਕ ਬਿਜਲੀ ਸਪਲਾਈ ਜਾਂ ਪਹਿਲੀ ਮੀਲ ਦਾ ਕਨੈਕਸ਼ਨ ਸਾਂਝਾ ਕਰਨ ਵਾਲੇ ਦੋ ਤਾਰਕਿਕ ਰਾਹ ਅਜੇ ਵੀ ਉਹ ਨਿਰਭਰਤਾ ਸਾਂਝੀ ਕਰਦੇ ਹਨ।
ਇੱਥੇ ਹੀ ਡਿਜ਼ਾਈਨ ਆਮ ਤੌਰ 'ਤੇ ਇਮਾਨਦਾਰ ਸਮੀਖਿਆ ਵਿੱਚ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ। ਇੱਕੋ ਪ੍ਰਦਾਤਾ ਦੇ ਦੋ ਸਰਕਟ, ਇੱਕੋ ਇਮਾਰਤ ਵਿੱਚ ਖਤਮ ਹੁੰਦੇ, ਇੱਕੋ ਖਰੀਦ ਆਰਡਰ ਦੇ ਉਪਕਰਣਾਂ ਉੱਤੇ, ਦੋ ਅਸਫਲਤਾ-ਡੋਮੇਨ ਨਹੀਂ ਹਨ। ਉਹ ਦੋ ਬਿੱਲਾਂ ਵਾਲਾ ਇੱਕ ਅਸਫਲਤਾ-ਡੋਮੇਨ ਹਨ।
ਕੈਰੀਅਰ ਨੂੰ ਸਵਾਲ ਲਿਖਤੀ ਰੂਪ ਵਿੱਚ ਪੁੱਛੋ: ਇਹਨਾਂ ਰਾਹਾਂ ਵਿੱਚੋਂ ਕਿਹੜਾ ਕਿੱਥੇ ਵੱਖ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਸਾਂਝੇ ਹਿੱਸੇ ਦੇ ਅਸਫਲ ਹੋਣ 'ਤੇ ਦਸਤਾਵੇਜ਼ੀ ਵਿਵਹਾਰ ਕੀ ਹੈ? ਡਿਜ਼ਾਈਨ ਕਾਲ ਦੌਰਾਨ ਜ਼ੁਬਾਨੀ ਭਰੋਸਾ ਉਸ ਰੁਕਾਵਟ ਵਿੱਚ ਨਹੀਂ ਟਿਕਦਾ ਜਿਸ ਲਈ ਤੁਸੀਂ ਡਿਜ਼ਾਈਨ ਕਰ ਰਹੇ ਹੋ।
ਅਸਫਲਤਾ-ਡੋਮੇਨ 3: IPsec ਤੋਂ ਬਿਨਾਂ ਬਚਣ ਵਾਲਾ ਰਾਹ
ਨਿੱਜੀ ਪੀਅਰਿੰਗ ਅਤੇ IPsec ਇੱਕੋ ਐਪਲੀਕੇਸ਼ਨ ਪ੍ਰੀਫਿਕਸ ਲਈ ਮੁਕਾਬਲੇ ਵਾਲੇ ਰੂਟ ਦੇ ਸਕਦੇ ਹਨ. ਜੇ ਸੁਰੱਖਿਅਤ ਰਾਹ ਗਾਇਬ ਹੋ ਜਾਵੇ, ਤਾਂ ਬਚਿਆ ਹੋਇਆ ਸਿੱਧਾ ExpressRoute ਰਾਹ ਸੁਰੰਗ ਵੱਲੋਂ ਦਿੱਤੀ ਐਨਕ੍ਰਿਪਸ਼ਨ ਪਰਤ ਤੋਂ ਬਿਨਾਂ ਵੀ ਵਰਤੋਂਯੋਗ ਹੋ ਸਕਦਾ ਹੈ। ਇਹ ਸਵੀਕਾਰਯੋਗ ਹੈ ਜਾਂ ਨਹੀਂ ਇਹ ਨੀਤੀ-ਫੈਸਲਾ ਹੈ, ਅਤੇ ਸਭ ਤੋਂ ਵੱਧ ਅਪ੍ਰਤੱਖ ਛੱਡਿਆ ਜਾਣ ਵਾਲਾ ਫੈਸਲਾ ਵੀ ਇਹੀ ਹੈ।
ਐਨਕ੍ਰਿਪਸ਼ਨ ਦੀਆਂ ਲੋੜਾਂ ਅਤੇ ਉਪਲਬਧਤਾ ਦੀਆਂ ਲੋੜਾਂ ਇੱਥੇ ਸੱਚਮੁੱਚ ਟਕਰਾ ਸਕਦੀਆਂ ਹਨ। «ਬਚਿਆ ਕੋਈ ਵੀ ਰਾਹ ਸਫਲਤਾ ਗਿਣਿਆ ਜਾਂਦਾ ਹੈ» ਇੱਕ ਉਪਲਬਧਤਾ-ਕਥਨ ਹੈ ਜੋ ਐਨਕ੍ਰਿਪਸ਼ਨ ਦੇ ਸਵਾਲ ਦਾ ਚੁੱਪਚਾਪ «ਨਹੀਂ» ਨਾਲ ਜਵਾਬ ਦਿੰਦਾ ਹੈ। ਲਿਖੋ ਕਿ ਕੌਣ ਜਿੱਤਦਾ ਹੈ, ਕਿਹੜੇ ਪ੍ਰੀਫਿਕਸ ਲਈ, ਅਤੇ ਕਿਸਨੇ ਮਨਜ਼ੂਰੀ ਦਿੱਤੀ।
az network vnet-gateway list-advertised-routes -g rg-connectivity -n gw-hub --peer 10.0.0.1
az network vnet-gateway list-learned-routes -g rg-connectivity -n gw-hub -o tableਸਿੱਖੇ ਰੂਟਾਂ ਦੀ ਤੁਲਨਾ ਉਹਨਾਂ ਪ੍ਰੀਫਿਕਸਾਂ ਨਾਲ ਕਰੋ ਜਿਨ੍ਹਾਂ ਦੀ ਤੁਸੀਂ ਉਮੀਦ ਕੀਤੀ ਸੀ। ਛੋਟਾ ਪ੍ਰਬੰਧਕੀ ਭਾਰ ਢੋਣ ਵਾਲਾ ਬਦਲਵਾਂ ਰਾਹ ਉਸ ਭਾਰ ਲਈ ਪੂਰੀ ਤਰ੍ਹਾਂ ਢੁਕਵਾਂ ਹੋ ਸਕਦਾ ਹੈ ਅਤੇ ਉਤਪਾਦਨ ਮੰਗ ਨੂੰ ਲੋੜੀਂਦੀ ਸਮਰੱਥਾ ਤੋਂ ਬਹੁਤ ਦੂਰ ਹੋ ਸਕਦਾ ਹੈ, ਇਸ ਲਈ ਰਾਹ ਦੇ ਕੋਲ ਸਮਰੱਥਾ ਦੀ ਧਾਰਨਾ ਦਰਜ ਕਰੋ।
ਇੱਕ ਫੈਸਲਾ ਨਹੀਂ, ਤਿੰਨ ਵੱਖਰੀਆਂ ਲਾਈਨਾਂ ਦਰਜ ਕਰੋ
ਸਿਰਾ-ਰਿਡੰਡੈਂਸੀ, ਟਰਾਂਸਪੋਰਟ ਰਿਡੰਡੈਂਸੀ ਅਤੇ ਆਫ਼ਤ ਤੋਂ ਬਾਅਦ ਦੀ ਰਿਕਵਰੀ ਨੂੰ ਡਿਜ਼ਾਈਨ ਰਿਕਾਰਡ ਵਿੱਚ ਵੱਖਰੀਆਂ ਐਂਟਰੀਆਂ ਵਜੋਂ ਰੱਖੋ, ਹਰ ਇੱਕ ਦੀ ਆਪਣੀ ਵਿਧੀ, ਆਪਣੀ ਪੁਸ਼ਟੀ ਅਤੇ ਆਪਣਾ ਮਾਲਕ। ਜਦੋਂ ਘਟਨਾ-ਸਮੀਖਿਆ ਪੁੱਛਦੀ ਹੈ ਕਿ ਕਨੈਕਸ਼ਨ ਨੇ ਗੇਟਵੇ ਰੀਸਟਾਰਟ ਕਿਉਂ ਸਹਿਯਾ ਪਰ ਫਾਈਬਰ ਕਟ ਨਹੀਂ, ਤਾਂ ਤਿੰਨ ਲਾਈਨਾਂ ਇੱਕ ਵਾਕ ਵਿੱਚ ਜਵਾਬ ਦਿੰਦੀਆਂ ਹਨ; ਇੱਕ «ਰਿਡੰਡੈਂਟ» ਚੈੱਕਬਾਕਸ ਇਹ ਨਹੀਂ ਕਰ ਸਕਦਾ।
ਫਿਰ ਉਹ ਲਾਈਨਾਂ ਪਰਖੋ ਜੋ ਸਸਤੇ ਵਿੱਚ ਪਰਖੀਆਂ ਜਾ ਸਕਦੀਆਂ ਹਨ। ਇੱਕ ਸੁਰੰਗ ਅਸਫਲ ਕਰੋ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਟਰੈਫਿਕ ਹਿੱਲਦਾ ਹੈ ਅਤੇ ਦੁਬਾਰਾ ਐਨਕ੍ਰਿਪਟ ਹੁੰਦਾ ਹੈ। ਇੱਕ ਰੂਟ ਵਾਪਸ ਲਵੋ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਬਚਿਆ ਰਾਹ ਉਹੀ ਹੈ ਜੋ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਸੀ, ਫਿਰ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਕੀ ਇਹ ਅਜੇ ਵੀ ਐਨਕ੍ਰਿਪਟਿਡ ਹੈ। ਜਿਨ੍ਹਾਂ ਅਸਫਲਤਾਵਾਂ ਦੀ ਨਕਲ ਤੁਸੀਂ ਨਹੀਂ ਕਰ ਸਕੇ ਉਹਨਾਂ ਦਾ ਦਸਤਾਵੇਜ਼ ਬਣਾਓ, ਕਿਉਂਕਿ ਨਾ-ਪਰਖੀ ਲਾਈਨ ਇੱਕ ਧਾਰਨਾ ਹੈ ਅਤੇ ਇਸਨੂੰ ਉਸੇ ਤਰ੍ਹਾਂ ਚਿੰਨ੍ਹਿਤ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।
ਲਾਭਦਾਇਕ ਨਤੀਜਾ ਇੱਕ ਛੋਟੀ ਸਾਰਣੀ ਅਤੇ ਹਰ ਲਾਈਨ ਲਈ ਇੱਕ ਵਾਕ ਹੈ। ਜੇ ਕਿਸੇ ਲਾਈਨ ਵਿੱਚ ਕੋਈ ਵਿਧੀ ਨਹੀਂ ਹੈ, ਤਾਂ ਉਹੀ ਖੋਜ ਹੈ, ਅਤੇ ਇਸਨੂੰ ਡਿਜ਼ਾਈਨ ਸਮੀਖਿਆ ਵਿੱਚ ਲੱਭਣਾ ਦੋਵੇਂ ਸੁਰੰਗਾਂ ਕਦੇ ਨਾ ਸਹਿਣ ਵਾਲੀ ਕੈਰੀਅਰ ਰੁਕਾਵਟ ਦੌਰਾਨ ਲੱਭਣ ਨਾਲੋਂ ਬਹੁਤ ਸਸਤਾ ਹੈ।