AWS Site-to-Site VPN ਤੋਂ NAT Gateway: VGW ਬਨਾਮ Transit Gateway

ਪਹਿਲੀ ਵਾਰ ਸਾਰੇ ਉਹੀ ਡਾਇਗ੍ਰਾਮ ਬਣਾਉਂਦੇ ਹਨ: VPC ਵਿੱਚ VPN, ਫਿਰ NAT gateway ਰਾਹੀਂ ਇੰਟਰਨੈਟ, ਹੋ ਗਿਆ। ਪਰ ਜਦੋਂ VPN virtual private gateway 'ਤੇ ਖ਼ਤਮ ਹੁੰਦਾ ਹੈ ਤਾਂ AWS ਉਸ ਮਾਰਗ ਦਾ ਸਮਰਥਨ ਨਹੀਂ ਕਰਦਾ, ਅਤੇ ਨਾਕਾਮੀ ਇੰਨੀ ਚੁੱਪ ਹੈ ਕਿ ਟੀਮਾਂ ਇਸਨੂੰ ਇੱਕ ਤੋਂ ਵੱਧ ਵਾਰ ਦੁਬਾਰਾ ਬਣਾਉਂਦੀਆਂ ਹਨ। ਜੋ ਡਿਜ਼ਾਈਨ ਕੰਮ ਕਰਦਾ ਹੈ ਉਸਨੂੰ transit gateway ਚਾਹੀਦਾ ਹੈ, ਜੋ ਦੋਵੇਂ ਪਾਸੇ gateway ਅਤੇ route tables ਬਦਲਦਾ ਹੈ। ਕੁਝ ਵੀ ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਦੋਵੇਂ ਆਕਾਰਾਂ ਦੀ ਤੁਲਨਾ ਕਰੋ।

ਉਹ ਟੋਪੋਲੋਜੀ ਜੋ ਸਪੱਸ਼ਟ ਦਿਸਦੀ ਹੈ ਤੇ ਸਮਰਥਿਤ ਨਹੀਂ

AWS ਦਾ NAT gateway ਦਸਤਾਵੇਜ਼ ਇੱਕ ਲਕੀਰ ਖਿੱਚਦਾ ਹੈ ਜੋ ਹਰ ਉਸ ਵਿਅਕਤੀ ਨੂੰ ਹੈਰਾਨ ਕਰਦੀ ਹੈ ਜਿਸਨੇ ਸਿਰਫ਼ ਇੱਕ VPC ਵਾਲੇ ਡਿਜ਼ਾਈਨ ਬਣਾਏ ਹਨ: Site-to-Site VPN ਕਨੈਕਸ਼ਨ ਦਾ ਟ੍ਰੈਫਿਕ virtual private gateway ਰਾਹੀਂ NAT gateway ਵੱਲ ਰੂਟ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ। VPN ਕਿਸ ਕਿਸਮ ਦੇ gateway 'ਤੇ ਖ਼ਤਮ ਹੁੰਦਾ ਹੈ ਇਹ ਫੈਸਲਾ ਕਰਦਾ ਹੈ ਕਿ ਅਨੁਵਾਦ ਮਾਰਗ ਹੈ ਵੀ ਜਾਂ ਨਹੀਂ। ਗ਼ਲਤੀ ਬਚੀ ਰਹਿੰਦੀ ਹੈ ਕਿਉਂਕਿ ਟਨਲ ਦੀ ਸਥਿਤੀ UP ਹੈ ਅਤੇ ਉਸੇ subnet ਦਾ EC2 instance ਬਿਨਾਂ ਮੁਸ਼ਕਲ ਇੰਟਰਨੈਟ ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ। ਇਹਨਾਂ ਦੋਵੇਂ ਨਿਰੀਖਣਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਟੁੱਟੀ ਦਿਸ਼ਾ ਦੀ ਜਾਂਚ ਨਹੀਂ ਕਰਦਾ।

