AWS ਤੋਂ Azure ਸਾਈਟ VPN: ਪਹਿਲਾਂ ਵਾਪਸੀ ਮਾਰਗ ਲਿਖੋ
ਦੋ ਕਲਾਊਡਾਂ ਵਿਚਕਾਰ ਜੁੜਿਆ ਟਨਲ ਉਦੋਂ ਤੱਕ ਕੁਝ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ ਜਦੋਂ ਤੱਕ ਹਰ ਵਰਕਲੋਡ ਸਬਨੈੱਟ ਦੂਰ ਦੇ ਪ੍ਰੀਫਿਕਸ ਵੱਲ ਰੂਟ ਨਹੀਂ ਕਰਦਾ। ਯੋਜਨਾ ਕ੍ਰਮ ਅਨੁਸਾਰ ਕਰੋ, ਫਿਰ ਸੇਵਾ ਦੀ ਜਾਂਚ ਕਰੋ।
ਟਨਲ ਉੱਪਰ ਆਵੇਗਾ। ਆਮ ਤੌਰ ’ਤੇ ਇੰਝ ਹੀ ਹੁੰਦਾ ਹੈ, ਕਿਉਂਕਿ IKE ਨੂੰ ਸਿਰਫ਼ ਮਿਲਦੇ ਪ੍ਰਸਤਾਵ ਅਤੇ ਪਹੁੰਚਯੋਗ ਪੀਅਰ ਪਤਾ ਚਾਹੀਦਾ ਹੈ। ਉਸ ਤੋਂ ਬਾਅਦ ਜੋ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ ਉਹ ਵਾਪਸੀ ਮਾਰਗ ਹੈ: AWS ਵਰਕਲੋਡ ਪੈਕੇਟ ਟਨਲ ਵਿੱਚ ਭੇਜਦਾ ਹੈ, ਪਰ Azure ਪਾਸੇ ਕਿਸੇ ਨੂੰ ਨਹੀਂ ਪਤਾ ਕਿ 10.10.0.0/16 ਨੂੰ ਕਿਵੇਂ ਜਵਾਬ ਦੇਣਾ ਹੈ, ਜਾਂ Azure ਦਾ ਮਾਰਗ ਅਜਿਹੀ ਸਾਰਣੀ ਵਿੱਚ ਹੈ ਜੋ ਵਰਕਲੋਡ ਸਬਨੈੱਟ ਵਰਤਦਾ ਨਹੀਂ। ਕੋਈ ਵੀ ਕੰਸੋਲ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਮਾਰਗ ਯੋਜਨਾ ਲਿਖੋ, ਅਤੇ ਟਨਲ ਕੰਮ ਦਾ ਸਭ ਤੋਂ ਘੱਟ ਦਿਲਚਸਪ ਹਿੱਸਾ ਬਣ ਜਾਵੇਗਾ।
ਕਦਮ 1: ਪਤਾ ਯੋਜਨਾ ਸਥਿਰ ਕਰੋ
ਠੋਸ ਮੁੱਲਾਂ ਨਾਲ ਕੰਮ ਕਰੋ। AWS ਵਰਕਲੋਡ 10.10.0.0/16 ਦੇ ਅੰਦਰ 10.10.1.20 ’ਤੇ ਹੈ ਅਤੇ 10.20.0.0/16 ਦੇ ਅੰਦਰ 10.20.1.30 ’ਤੇ Azure ਸੇਵਾ ਲਈ TCP 443 ਚਾਹੀਦਾ ਹੈ। ਦੋਵੇਂ ਰੇਂਜਾਂ ਇੱਕ ਦੂਜੇ ’ਤੇ ਨਹੀਂ ਚੜ੍ਹਨੀਆਂ ਚਾਹੀਦੀਆਂ, ਅਤੇ ਪ੍ਰਵਾਨਗੀ ਜਾਂਚ ਸੇਵਾ-ਜੋੜੀ ਹੈ, ਟਨਲ ਨਹੀਂ।
ਬਾਕੀ ਕੁਝ ਵੀ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਉਹ ਚਾਰ ਤੱਥ ਲਿਖੋ, ਕਿਉਂਕਿ ਹਰ ਅਗਲਾ ਕਦਮ ਉਨ੍ਹਾਂ ਦੇ ਖਿਲਾਫ਼ ਜਾਂਚਿਆ ਜਾਂਦਾ ਹੈ।
ਕਦਮ 2: ਹਰ ਸਿਰੇ ਦਾ ਮਾਲਕ ਗੇਟਵੇ ਨਾਮ ਦਿਓ
AWS Site-to-Site VPN ਵਰਚੁਅਲ ਪ੍ਰਾਈਵੇਟ ਗੇਟਵੇ ਜਾਂ ਟ੍ਰਾਂਜ਼ਿਟ ਗੇਟਵੇ ’ਤੇ ਖਤਮ ਹੋ ਸਕਦਾ ਹੈ, ਅਤੇ ਇਹ ਵੱਖਰੇ ਰੂਟਿੰਗ ਮਾਲਕ ਹਨ। Azure ਆਪਣਾ ਪ੍ਰਬੰਧਿਤ VPN Gateway ਅਤੇ ਵੱਖਰੇ ਤੌਰ ’ਤੇ ਗਾਹਕਾਂ ਵੱਲੋਂ ਖੁਦ ਚਲਾਏ ਜਾਂਦੇ VM-ਅਧਾਰਿਤ ਉਪਕਰਣ ਦਿੰਦਾ ਹੈ। ਨੋਟ ਕਰੋ ਕਿ ਤੁਹਾਡੇ ਕੋਲ ਕਿਹੜੀ ਜੋੜੀ ਹੈ, ਕਿਉਂਕਿ ਹਰ ਸੁਮੇਲ ਵਿੱਚ ਅਗਲਾ ਹਾਪ ਵੱਖਰਾ ਹੁੰਦਾ ਹੈ।
ਪ੍ਰਬੰਧਿਤ ਗੇਟਵੇ ਲਈ, ਅਨੁਮਾਨਿਤ ਨਿੱਜੀ ਉਪਕਰਣ ਪਤੇ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਨ ਵਾਲਾ ਮਾਰਗ ਨਕਲ ਨਾ ਕਰੋ। ਉਪਕਰਣ ਲਈ, ਇਹ ਨਾ ਮੰਨੋ ਕਿ ਕਲਾਊਡ ਰੂਟ ਪ੍ਰਸਾਰ ਗੈਸਟ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਨੂੰ ਸੰਰਚਿਤ ਕਰਦਾ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਅਜਿਹਾ ਨਹੀਂ ਕਰਦਾ।
ਇੱਥੇ ਗਲਤੀ ਕਰਨ ਨਾਲ ਪੂਰੀ ਦਿਖਣ ਵਾਲੀ ਯੋਜਨਾ ਬਣਦੀ ਹੈ ਅਤੇ ਪੈਕੇਟ ਉਸ ਪਤੇ ’ਤੇ ਭੇਜੇ ਜਾਂਦੇ ਹਨ ਜੋ ਕਦੇ ਜਵਾਬ ਨਹੀਂ ਦਿੰਦਾ।
ਕਦਮ 3: ਹਰ ਵਰਕਲੋਡ ਅਸਲ ਵਿੱਚ ਜੋ ਮਾਰਗ ਵਰਤਦਾ ਹੈ ਉਹ ਲਿਖੋ
ਹੇਠਾਂ ਦੀ ਹਰ ਸੀਮਾ ਇੱਕ ਵੱਖਰੀ ਖੋਜ ਹੈ, ਅਤੇ ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਇੱਕ ਦਾ ਮਾਰਗ ਪੈਕੇਟ ਲਈ ਮਾਰਗ ਨਹੀਂ ਹੈ। ਟਨਲ ਚਾਲੂ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਸਾਰਣੀ ਨੂੰ ਆਪਣੇ ਮੁੱਲਾਂ ਨਾਲ ਭਰੋ।
| Boundary | Must reach | Owner to inspect |
|---|---|---|
| AWS workload subnet | 10.20.0.0/16 | the subnet's VPC route table |
| AWS transit gateway, if used | 10.20.0.0/16 via the VPN attachment | the table associated with that attachment |
| Azure workload subnet | 10.10.0.0/16 | effective routes on the NIC, whatever their source |
| VPN scope | both prefixes, agreed | static connection ranges or BGP advertisements |
AWS ਵਿੱਚ, BGP ਜਾਂ ਟਨਲ ਸਿਹਤਮੰਦ ਹੋਣ ਤੋਂ ਬਾਅਦ ਵੀ ਵਰਕਲੋਡ ਸਬਨੈੱਟ ਦੀ ਮਾਰਗ ਸਾਰਣੀ ਤੁਸੀਂ ਹੀ ਅੱਪਡੇਟ ਕਰਦੇ ਹੋ; ਰੂਟਿੰਗ ਝਲਕ ਇਸਨੂੰ ਕਨੈਕਸ਼ਨ ਦਾ ਹਿੱਸਾ ਮੰਨਦੀ ਹੈ। Azure ਵਿੱਚ, ਵਰਤੋਂਕਾਰ-ਨਿਰਧਾਰਿਤ ਮਾਰਗ ਸਾਰਣੀ ਵਰਚੁਅਲ ਨੈੱਟਵਰਕ ਨਾਲ ਨਹੀਂ, ਸਬਨੈੱਟ ਨਾਲ ਜੁੜਦੀ ਹੈ, ਇਸ ਲਈ ਪ੍ਰਭਾਵੀ ਮਾਰਗ VNet ਬਲੇਡ ਵਿੱਚ ਨਹੀਂ, ਵਰਕਲੋਡ NIC ’ਤੇ ਜਾਂਚੋ।
ਪ੍ਰਬੰਧਿਤ Azure ਗੇਟਵੇ ਗੇਟਵੇ ਪ੍ਰਸਾਰ ਰਾਹੀਂ ਦੂਰ ਦਾ ਪ੍ਰੀਫਿਕਸ ਸਿੱਖ ਸਕਦਾ ਹੈ, ਅਤੇ UDR ਉਹ ਫੈਸਲਾ ਰੱਦ ਕਰ ਸਕਦਾ ਹੈ। ਕਾਰਨ ਹੋਵੇ ਤਾਂ UDR ਸ਼ਾਮਲ ਕਰੋ, ਆਦਤ ਨਾਲ ਨਹੀਂ। ਸ਼ਾਮਲ ਕਰੋ ਤਾਂ ਉਪਕਰਣ ਪਤਾ ਘੜਨ ਦੀ ਬਜਾਏ ਗੇਟਵੇ ਵੱਲੋਂ VPN ਮਾਰਗ ਲਈ ਪ੍ਰਕਾਸ਼ਿਤ ਅਗਲੇ ਹਾਪ ਵੱਲ ਨਿਰਦੇਸ਼ਿਤ ਕਰੋ। ਫਿਰ NIC ’ਤੇ ਪ੍ਰਭਾਵੀ ਮਾਰਗ ਦੁਬਾਰਾ ਪੜ੍ਹੋ, ਕਿਉਂਕਿ ਫੈਸਲਾ ਅਸਲ ਵਿੱਚ ਉੱਥੇ ਹੀ ਲਿਆ ਜਾਂਦਾ ਹੈ।
ਕਦਮ 4: ਦਾਇਰਾ ਮਿਲਾਓ
BGP ਲਈ, ਹਰ ਪਾਸੇ ਦਾ ਐਲਾਨ ਦੂਜੇ ਪਾਸੇ ਵੱਲੋਂ ਅਸਲ ਵਿੱਚ ਸਿੱਖੇ ਨਾਲ ਪ੍ਰੀਫਿਕਸ-ਪ੍ਰੀਫਿਕਸ ਤੁਲਨਾ ਕਰੋ। ਸਥਿਰ ਰੂਟਿੰਗ ਲਈ, ਸੰਰਚਿਤ ਦੂਰ ਦੀਆਂ ਰੇਂਜਾਂ ਦੀ ਤੁਲਨਾ ਕਦਮ 3 ਵਿੱਚ ਲਿਖੇ ਵਰਕਲੋਡ ਮਾਰਗਾਂ ਨਾਲ ਕਰੋ।
ਕ੍ਰਿਪਟੋਗ੍ਰਾਫੀ ’ਤੇ ਸਹਿਮਤ IKE ਸੰਬੰਧ ਇਸ ਦਾ ਸਬੂਤ ਨਹੀਂ ਕਿ ਕਿਸੇ ਪਾਸੇ 10.10.0.0/16 ਜਾਂ 10.20.0.0/16 ਸਿੱਖਿਆ ਹੈ। ਦੋ ਟਨਲ ਉੱਪਰ ਹੋ ਸਕਦੇ ਹਨ ਜਦੋਂ ਕਿ ਇੱਕ ਪਾਸਾ ਤੁਹਾਡੀ ਯੋਜਨਾ ਦੇ /16 ਦੀ ਬਜਾਏ ਇੱਕੋ /24 ਦਾ ਐਲਾਨ ਕਰ ਰਿਹਾ ਹੋਵੇ। ਪ੍ਰੀਫਿਕਸ ਰੂਟਿੰਗ ਸਾਰਣੀ ਵਿੱਚ ਜਾਂਚੋ, ਟਨਲ ਸਥਿਤੀ ਵਿੱਚ ਨਹੀਂ। ਅਸੰਗਤੀ ਬਾਅਦ ਵਿੱਚ ਇੱਕ ਚੱਲਦੇ ਸਬਨੈੱਟ ਅਤੇ ਇੱਕ ਕਦੇ ਜਵਾਬ ਨ ਦੇਣ ਵਾਲੇ ਸਬਨੈੱਟ ਵਜੋਂ ਦਿਸਦੀ ਹੈ।
ਕਦਮ 5: ਸੇਵਾ ਦੀ ਜਾਂਚ ਅਸਲ ਸਰੋਤ ਤੋਂ ਕਰੋ
AWS ਸੁਰੱਖਿਆ ਸਮੂਹਾਂ ਅਤੇ ਨੈੱਟਵਰਕ ACL, Azure NSG, ਅਤੇ ਮਾਰਗ ਦੇ ਕਿਸੇ ਵੀ ਉਪਕਰਣ ਫਿਲਟਰ ਵਿੱਚ ਇੱਛਤ ਪ੍ਰਵਾਹ ਦੀ ਆਗਿਆ ਦਿਓ। ਫਿਰ 10.10.1.20 ਤੋਂ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਸੇਵਾ ਪਤੇ ਅਤੇ ਪੋਰਟ ’ਤੇ ਇੱਕ ਕਨੈਕਸ਼ਨ ਖੋਲ੍ਹੋ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਜਵਾਬ ਉਸੇ ਸਰੋਤ ’ਤੇ ਵਾਪਸ ਆਉਂਦਾ ਹੈ।
ਕਲਾਊਡ ਸੁਰੱਖਿਆ ਸਮੂਹ ਅਤੇ NSG ਦੋਵੇਂ stateful ਹਨ, ਇਸ ਲਈ ਰੱਦ ਕੀਤਾ ਵਾਪਸੀ ਪੈਕੇਟ ਰੂਟਿੰਗ ਦਾ ਲੱਛਣ ਹੈ, ਉਲਟ ਦਿਸ਼ਾ ਵਿੱਚ ਲਿਖਣਾ ਭੁੱਲਿਆ ਨਿਯਮ ਨਹੀਂ।
ਕਿਸੇ ਵੀ ਗੇਟਵੇ ਤੋਂ ping ਕੁਝ ਨਹੀਂ ਤੈਅ ਕਰਦਾ। ਗੇਟਵੇ ਪਤੇ ’ਤੇ ICMP ਕੰਟਰੋਲ ਪਲੇਨ ਮਾਰਗ ਦਾ ਅਭਿਆਸ ਕਰਦਾ ਹੈ, ਵਰਕਲੋਡ ਨੂੰ ਲੋੜੀਂਦੀ ਫਾਰਵਰਡ ਕੀਤੀ TCP ਸੇਵਾ ਨਹੀਂ।
ਰੋਲਬੈਕ ਅਤੇ ਰਿਕਾਰਡ
ਟਨਲ ਪਛਾਣਕਰਤਾਵਾਂ ਦੇ ਨਾਲ ਮਾਰਗ ਮਾਲਕ ਦਰਜ ਕਰੋ ਅਤੇ ਤਬਦੀਲੀ ਤੋਂ ਪਹਿਲਾਂ ਦੀਆਂ ਮਾਰਗ ਸਾਰਣੀਆਂ ਸੰਭਾਲੋ। ਜੇ ਤਬਦੀਲੀ ਹਟਾਉਣੀ ਪਵੇ, ਤਾਂ ਟਨਲ ਤੋੜਨ ਤੋਂ ਪਹਿਲਾਂ ਵਰਕਲੋਡ ਮਾਰਗ ਹਟਾਓ, ਤਾਂ ਜੋ ਕੋਈ ਸਬਨੈੱਟ ਹੁਣ ਨਾ-ਮੌਜੂਦ ਅਗਲੇ ਹਾਪ ਵੱਲ ਨਾ ਦੇਖਦਾ ਰਹੇ।
ਫਿਰ ਬਾਅਦ ਦੇ ਸਬਨੈੱਟ ਟਿਕਾਣਾ ਬਦਲਣ ਜਾਂ spoke ਜੁੜਨ ਲਈ ਅੱਪਡੇਟ ਕਰਨ ਦੀ ਇੱਕ ਨਿਸ਼ਚਿਤ ਥਾਂ ਹੁੰਦੀ ਹੈ, ਕਦੇ ਆਪਣਾ ਨਾ ਰਹੇ ਮਾਰਗ ਦਾ ਦੋਸ਼ ਢੋਣ ਵਾਲੇ ਚੱਲਦੇ ਟਨਲ ਦੀ ਬਜਾਏ।