ਦੋ ਸ਼ਾਖਾਵਾਂ ਵਿਚਕਾਰ ਟ੍ਰੈਫਿਕ Azure VPN ਗੇਟਵੇ ਰਾਹੀਂ ਰੂਟ ਕਰੋ
ਇੱਕੋ Azure VPN ਗੇਟਵੇ 'ਤੇ ਦੋ ਸਾਈਟ-ਟੂ-ਸਾਈਟ ਕਨੈਕਸ਼ਨ ਸ਼ਾਖਾਵਾਂ ਦਾ ਟ੍ਰੈਫਿਕ ਲੰਘਾ ਸਕਦੇ ਹਨ, ਪਰ ਸਿਰਫ਼ ਤਦ ਜਦੋਂ ਦੋਵੇਂ ਸਿਰੇ ਪ੍ਰੀਫਿਕਸ ਸਿੱਖਦੇ ਹਨ ਅਤੇ LAN ਵਾਪਸੀ ਮਾਰਗ ਮੌਜੂਦ ਹੋਵੇ।
ਦੋ ਸ਼ਾਖਾਵਾਂ ਆਪਸ ਵਿੱਚ ਕਿਸੇ ਸਿੱਧੀ ਸੁਰੰਗ ਤੋਂ ਬਿਨਾਂ Azure VPN ਗੇਟਵੇ ਰਾਹੀਂ ਟ੍ਰੈਫਿਕ ਦਾ ਆਦਾਨ-ਪ੍ਰਦਾਨ ਕਰ ਸਕਦੀਆਂ ਹਨ। ਹਰ ਸ਼ਾਖਾ ਉਸੇ ਗੇਟਵੇ ਨਾਲ ਸਾਈਟ-ਟੂ-ਸਾਈਟ ਕਨੈਕਸ਼ਨ ਖੋਲ੍ਹਦੀ ਹੈ, ਅਤੇ ਗੇਟਵੇ ਸਿੱਖੇ ਪ੍ਰੀਫਿਕਸ ਦੋਵਾਂ ਕਨੈਕਸ਼ਨਾਂ ਵਿਚਕਾਰ ਲੰਘਾਉਂਦਾ ਹੈ। ਇਸ ਨੂੰ ਕੰਮ ਕਰਾਉਣ ਵਾਲੀ ਦੂਜੀ ਸੁਰੰਗ ਨਹੀਂ, ਸਗੋਂ ਰੂਟ ਦਾ ਆਦਾਨ-ਪ੍ਰਦਾਨ ਹੈ: ਸ਼ਾਖਾ A ਨੂੰ ਸ਼ਾਖਾ B ਦਾ ਪ੍ਰੀਫਿਕਸ ਸਿੱਖਣਾ ਪਵੇਗਾ, ਅਤੇ B ਨੂੰ A ਦਾ। ਹੇਠਾਂ ਦਿੱਤੀਆਂ ਜਾਂਚਾਂ ਕ੍ਰਮ ਵਿੱਚ ਕਰੋ ਅਤੇ ਪਹਿਲੀ ਅਸਫਲ ਜਾਂਚ 'ਤੇ ਰੁਕੋ, ਕਿਉਂਕਿ ਹਰ ਅਗਲਾ ਕਦਮ ਉਸ 'ਤੇ ਨਿਰਭਰ ਹੈ।
ਕੁਝ ਵੀ ਕਨਫਿਗਰ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਪੂਰਵ-ਸ਼ਰਤਾਂ
ਇਹ ਡਿਜ਼ਾਈਨ ਆਖਿਰ ਕੰਮ ਕਰ ਸਕਦਾ ਹੈ ਜਾਂ ਨਹੀਂ, ਇਹ ਚਾਰ ਸ਼ਰਤਾਂ ਤੈਅ ਕਰਦੀਆਂ ਹਨ। ਗੇਟਵੇ ਰੂਟ-ਆਧਾਰਿਤ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ BGP ਦਾ ਸਮਰਥਨ ਕਰਨ ਵਾਲੇ SKU 'ਤੇ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਦੋਵੇਂ ਕਨੈਕਸ਼ਨਾਂ 'ਤੇ BGP ਸਕ੍ਰਿਆ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਸ਼ਾਖਾਵਾਂ ਦੇ ਪਤਾ ਖੇਤਰ ਇੱਕ-ਦੂਜੇ 'ਤੇ ਨਹੀਂ ਚੜ੍ਹਨੇ ਚਾਹੀਦੇ, ਅਤੇ ਕੋਈ ਵੀ ਧਿਰ ਆਪਣਾ ਅਸਲੀ ਪ੍ਰੀਫਿਕਸ ਲੁਕਾਉਣ ਲਈ NAT 'ਤੇ ਨਿਰਭਰ ਨਹੀਂ ਹੋ ਸਕਦੀ।
ASN ਦੀ ਯੋਜਨਾ ਜਾਣ-ਬੁੱਝ ਕੇ ਬਣਾਓ। Azure ਦਾ ਦਸਤਾਵੇਜ਼ੀ ਡਿਫ਼ਾਲਟ 65515 ਹੈ, ਅਤੇ ਹਰ ਸ਼ਾਖਾ ਰਾਊਟਰ ਨੂੰ ਆਪਣਾ ਨਿੱਜੀ ASN ਚਾਹੀਦਾ ਹੈ ਜੋ ਗੇਟਵੇ ਜਾਂ ਦੂਜੀ ਸ਼ਾਖਾ ਨਾਲ ਨਾ ਟਕਰਾਏ। ਮੌਜੂਦਾ ਗੇਟਵੇ ਕਨਫਿਗਰੇਸ਼ਨ ਦੀ ਜਾਂਚ ਕੀਤੇ ਬਿਨਾਂ ਡਿਫ਼ਾਲਟ ਦੁਬਾਰਾ ਵਰਤਣਾ ਹੀ ਉਹ ਤਰੀਕਾ ਹੈ ਜਿਸ ਨਾਲ ਬਾਅਦ ਵਿੱਚ AS ਮਾਰਗ ਰੱਦ ਹੋ ਜਾਂਦਾ ਹੈ।
ਇਹ ਵੀ ਪੱਕਾ ਕਰੋ ਕਿ ਤੁਸੀਂ VNet ਪੀਅਰਿੰਗ ਵਿਵਹਾਰ ਦੀ ਉਮੀਦ ਨਹੀਂ ਕਰ ਰਹੇ। ਗੇਟਵੇ ਤੁਹਾਡੇ ਕਨਫਿਗਰ ਕੀਤੇ ਦੋਵਾਂ ਕਨੈਕਸ਼ਨਾਂ ਵਿਚਕਾਰ ਰੂਟ ਦਾ ਆਦਾਨ-ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ; ਇਹ ਮਨਮਾਨੀ ਪੀਅਰਿੰਗਾਂ ਨੂੰ ਪਾਰਗਾਮੀ ਨਹੀਂ ਬਣਾਉਂਦਾ। ਜੇ ਕਿਸੇ ਤੀਜੇ ਨੈੱਟਵਰਕ ਨੂੰ ਦੋਵੇਂ ਸ਼ਾਖਾਵਾਂ ਤੱਕ ਪਹੁੰਚਣਾ ਹੈ, ਤਾਂ ਉਸ ਨੂੰ ਆਪਣਾ ਕਨੈਕਸ਼ਨ ਜਾਂ ਆਪਣਾ ਰੂਟ ਮਾਰਗ ਚਾਹੀਦਾ ਹੈ, ਇਹ ਮੰਨਣਾ ਨਹੀਂ ਕਿ ਗੇਟਵੇ ਟ੍ਰੈਫਿਕ ਵੰਡ ਦੇਵੇਗਾ। ਪਹਿਲੀ ਤਬਦੀਲੀ ਵਿੰਡੋ ਤੋਂ ਪਹਿਲਾਂ ਇਹ ਸੀਮਾ ਲਿਖ ਲਓ, ਕਿਉਂਕਿ ਬਾਅਦ ਵਿੱਚ ਸਾਈਟ ਜੋੜਨ 'ਤੇ ਲੋਕ ਇਸੇ ਡਿਜ਼ਾਈਨ ਫੈਸਲੇ ਵੱਲ ਵਾਪਸ ਆਉਂਦੇ ਹਨ।
ਇਸ ਕ੍ਰਮ ਵਿੱਚ ਕਨਫਿਗਰ ਕਰੋ
ਹਰ ਕਦਮ ਦਾ ਦੇਖਣਯੋਗ ਨਤੀਜਾ ਹੈ, ਇਸ ਲਈ ਉਹ ਦਿਖਣ ਤੱਕ ਅੱਗੇ ਨਾ ਵਧੋ।
- ਵਰਚੁਅਲ ਨੈੱਟਵਰਕ ਗੇਟਵੇ 'ਤੇ BGP ਸਕ੍ਰਿਆ ਕਰੋ ਅਤੇ ਉਸ ਦਾ ASN ਤੇ ਪੀਅਰ ਪਤਾ ਨੋਟ ਕਰੋ।
- ਹਰ ਸ਼ਾਖਾ ਲਈ ਉਸ ਸ਼ਾਖਾ ਦੇ ਅਸਲੀ ਪਤਾ ਖੇਤਰ, ਉਸ ਦੇ ASN ਅਤੇ BGP ਪੀਅਰ ਪਤੇ ਨਾਲ ਸਥਾਨਕ ਨੈੱਟਵਰਕ ਗੇਟਵੇ ਬਣਾਓ।
- ਹਰ ਸਾਈਟ-ਟੂ-ਸਾਈਟ ਕਨੈਕਸ਼ਨ ਬਣਾਓ ਅਤੇ ਕਨੈਕਸ਼ਨ 'ਤੇ ਹੀ BGP ਸਕ੍ਰਿਆ ਕਰੋ।
- ਸ਼ਾਖਾ ਰਾਊਟਰ ਨੂੰ ਅੰਦਾਜ਼ੇ ਦੇ ਆਧਾਰ 'ਤੇ ਗੇਟਵੇ ਦੇ ਜਨਤਕ IKE ਅੰਤ ਬਿੰਦੂ ਨਾਲ ਨਹੀਂ, ਸਗੋਂ Azure ਵੱਲੋਂ ਦਿੱਤੇ ਗੇਟਵੇ ਪਤੇ ਨਾਲ ਪੀਅਰ ਕਰਨ ਲਈ ਕਨਫਿਗਰ ਕਰੋ।
ਚੌਥਾ ਕਦਮ ਹੀ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਬਹੁਤੀਆਂ ਕੋਸ਼ਿਸ਼ਾਂ ਅਟਕਦੀਆਂ ਹਨ। Azure ਜੋ BGP ਪੀਅਰ ਪਤਾ ਦੱਸਦਾ ਹੈ, ਉਹੀ ਸ਼ਾਖਾ ਰਾਊਟਰ ਨੂੰ ਗੁਆਂਢੀ ਵਜੋਂ ਵਰਤਣਾ ਪੈਂਦਾ ਹੈ, ਅਤੇ ਇਹ ਹਮੇਸ਼ਾ ਉਹ ਪਤਾ ਨਹੀਂ ਹੁੰਦਾ ਜਿਸ ਦੀ ਲੋਕ ਸੁਰੰਗ ਚਿੱਤਰ ਤੋਂ ਉਮੀਦ ਕਰਦੇ ਹਨ।
ਸ਼ਾਖਾ ਦਾ ਪ੍ਰੀਫਿਕਸ ਆਪ ਹੀ ਐਲਾਨੋ, ਉਦਾਹਰਨ ਲਈ A ਤੋਂ 10.10.0.0/16 ਅਤੇ B ਤੋਂ 10.20.0.0/16। ਗੁੰਮ ਵਿਸ਼ੇਸ਼ ਨੈੱਟਵਰਕ ਢੱਕਣ ਲਈ ਡਿਫ਼ਾਲਟ ਰੂਟ ਜਾਂ ਚੌੜਾ ਸਮੂਹ ਐਲਾਨ ਨਾ ਕਰੋ; ਖਾਲੀ ਥਾਂ ਬਾਅਦ ਵਿੱਚ ਚੁੱਪ ਕਾਲੇ ਮੋਰੀ ਵਜੋਂ ਵਾਪਸ ਆਉਂਦੀ ਹੈ।
ਦੋਵੇਂ ਸਿਰਿਆਂ 'ਤੇ ਰੂਟ ਦਾ ਆਦਾਨ-ਪ੍ਰਦਾਨ ਪਰਖੋ
ਕਨੈਕਸ਼ਨ ਦੀ ਸਥਿਤੀ ਜਾਂਚ ਨਹੀਂ ਹੈ। ਦੋਵੇਂ ਕਨੈਕਸ਼ਨਾਂ 'ਤੇ IPsec ਚੱਲ ਸਕਦਾ ਹੈ ਪਰ ਉਨ੍ਹਾਂ ਵਿਚਕਾਰ ਕੋਈ ਪ੍ਰੀਫਿਕਸ ਨਹੀਂ ਲੰਘਦਾ। ਗੇਟਵੇ ਦੇ BGP ਪੀਅਰ ਅਤੇ ਸਿੱਖੇ ਰੂਟ ਪੜ੍ਹੋ, ਫਿਰ ਪੱਕਾ ਕਰੋ ਕਿ ਦੂਜੀ ਸ਼ਾਖਾ ਵੱਲ ਦਾ ਰੂਟ ਵਰਤੋਂਯੋਗ ਮਾਰਗ ਵਜੋਂ ਦਿਖਦਾ ਹੈ।
| Check | Where | Stop if |
|---|---|---|
| BGP session established | Gateway BGP peers, branch router neighbour state | Session is Idle or Active on either side |
| Prefix learned | Gateway learned routes, branch BGP table | The other branch's prefix is absent |
| Prefix selected | Branch routing table, effective routes on the VNet | Prefix is known but a more specific route wins |
BGP ਸਾਰਣੀ ਵਿੱਚ ਮੌਜੂਦ ਪ੍ਰੀਫਿਕਸ ਵੀ ਸਥਿਰ ਰੂਟ ਜਾਂ ਵਧੇਰੇ ਵਿਸ਼ੇਸ਼ ਪ੍ਰੀਫਿਕਸ ਅੱਗੇ ਫਾਰਵਰਡਿੰਗ ਫੈਸਲਾ ਹਾਰ ਸਕਦਾ ਹੈ। ਸਿਰਫ਼ ਪ੍ਰਾਪਤ ਰੂਟ ਨਹੀਂ, ਚੁਣਿਆ ਰੂਟ ਜਾਂਚੋ।
LAN ਪਾਸੇ ਵਾਪਸੀ ਮਾਰਗ ਦੀ ਪੈੜ ਲਵੋ
ਇਹ ਉਹ ਹਿੱਸਾ ਹੈ ਜੋ Azure ਵਿੱਚ ਸਹੀ ਦਿਸਦਾ ਹੈ ਅਤੇ ਸਾਈਟ 'ਤੇ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ। ਸ਼ਾਖਾ A ਦਾ ਹੋਸਟ ਆਪਣਾ ਪੈਕਟ A ਦੇ VPN ਰਾਊਟਰ ਨੂੰ ਤਾਂ ਹੀ ਭੇਜਦਾ ਹੈ ਜੇ ਉਹ ਰਾਊਟਰ ਉਸ ਦਾ ਡਿਫ਼ਾਲਟ ਗੇਟਵੇ ਹੈ, ਜਾਂ ਜੇ ਹੋਸਟ ਜਾਂ ਉਸ ਦੇ ਗੇਟਵੇ ਕੋਲ B ਦੇ ਪ੍ਰੀਫਿਕਸ ਲਈ ਰੂਟ ਹੈ। ਉਲਟ ਦਿਸ਼ਾ ਵਿੱਚ ਵੀ ਇਹੀ ਸੱਚ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।
ਜੇ ਕੋਈ ਵੱਖਰਾ ਕੋਰ ਸਵਿੱਚ LAN ਦਾ ਡਿਫ਼ਾਲਟ ਗੇਟਵੇ ਹੈ, ਤਾਂ ਉਸ ਨੂੰ VPN ਰਾਊਟਰ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਨ ਵਾਲਾ ਦੂਜੀ ਸ਼ਾਖਾ ਵੱਲ ਦਾ ਰੂਟ ਚਾਹੀਦਾ ਹੈ। ਉਸ ਤੋਂ ਬਿਨਾਂ ਬੇਨਤੀ ਆਉਂਦੀ ਹੈ ਅਤੇ ਜਵਾਬ ਇੰਟਰਨੈੱਟ ਮਾਰਗ ਰਾਹੀਂ ਨਿਕਲ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਵਰਤੋਂਕਾਰ ਨੂੰ ਖੁੱਲ੍ਹ ਕੇ ਫਿਰ ਅਟਕਣ ਵਾਲਾ ਕਨੈਕਸ਼ਨ ਦਿਸਦਾ ਹੈ।
ਇਸ ਨੂੰ ਠੀਕ ਕਰਨ ਲਈ ਗੇਟਵੇ ਸਬਨੈੱਟ 'ਤੇ ਨੈੱਟਵਰਕ ਸੁਰੱਖਿਆ ਸਮੂਹ ਵੱਲ ਨਾ ਜਾਓ। ਉਸ ਸਬਨੈੱਟ ਦੀਆਂ ਆਪਣੀਆਂ ਲੋੜਾਂ ਹਨ ਅਤੇ ਉੱਥੇ NSG ਸ਼ਾਖਾ-ਪਾਸੇ ਦੀ ਨੀਤੀ ਦਾ ਸਮਰਥਿਤ ਬਦਲ ਨਹੀਂ ਹੈ। ਫਿਲਟਰਿੰਗ ਸ਼ਾਖਾਵਾਂ ਦੇ ਫਾਇਰਵਾਲ ਅਤੇ ਕੰਮ ਦੇ ਭਾਰ 'ਤੇ ਹੀ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ, ਜਿੱਥੇ ਨਿਯਮਾਂ ਦੀ ਸਮੀਖਿਆ ਉਨ੍ਹਾਂ ਦੇ ਮਾਲਕ ਕਰ ਸਕਦੇ ਹਨ। ਉਹ ਨਿਯਮ ਸਬਨੈੱਟ NSG ਵਿੱਚ ਭੇਜਣ ਨਾਲ ਅਗਲੀ ਖਰਾਬੀ ਡੀਬੱਗ ਕਰਨ ਵਾਲੀ ਟੀਮ ਤੋਂ ਵੀ ਉਹ ਲੁਕ ਜਾਂਦੇ ਹਨ।
ਕਾਰਵਾਈ ਦੀ ਆਗਿਆ ਦਿਓ, ਫਿਰ ਰੱਦ ਕੀਤੀ ਜਾਂਚ ਨਾਲ ਸਾਬਤ ਕਰੋ
ਸਿੱਖਿਆ ਰੂਟ ਆਗਿਆ ਨਹੀਂ ਹੈ। ਜੋ ਸਰੋਤ, ਮੰਜ਼ਿਲ ਅਤੇ ਸੇਵਾ ਤੁਹਾਨੂੰ ਸੱਚਮੁੱਚ ਚਾਹੀਦੀ ਹੈ, ਉਸ ਨੂੰ ਸ਼ਾਖਾਵਾਂ ਦੇ ਫਾਇਰਵਾਲ ਅਤੇ ਅੰਤ ਬਿੰਦੂ ਨੀਤੀ ਰਾਹੀਂ ਆਗਿਆ ਦਿਓ, ਅਤੇ ਬਾਕੀ ਰੱਦ ਰਹਿਣ ਦਿਓ।
ਸ਼ਾਖਾ A ਦੇ ਆਮ ਕੰਮ ਦੇ ਭਾਰ ਤੋਂ ਸ਼ਾਖਾ B ਦੀ ਅਸਲੀ ਸੇਵਾ ਤੱਕ ਜਾਂਚ ਕਰੋ, ਜਵਾਬ ਪੱਕਾ ਕਰੋ, ਫਿਰ ਅਜਿਹੀ ਕਾਰਵਾਈ ਅਜ਼ਮਾਓ ਜੋ ਵਰਜਿਤ ਰਹਿਣੀ ਚਾਹੀਦੀ ਹੈ। VPN ਉਪਕਰਣ ਆਪ ਜੋ ਟ੍ਰੈਫਿਕ ਪੈਦਾ ਕਰਦਾ ਹੈ ਉਹ ਵੱਖਰਾ ਸਰੋਤ ਪਤਾ ਵਰਤ ਕੇ LAN ਰੂਟਿੰਗ ਪੜਾਅ ਛੱਡ ਸਕਦਾ ਹੈ, ਇਸ ਲਈ ਰਾਊਟਰ ਤੋਂ ਸਫਲ ping ਦਿਸਣ ਨਾਲੋਂ ਘੱਟ ਸਾਬਤ ਕਰਦਾ ਹੈ।
ਚਾਰ ਤੱਥ ਲਿਖ ਕੇ ਸਮਾਪਤ ਕਰੋ: ਬਦਲੇ ਪ੍ਰੀਫਿਕਸ, ਵਰਤੇ ਜਾ ਰਹੇ ASN, ਹਰ ਪਾਸੇ ਦਾ LAN ਵਾਪਸੀ ਮਾਰਗ, ਅਤੇ ਸੇਵਾ ਦੀ ਆਗਿਆ ਦੇਣ ਵਾਲੀ ਨੀਤੀ। ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਇੱਕ ਵੀ ਗੁੰਮ ਹੋਵੇ ਤਾਂ ਸੈੱਟਅੱਪ ਪਹਿਲੀ ਤਬਦੀਲੀ ਤੱਕ ਕੰਮ ਕਰਦਾ ਹੈ, ਅਤੇ ਫਿਰ ਕੋਈ ਨਹੀਂ ਦੱਸ ਸਕਦਾ ਕਿ ਕਿਉਂ।