ਵਿਹਾਰ ਵਿੱਚ ਪੈਕਟ ਆਨ-ਪ੍ਰੈਮਾਈਸਿਜ਼ ਸਰੋਤ ਪਤੇ ਨਾਲ ਆਉਂਦਾ ਹੈ ਅਤੇ ਉਸਦਾ ਅਨੁਵਾਦ ਕਰਨ ਵਾਲਾ ਕੋਈ ਸਮਰਥਿਤ ਅਗਲਾ hop ਨਹੀਂ ਮਿਲਦਾ। ਟੇਬਲਾਂ ਅਨੁਸਾਰ ਇਸਨੂੰ egress ਸੀਮਾ 'ਤੇ ਸੁੱਟ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਟਨਲ UP ਰਹਿਣ ਕਰਕੇ ਤੇ ਉਸੇ subnet ਦਾ instance ਇੰਟਰਨੈਟ ਤੱਕ ਪਹੁੰਚਣ ਕਰਕੇ ਨਾਕਾਮੀ ਆਨ-ਪ੍ਰੈਮਾਈਸਿਜ਼ firewall ਸਮੱਸਿਆ ਵਜੋਂ ਦਰਜ ਹੁੰਦੀ ਹੈ।

Virtual private gateway ਬਨਾਮ transit gateway

ਇੱਕ virtual private gateway ਇੱਕ VPC ਦਾ ਹੁੰਦਾ ਹੈ। ਇਹ VPN ਖ਼ਤਮ ਕਰਦਾ ਹੈ, ਉਸ VPC ਦੀਆਂ route tables ਵਿੱਚ routes ਪਾਉਂਦਾ ਹੈ ਅਤੇ ਉੱਥੇ ਹੀ ਰੁਕ ਜਾਂਦਾ ਹੈ। ਇਸਦਾ attachment ਮਾਡਲ ਨਹੀਂ ਹੈ, ਇਸ ਲਈ ਇਹ ਦੂਜੇ VPC ਜਾਂ ਸਾਂਝੇ egress ਹਿੱਸੇ ਨੂੰ ਟ੍ਰੈਫਿਕ ਨਹੀਂ ਦੇ ਸਕਦਾ। ਇਹ ਇੱਕ-VPC ਦਾਇਰਾ ਹੀ ਪੂਰੀ ਸੀਮਾ ਹੈ, ਅਤੇ VPC ਅੰਦਰ ਜੋੜਿਆ ਕੋਈ route ਇਸਨੂੰ ਨਹੀਂ ਬਦਲਦਾ।

Transit gateway ਇੱਕ ਖੇਤਰੀ ਕੇਂਦਰ ਹੈ ਜਿੱਥੇ VPN, ਹਰ spoke VPC ਅਤੇ ਸਾਂਝੀਆਂ ਸੇਵਾਵਾਂ ਦਾ VPC ਸਭ attachments ਵਜੋਂ ਦਿਸਦੇ ਹਨ। ਇਸਦੀਆਂ ਆਪਣੀਆਂ route tables ਹਨ, ਜੋ ਤੈਅ ਕਰਦੀਆਂ ਹਨ ਕਿ ਕਿਹੜਾ attachment ਦਿੱਤਾ prefix ਲਵੇਗਾ।

ਇਹੀ ਕੇਂਦਰ ਕੇਂਦਰਿਤ egress ਸੰਭਵ ਕਰਦਾ ਹੈ: VPN ਇੱਕ attachment ਵਜੋਂ ਉਤਰਦਾ ਹੈ, egress VPC ਦੂਜੇ ਵਜੋਂ, ਅਤੇ transit gateway ਦੀ route table ਇੰਟਰਨੈਟ ਵੱਲ ਦੇ prefixes ਪਹਿਲੇ ਤੋਂ ਦੂਜੇ ਨੂੰ ਭੇਜਦੀ ਹੈ। virtual private gateway ਨਾਲ ਭੇਜਣ ਲਈ ਦੂਜਾ attachment ਨਹੀਂ ਹੁੰਦਾ, ਇਸ ਲਈ ਡਿਜ਼ਾਈਨ ਬਾਅਦ ਵਿੱਚ ਪੈਚ ਕਰਕੇ ਨਹੀਂ ਬਣਾਇਆ ਜਾ ਸਕਦਾ।

ਸਮਰਥਿਤ egress ਮਾਰਗ, ਕਦਮ ਦਰ ਕਦਮ

