AWS Transit Gateway 'ਤੇ ਕਈ VPC ਲਈ ਇੱਕ ਸਾਈਟ-ਤੋਂ-ਸਾਈਟ VPN

ਇਸ ਤਿਮਾਹੀ ਦੋ VPC ਨੂੰ ਦਫ਼ਤਰ ਦਾ ਨੈੱਟਵਰਕ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਦੂਜੀ ਟਨਲ 'ਤੇ ਹੀ ਅੰਦਾਜ਼ਾ ਟੁੱਟਦਾ ਹੈ। AWS Transit Gateway ਸਾਂਝੇ ਰਾਊਟਿੰਗ ਹੱਬ ਵਜੋਂ ਕੰਮ ਕਰ ਸਕਦਾ ਹੈ: VPN ਇੱਕ ਵਾਰ ਜੁੜਦਾ ਹੈ, ਅਤੇ ਹਰ VPC ਉਸੇ ਹੱਬ ਨਾਲ ਜੁੜਦਾ ਹੈ। ਫਿਰ ਸਥਾਨਕ ਨੈੱਟਵਰਕ ਇੱਕ ਕਨੈਕਸ਼ਨ ਰਾਹੀਂ ਹਰ ਜੁੜੇ VPC ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ। ਇਹ ਬਦਲਦਾ ਹੈ ਕਿ ਰਾਊਟਿੰਗ ਦਾ ਫ਼ੈਸਲਾ ਕਿਸ ਕੋਲ ਹੈ, ਅਤੇ ਜ਼ਿਆਦਾਤਰ ਡਿਜ਼ਾਈਨ ਠੀਕ ਇਸੇ ਹਿੱਸੇ ਵਿੱਚ ਗਲਤੀ ਕਰਦੇ ਹਨ।

VPN ਅਟੈਚਮੈਂਟ ਅਤੇ VPC ਅਟੈਚਮੈਂਟ ਇੱਕੋ ਗੇਟਵੇ 'ਤੇ ਵੱਖਰੇ ਆਬਜੈਕਟ ਹਨ, ਇਸ ਲਈ ਰਾਊਟਿੰਗ ਸੰਬੰਧ ਬਾਅਦ ਵਿੱਚ ਬਣਾਉਣੇ ਪੈਂਦੇ ਹਨ।

On-premises network <-> Site-to-Site VPN <-> Transit Gateway
                                            |- VPC A
                                            |- VPC B

ਪੀਅਰਿੰਗ ਉਹ ਛੋਟਾ ਰਾਹ ਕਿਉਂ ਨਹੀਂ ਜਿਸਦੀ ਲੋਕ ਉਮੀਦ ਕਰਦੇ ਹਨ

ਲੁਭਾਉਣ ਵਾਲਾ ਬਦਲ ਇਹ ਹੈ ਕਿ VPN ਨੂੰ VPC A 'ਤੇ ਖ਼ਤਮ ਕਰੋ ਅਤੇ VPC B ਨੂੰ ਉਸ ਨਾਲ ਪੀਅਰ ਕਰੋ। ਆਮ VPC ਪੀਅਰਿੰਗ A ਦੇ VPN ਕਨੈਕਸ਼ਨ ਰਾਹੀਂ ਕਿਨਾਰੇ-ਤੋਂ-ਕਿਨਾਰੇ ਟ੍ਰਾਂਜ਼ਿਟ ਨਹੀਂ ਦਿੰਦੀ। ਪੀਅਰ ਸਿਰਫ਼ ਉਨ੍ਹਾਂ ਪਤਿਆਂ ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ ਜੋ ਪੀਅਰਿੰਗ ਖ਼ੁਦ ਦਿੰਦੀ ਹੈ, ਅਤੇ VPN ਕਿਨਾਰਾ ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਇੱਕ ਨਹੀਂ। ਟ੍ਰਾਂਜ਼ਿਟ ਹੱਬ ਦਿੰਦਾ ਹੈ; ਪੀਅਰਿੰਗ ਤੁਹਾਨੂੰ ਇੱਕ ਜੋੜੀ ਦਿੰਦੀ ਹੈ।

ਉਹ ਸੀਮਾ ਪੀਅਰਿੰਗ ਦੀ ਵਿਸ਼ੇਸ਼ਤਾ ਹੈ, ਨਾ ਕਿ ਕੋਟਾ ਜੋ ਤੁਸੀਂ ਵਧਾ ਸਕਦੇ ਹੋ।