ਸੰਦਰਭ ਡਿਜ਼ਾਈਨ ਵਿੱਚ ਪੰਜ hops ਹਨ ਅਤੇ ਹਰ ਤੀਰ ਇੱਕ route ਫੈਸਲਾ ਹੈ ਜੋ ਤੁਹਾਨੂੰ ਸੰਰਚਿਤ ਕਰਨਾ ਹੈ। ਟ੍ਰੈਫਿਕ ਆਨ-ਪ੍ਰੈਮਾਈਸਿਜ਼ ਨੈੱਟਵਰਕ ਤੋਂ Site-to-Site VPN attachment ਵਿੱਚ ਜਾਂਦਾ ਹੈ, transit gateway ਦੀ route table ਇਸਨੂੰ egress VPC attachment ਵੱਲ ਭੇਜਦੀ ਹੈ, ਜਿੱਥੇ subnet ਟੇਬਲ ਇਸਨੂੰ ਜਨਤਕ NAT gateway ਵੱਲ ਭੇਜਦੀ ਹੈ। NAT gateway ਸਰੋਤ ਦਾ ਅਨੁਵਾਦ ਕਰਦਾ ਹੈ ਅਤੇ internet gateway ਪੈਕਟ ਬਾਹਰ ਲੈ ਜਾਂਦਾ ਹੈ।

On-premises network
  -> Site-to-Site VPN attachment on the transit gateway
  -> transit gateway route table
  -> egress VPC attachment
  -> public NAT gateway in that VPC
  -> internet gateway

ਆਖਰੀ hops ਕੰਮ ਕਰਨਗੇ ਜਾਂ ਨਹੀਂ ਇਹ ਦੋ ਗੱਲਾਂ ਤੈਅ ਕਰਦੀਆਂ ਹਨ। NAT gateway ਜਨਤਕ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, elastic IP ਅਤੇ internet gateway ਵੱਲ route ਨਾਲ, ਕਿਉਂਕਿ ਨਿੱਜੀ NAT gateway ਨੈੱਟਵਰਕਾਂ ਵਿਚਕਾਰ ਅਨੁਵਾਦ ਕਰਦਾ ਹੈ ਅਤੇ ਕਦੇ ਇੰਟਰਨੈਟ ਨਿਕਾਸ ਨਹੀਂ ਬਣਦਾ।

ਤੁਸੀਂ ਜਿਸ ਵੀ Availability Zone ਨੂੰ ਸੇਵਾ ਦੇਣਾ ਚਾਹੁੰਦੇ ਹੋ ਉਸ ਲਈ ਇੱਕ NAT gateway ਦੀ ਯੋਜਨਾ ਬਣਾਓ ਅਤੇ ਹਰ subnet ਟੇਬਲ ਸਥਾਨਕ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰੇ। ਆਪਣੀਆਂ ਨੋਟਾਂ ਵਿੱਚ transit gateway ਦੀ ਟੇਬਲ ਅਤੇ VPC ਦੀਆਂ ਟੇਬਲਾਂ ਨੂੰ ਵੱਖਰੀਆਂ ਵਸਤੂਆਂ ਵਜੋਂ ਰੱਖੋ, ਕਿਉਂਕਿ ਇੱਕ attachment ਚੁਣਦੀ ਹੈ ਅਤੇ ਦੂਜੀ VPC ਅੰਦਰ ਦਾ ਸਰੋਤ। ਸਿਰਫ਼ ਇੱਕ ਵਿੱਚ default route ਹੋਵੇ ਤਾਂ ਅੱਧਾ ਮਾਰਗ ਅਣ-ਪਰਿਭਾਸ਼ਿਤ ਰਹਿੰਦਾ ਹੈ ਅਤੇ ਉਹ ਅੰਸ਼ਕ ਨਾਕਾਮੀਆਂ ਬਣਦੀਆਂ ਹਨ ਜਿਨ੍ਹਾਂ ਨੂੰ ਜੋੜਨਾ ਸਭ ਤੋਂ ਔਖਾ ਹੈ।

ਇਹ ਡਿਜ਼ਾਈਨ ਵਾਪਸੀ ਮਾਰਗ 'ਤੇ ਹੀ ਫੇਲ੍ਹ ਹੁੰਦੇ ਹਨ