ਸੰਬੰਧ ਅਤੇ ਪ੍ਰਸਾਰ ਵੱਖਰਾ ਕੰਮ ਕਰਦੇ ਹਨ

ਟ੍ਰਾਂਜ਼ਿਟ ਗੇਟਵੇ ਦੇ ਅੰਦਰ ਸੰਬੰਧ ਉਹ ਰਾਊਟ ਟੇਬਲ ਚੁਣਦਾ ਹੈ ਜਿਸ ਨਾਲ ਅਟੈਚਮੈਂਟ ਤੋਂ ਆਉਣ ਵਾਲਾ ਟ੍ਰੈਫਿਕ ਲੱਭਿਆ ਜਾਂਦਾ ਹੈ। ਪ੍ਰਸਾਰ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਕਿਹੜੀਆਂ ਟੇਬਲਾਂ ਨੂੰ ਅਟੈਚਮੈਂਟ ਦੇ ਸਿੱਖੇ ਜਾਂ ਜੁੜੇ ਪ੍ਰੀਫਿਕਸ ਮਿਲਦੇ ਹਨ। ਇੱਕ ਅਟੈਚਮੈਂਟ ਇੱਕ ਟੇਬਲ ਨਾਲ ਸੰਬੰਧਿਤ ਹੋ ਸਕਦਾ ਹੈ ਅਤੇ ਨਾਲ ਹੀ ਕਈ ਵਿੱਚ ਪ੍ਰਸਾਰਿਤ ਹੋ ਸਕਦਾ ਹੈ। ਦੋਵਾਂ ਨੂੰ ਮਿਲਾ ਦੇਣਾ ਹੀ ਉਹ ਤਰੀਕਾ ਹੈ ਜਿਸ ਨਾਲ ਡਿਜ਼ਾਈਨ ਅਜਿਹੀ ਪਹੁੰਚ 'ਤੇ ਪਹੁੰਚਦਾ ਹੈ ਜਿਸਦੀ ਕਿਸੇ ਨੇ ਯੋਜਨਾ ਨਹੀਂ ਬਣਾਈ ਸੀ।

ਪੂਰੀ ਤਰ੍ਹਾਂ ਜੁੜਿਆ ਛੋਟਾ ਹੱਬ ਸੌਖਾ ਕੇਸ ਹੈ।

ਹਰ ਅਟੈਚਮੈਂਟ ਨੂੰ ਇੱਕ ਟੇਬਲ ਵਿੱਚ ਰੱਖੋ ਅਤੇ VPN ਸਮੇਤ ਦੋਵੇਂ VPC ਪ੍ਰੀਫਿਕਸ ਸਾਫ਼ ਹੱਲ ਹੋ ਜਾਂਦੇ ਹਨ। ਇਹ VPC-ਤੋਂ-VPC ਪਹੁੰਚ ਦੀ ਵੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ ਜੋ ਸੰਸਥਾ ਨੇ ਸ਼ਾਇਦ ਕਦੇ ਨਹੀਂ ਚਾਹੀ, ਕਿਉਂਕਿ ਸਾਂਝੀ ਟੇਬਲ ਵਿੱਚ ਸਪੋਕ ਦੀ ਧਾਰਨਾ ਨਹੀਂ ਹੈ।

ਵਰਕਲੋਡ ਰਾਊਟ ਕਿਤੇ ਹੋਰ ਰਹਿੰਦੇ ਹਨ

ਹਰ ਵਰਕਲੋਡ ਸਬਨੈੱਟ ਨੂੰ ਲੋੜੀਂਦੇ ਸਥਾਨਕ ਪ੍ਰੀਫਿਕਸ ਲਈ ਟ੍ਰਾਂਜ਼ਿਟ ਗੇਟਵੇ ਵੱਲ ਆਪਣਾ ਰਾਊਟ ਹਾਲੇ ਵੀ ਚਾਹੀਦਾ ਹੈ। ਉਹ VPC ਰਾਊਟ ਟੇਬਲਾਂ ਗੇਟਵੇ ਦੀਆਂ ਆਪਣੀਆਂ ਟੇਬਲਾਂ ਤੋਂ ਵੱਖਰੇ ਆਬਜੈਕਟ ਹਨ। ਲੋੜੀਂਦੇ ਪ੍ਰੀਫਿਕਸ ਸ਼ਾਮਲ ਕਰੋ ਅਤੇ ਹਰ ਮੰਜ਼ਿਲ ਨੂੰ ਨਵੇਂ ਡਿਫ਼ਾਲਟ ਨਾਲ ਬਦਲਣ ਦੀ ਥਾਂ ਮੌਜੂਦਾ ਰਾਊਟ ਬਚਾਓ। ਸਬਨੈੱਟ ਰਾਊਟ ਗਾਹਕ ਡਿਵਾਈਸ ਨੂੰ ਕੁਝ ਵੀ ਐਲਾਨਦਾ ਨਹੀਂ।

ਡਾਇਨੈਮਿਕ ਜਾਂ ਸਟੈਟਿਕ ਰਾਊਟਿੰਗ ਸੋਚ-ਸਮਝ ਕੇ ਚੁਣੋ; ਪੀਅਰਿੰਗ ਦੋਵਾਂ ਵਿੱਚੋਂ ਕੁਝ ਨਹੀਂ ਦਿੰਦੀ।

ਸਥਾਨਕ ਪਹੁੰਚ ਗੁਆਏ ਬਿਨਾਂ ਸਪੋਕ ਅਲੱਗ ਰੱਖੋ

ਜਦੋਂ A ਅਤੇ B ਦੋਵੇਂ ਦਫ਼ਤਰ ਤੱਕ ਪਹੁੰਚ ਸਕਦੇ ਹਨ ਪਰ ਇੱਕ ਦੂਜੇ ਵੱਲ ਰਾਊਟ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਤਾਂ ਟੇਬਲ ਵੰਡੋ। VPN ਅਟੈਚਮੈਂਟ ਦੀ ਸੰਬੰਧਿਤ ਟੇਬਲ VPC ਪ੍ਰੀਫਿਕਸ ਰੱਖਦੀ ਹੈ। VPC ਅਟੈਚਮੈਂਟਾਂ ਦੀ ਸੰਬੰਧਿਤ ਟੇਬਲ ਸਥਾਨਕ ਪ੍ਰੀਫਿਕਸ ਰੱਖਦੀ ਹੈ, ਬਿਨਾਂ ਕਿਸੇ ਅਜਿਹੇ ਰਾਊਟ ਦੇ ਜੋ A ਨੂੰ B ਨਾਲ ਜੋੜੇ। ਪ੍ਰਸਾਰ ਹੀ ਉਹ ਸੰਬੰਧ ਬਣਾਉਂਦਾ ਹੈ, ਇਸ ਲਈ ਤੁਹਾਨੂੰ ਕਦੇ ਵੀ ਹਰ ਡਿਫ਼ਾਲਟ ਸੰਬੰਧ ਸਵੀਕਾਰ ਨਹੀਂ ਕਰਨਾ ਪੈਂਦਾ।

ਇਹ ਰਾਊਟਿੰਗ ਅਲੱਗਾਅ ਹੈ, ਅਤੇ ਇਹ ਐਪਲੀਕੇਸ਼ਨ ਅਧਿਕਾਰ ਨਹੀਂ ਹੈ।

ਸੁਰੱਖਿਆ ਸਮੂਹ, ਨੈੱਟਵਰਕ ACL, ਹੋਸਟ ਫਾਇਰਵਾਲ ਅਤੇ ਹਰ ਸੇਵਾ ਦੀਆਂ ਆਪਣੀਆਂ ਆਗਿਆਵਾਂ ਹਾਲੇ ਵੀ ਤੈਅ ਕਰਦੀਆਂ ਹਨ ਕਿ ਕਿਹੜਾ ਟ੍ਰੈਫਿਕ ਸਵੀਕਾਰ ਹੁੰਦਾ ਹੈ। ਜੇ ਜਾਂਚ ਲੋੜੀਂਦੀ ਹੈ, ਤਾਂ ਹੱਬ ਇਹ ਕਰੇਗਾ ਮੰਨਣ ਦੀ ਥਾਂ ਉਸਦਾ ਸਮਰਥਿਤ ਰਾਹ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਡਿਜ਼ਾਈਨ ਕਰੋ।