NAT gateway ਪਹਿਲਾਂ ਦੇਖੇ flows ਲਈ stateful ਹੈ, ਇਸ ਲਈ ਬਾਹਰ ਜਾਂਦੇ ਕਨੈਕਸ਼ਨ ਦੇ ਜਵਾਬ ਨਵੇਂ inbound ਨਿਯਮ ਬਿਨਾਂ ਵਾਪਸ ਆਉਂਦੇ ਹਨ। ਉਹ ਗੁਣ ਕਿਸੇ ਆਨ-ਪ੍ਰੈਮਾਈਸਿਜ਼ ਸੇਵਾ ਨੂੰ ਇੰਟਰਨੈਟ 'ਤੇ ਪ੍ਰਕਾਸ਼ਿਤ ਨਹੀਂ ਕਰਦਾ, ਅਤੇ ਇੰਜ ਮੰਨਣਾ ਕਿ ਕਰਦਾ ਹੈ, ਟੀਮ ਨੂੰ ਉਸ ਕਨੈਕਸ਼ਨ ਨੂੰ ਡੀਬੱਗ ਕਰਨ ਵਿੱਚ ਦਿਨ ਲੰਘਾਉਣਾ ਪੈਂਦਾ ਹੈ ਜੋ ਕਦੇ ਬਣਨਾ ਹੀ ਨਹੀਂ ਸੀ। ਕਲਾਇੰਟ ਤੋਂ ਸ਼ੁਰੂ ਹੋਣ ਵਾਲੇ ਟ੍ਰੈਫਿਕ ਲਈ ਚਾਰ routes ਸਹਿਮਤ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ: ਆਨ-ਪ੍ਰੈਮਾਈਸਿਜ਼ ਨੀਤੀ, transit gateway ਦੀ ਟੇਬਲ, egress subnet ਟੇਬਲ ਅਤੇ NAT subnet ਟੇਬਲ। ਆਖਰੀ ਖੁੰਝ ਗਈ ਤਾਂ ਬੇਨਤੀ ਇਮਾਰਤ ਛੱਡ ਦਿੰਦੀ ਹੈ ਜਦਕਿ ਜਵਾਬ AWS ਅੰਦਰ ਮਰ ਜਾਂਦਾ ਹੈ।

VPN ਪਿੱਛੇ ਦੇ ਅਸਲ ਕਲਾਇੰਟ ਨਾਲ ਪੁਸ਼ਟੀ ਕਰੋ ਅਤੇ ਵੇਖੋ ਕਿ ਇਹ ਕਿਹੜਾ ਜਨਤਕ ਸਰੋਤ ਪਤਾ ਪੇਸ਼ ਕਰਦਾ ਹੈ। ਜੇ ਉਹ NAT gateway ਦਾ elastic IP ਹੈ ਤਾਂ ਅਨੁਵਾਦ ਹੋ ਰਿਹਾ ਹੈ; ਜੇ ਕੁਝ ਹੋਰ ਹੈ ਤਾਂ ਤੁਸੀਂ ਵੱਖਰਾ egress ਮਾਪ ਰਹੇ ਹੋ।

ਇਸ ਨਾਕਾਮੀ ਦਾ ਅਸਮਮਿਤ ਰੂਪ ਜਲਦੀ ਪਛਾਣਨਾ ਚਾਹੀਦਾ ਹੈ। ਜਦੋਂ ਇੱਕ Availability Zone ਦੀ NAT subnet ਟੇਬਲ ਵਿੱਚ ਕਲਾਇੰਟ prefix ਵੱਲ ਵਾਪਸੀ route ਹੁੰਦਾ ਹੈ ਅਤੇ ਦੂਜੀ ਵਿੱਚ ਨਹੀਂ, ਤਾਂ ਨਵੇਂ ਕਨੈਕਸ਼ਨ flow ਕਿਸ ਜ਼ੋਨ ਵਿੱਚ ਪੈਂਦਾ ਹੈ ਇਸ ਅਨੁਸਾਰ ਸਫਲ ਜਾਂ ਫੇਲ੍ਹ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਇਸ ਪੈਟਰਨ ਨੂੰ ਗ਼ਲਤੀ ਨਾਲ ਅਸਥਿਰ ਇੰਟਰਨੈਟ ਪੜ੍ਹਿਆ ਜਾਂਦਾ ਹੈ। ਟਿਕਟ ਖੁੱਲ੍ਹੀ ਜ਼ੋਨ ਨੂੰ ਠੀਕ ਕਰਨ ਦੀ ਥਾਂ ਤੁਸੀਂ ਸੇਵਾ ਦੇਣ ਵਾਲੇ ਹਰ ਜ਼ੋਨ ਦੀਆਂ subnet ਟੇਬਲਾਂ ਦੀ ਤੁਲਨਾ ਕਰੋ, ਕਿਉਂਕਿ ਗੁੰਮ route ਹੀ ਪੂਰਾ ਨੁਕਸ ਹੈ ਅਤੇ ਦੂਜੇ ਪਾਸੇ ਕੁਝ ਬਦਲਣ ਦੀ ਲੋੜ ਨਹੀਂ।