ਹੱਬ ਜੋ ਠੀਕ ਨਹੀਂ ਕਰਦਾ

ਪਤਾ ਯੋਜਨਾਵਾਂ ਹਾਲੇ ਵੀ ਬਿਨਾਂ ਓਵਰਲੈਪ ਦੇ ਰਹਿਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ, ਕਿਉਂਕਿ ਹੱਬ ਇੱਕ ਪ੍ਰੀਫਿਕਸ ਨੂੰ ਦੋ ਵਰਕਲੋਡ ਪਛਾਣਨ ਨਹੀਂ ਦਿੰਦਾ। ਹਰ VPC ਅਟੈਚਮੈਂਟ ਨੂੰ ਉਹ Availability Zone ਕਵਰੇਜ ਚਾਹੀਦੀ ਹੈ ਜਿਸਦੀ ਉਸਦੇ ਵਰਕਲੋਡ ਉਮੀਦ ਕਰਦੇ ਹਨ। BGP ਨਾਲ, ਗਾਹਕ ਡਿਵਾਈਸ ਦੇ ਹਰ ਲੋੜੀਂਦੇ ਪ੍ਰੀਫਿਕਸ ਵੱਲ ਵਾਪਸੀ ਰਾਊਟ ਡਿਜ਼ਾਈਨ ਅਤੇ ਉਸਦੀ ਆਯਾਤ ਨੀਤੀ ਨਾਲ ਮੇਲ ਖਾਣੇ ਚਾਹੀਦੇ ਹਨ। ਗੁੰਮ ਐਲਾਨ ਠੀਕ ਟੁੱਟੀ ਟਨਲ ਵਰਗਾ ਦਿਸਦਾ ਹੈ।

VPN ਕਨੈਕਸ਼ਨ ਅਤੇ ਟ੍ਰਾਂਜ਼ਿਟ ਗੇਟਵੇ ਹੁਣ ਸਾਂਝਾ ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਹਨ।

ਟਨਲ ਰਿਡੰਡੈਂਸੀ, ਡਿਵਾਈਸ ਸਮਰੱਥਾ, ਨਿਗਰਾਨੀ ਅਤੇ ਰੱਖ-ਰਖਾਅ ਦੀ ਯੋਜਨਾ ਸਾਰੇ ਨਿਰਭਰ VPC ਦੁਆਲੇ ਬਣਾਓ, ਹਰ ਇੱਕ ਨੂੰ ਸੁਤੰਤਰ ਤੌਰ 'ਤੇ ਜੁੜਿਆ ਮੰਨਣ ਦੀ ਥਾਂ।

ਮੌਜੂਦਾ virtual private gateway ਪ੍ਰਬੰਧ ਤੋਂ ਮਾਈਗ੍ਰੇਸ਼ਨ ਵੀ ਉਹੀ ਸਪੱਸ਼ਟ ਯੋਜਨਾ ਮੰਗਦੀ ਹੈ। ਅਟੈਚਮੈਂਟ ਅਤੇ ਨੀਤੀਆਂ ਬਣਾਓ, ਇੱਕ ਨਿਯੰਤਰਿਤ ਵਰਕਲੋਡ ਰਾਹ ਹਿਲਾਓ, ਅਤੇ ਪੁਰਾਣਾ ਰਾਹ ਹਟਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਮਨਜ਼ੂਰ ਅਤੇ ਰੱਦ ਕੀਤੇ ਸੰਬੰਧਾਂ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ। ਕੇਂਦਰੀਕਰਨ ਤਦ ਮਦਦ ਕਰਦਾ ਹੈ ਜਦੋਂ ਨੈੱਟਵਰਕ ਟੀਮ ਨੂੰ ਸਾਂਝੀ ਕਨੈਕਟੀਵਿਟੀ ਸੰਭਾਲਣ ਲਈ ਇੱਕ ਥਾਂ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਨੁਕਸਾਨ ਕਰਦਾ ਹੈ ਜਦੋਂ ਇੱਕ ਵੱਡੀ ਟੇਬਲ ਪਿੱਛੇ ਲੁਕਾਉਂਦਾ ਹੈ ਕਿ ਕੌਣ ਕਿਸ ਤੱਕ ਪਹੁੰਚ ਸਕਦਾ ਹੈ।