ਕਦੋਂ ਸਪੱਸ਼ਟ proxy ਬਿਹਤਰ ਡਿਜ਼ਾਈਨ ਹੈ

egress VPC ਦੇ instance 'ਤੇ HTTP proxy ਇੱਕ ਜਾਇਜ਼ ਵਿਕਲਪ ਹੈ ਅਤੇ ਅਕਸਰ ਸਸਤਾ ਵੀ। ਕਲਾਇੰਟ ਇਸਨੂੰ ਵਰਤਣ ਲਈ ਸੰਰਚਿਤ ਹੁੰਦੇ ਹਨ, proxy ਆਪਣਾ ਕਨੈਕਸ਼ਨ ਬਾਹਰ ਖੋਲ੍ਹਦਾ ਹੈ, ਅਤੇ ਵਾਪਸੀ ਮਾਰਗ ਸਮਮਿਤ routing ਦੀ ਬੁਝਾਰਤ ਨਹੀਂ ਸਗੋਂ proxy ਦੀ ਸਮੱਸਿਆ ਬਣ ਜਾਂਦਾ ਹੈ। ਥੋੜ੍ਹੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਲਈ ਇਹ transit gateway ਦਾ ਵੱਡਾ ਹਿੱਸਾ ਕੰਮ ਹਟਾ ਦਿੰਦਾ ਹੈ। ਇਹ NAT gateway ਨਾ ਬਣਾ ਸਕਣ ਵਾਲੀ ਪ੍ਰਤੀ-ਵਰਤੋਂਕਾਰ ਲੌਗਿੰਗ ਵੀ ਦਿੰਦਾ ਹੈ।

ਪਰ ਇਹ ਪਾਰਦਰਸ਼ੀ ਨਹੀਂ ਹੈ। proxy ਸੈਟਿੰਗਾਂ ਨੂੰ ਅਣਡਿੱਠ ਕਰਨ ਵਾਲੀ ਹਰ ਚੀਜ਼, ਅਤੇ HTTP ਨਾ ਹੋਣ ਵਾਲਾ ਹਰ ਪ੍ਰੋਟੋਕੋਲ, ਉਸ ਮਾਰਗ 'ਤੇ ਨਹੀਂ ਜਾਵੇਗਾ।

ਚੋਣ ਇਸ 'ਤੇ ਹੈ ਕਿ ਤੁਹਾਡੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਅਸਲ ਵਿੱਚ ਕੀ ਬੋਲਦੀਆਂ ਹਨ ਅਤੇ ਲੌਗਾਂ ਵਿੱਚ ਕਿੰਨੀ ਪਛਾਣ ਚਾਹੀਦੀ ਹੈ। ਜਿੱਥੇ ਉਹ HTTP ਬੋਲਦੀਆਂ ਹਨ ਉੱਥੇ proxy ਆਪਣੀ ਥਾਂ ਕਮਾਉਂਦਾ ਹੈ; ਜਿੱਥੇ ਮਨਮਾਨੇ ਪ੍ਰੋਟੋਕੋਲ ਲਈ ਆਮ egress ਚਾਹੀਦਾ ਹੈ ਉੱਥੇ AWS ਵੱਲੋਂ ਸਮਰਥਿਤ ਡਿਜ਼ਾਈਨ transit gateway ਵਾਲਾ ਹੈ। ਇਹ ਪਹਿਲਾਂ ਤੈਅ ਕਰਨਾ route tables ਬਣਨ ਤੋਂ ਬਾਅਦ ਲੱਭਣ ਤੋਂ ਸਸਤਾ ਹੈ।