VGW ਜਾਂ TGW? AWS Site-to-Site ਦਾ IPsec ਟਨਲ ਕਿੱਥੇ ਖਤਮ ਹੁੰਦਾ ਹੈ

ਲੋਕ ਪੁੱਛਦੇ ਹਨ ਕਿ AWS Site-to-Site VPN ਪੈਕੇਟ ਦੀ ਸੁਰੱਖਿਆ ਕਿੱਥੇ ਛੱਡ ਦਿੰਦਾ ਹੈ ਅਤੇ ਇੱਕ ਹੀ ਜਵਾਬ ਦੀ ਉਮੀਦ ਕਰਦੇ ਹਨ: ਗੇਟਵੇ 'ਤੇ। ਉਸ ਜਵਾਬ ਦਾ ਲਾਭਕਾਰੀ ਰੂਪ ਦੱਸਦਾ ਹੈ ਕਿ ਕਿਹੜਾ ਗੇਟਵੇ, ਕਿਉਂਕਿ ਵਰਚੁਅਲ ਪ੍ਰਾਈਵੇਟ ਗੇਟਵੇ ਅਤੇ ਟ੍ਰਾਂਜ਼ਿਟ ਗੇਟਵੇ ਵੱਖਰੇ ਅਟੈਚਮੈਂਟ ਆਬਜੈਕਟ ਵਾਲੇ ਵੱਖਰੇ ਪ੍ਰਬੰਧ ਹਨ, ਅਤੇ ਗਲਤ ਪ੍ਰਬੰਧ ਮੰਨਣ ਵਾਲਾ ਸਮੀਖਿਅਕ ਬਾਕੀ ਮੁਲਾਂਕਣ ਅਜਿਹੇ ਡਾਇਗ੍ਰਾਮ 'ਤੇ ਖੜ੍ਹਾ ਕਰਦਾ ਹੈ ਜੋ ਹੈ ਹੀ ਨਹੀਂ। ਹੇਠਾਂ ਦਿੱਤੀਆਂ ਤਿੰਨ ਜਾਂਚਾਂ ਕ੍ਰਮ ਵਿੱਚ ਕਰੋ। ਹਰ ਇੱਕ ਜਾਂ ਤਾਂ ਸੀਮਾ ਦੀ ਪੁਸ਼ਟੀ ਕਰਦੀ ਹੈ ਜਾਂ ਦੱਸਦੀ ਹੈ ਕਿ ਪਿਛਲਾ ਜਵਾਬ ਕਿਸੇ ਹੋਰ ਸਰੋਤ ਬਾਰੇ ਸੀ।

ਕੁਝ ਵੀ ਮੁਲਾਂਕਣ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਤਿੰਨਾਂ ਅੰਤ ਬਿੰਦੂਆਂ ਦੇ ਨਾਮ ਦਿਓ

ਇਸ ਰਸਤੇ ਦੀ ਐਨਕ੍ਰਿਪਸ਼ਨ ਸਮੀਖਿਆ ਲਈ ਤਿੰਨ ਨਾਮਿਤ ਚੀਜ਼ਾਂ ਚਾਹੀਦੀਆਂ ਹਨ: ਗਾਹਕ ਗੇਟਵੇ, IPsec ਖਤਮ ਕਰਨ ਵਾਲਾ AWS VPN ਟਾਰਗਿਟ, ਅਤੇ ਅੰਦਰੂਨੀ ਪੈਕੇਟ ਪ੍ਰਾਪਤ ਕਰਨ ਵਾਲਾ ਐਪਲੀਕੇਸ਼ਨ ਅੰਤ ਬਿੰਦੂ। ਇੱਕ ਵੀ ਕੰਸੋਲ ਪੰਨਾ ਖੋਲ੍ਹਣ ਤੋਂ ਪਹਿਲਾਂ ਉਹਨਾਂ ਨੂੰ ਉਹਨਾਂ ਦੇ ਸਰੋਤ ਪਛਾਣਕਰਤਾ ਨਾਲ ਲਿਖੋ, ਕਿਉਂਕਿ ਇਸ ਬਿੰਦੂ ਤੋਂ ਬਾਅਦ ਸਭ ਕੁਝ ਉਹਨਾਂ ਤਿੰਨਾਂ ਵਿੱਚੋਂ ਇੱਕ ਬਾਰੇ ਬਿਆਨ ਹੈ।

ਗਾਹਕ ਗੇਟਵੇ ਤੁਹਾਡਾ ਹੈ ਅਤੇ ਇਸ ਦਾ ਸੰਰਚਨਾ ਤੁਹਾਨੂੰ ਦਿਸਦਾ ਹੈ। AWS ਟਾਰਗਿਟ ਇੱਕ ਪ੍ਰਬੰਧਿਤ ਸਰੋਤ ਹੈ, ਅਤੇ ਗਲਤੀ ਇਸ ਨੂੰ ਮੰਨ ਲੈਣਾ ਹੈ: VPN ਕਨੈਕਸ਼ਨ ਵਰਚੁਅਲ ਪ੍ਰਾਈਵੇਟ ਗੇਟਵੇ ਜਾਂ ਸਿੱਧਾ ਟ੍ਰਾਂਜ਼ਿਟ ਗੇਟਵੇ ਨਾਲ ਜੁੜ ਸਕਦਾ ਹੈ, ਅਤੇ ਕੋਈ ਵੀ ਦੂਜੇ ਨੂੰ ਲਾਜ਼ਮੀ ਨਹੀਂ ਕਰਦਾ। ਤੀਜਾ ਅੰਤ ਬਿੰਦੂ ਉਹ ਹੈ ਜਿਸ ਨੂੰ ਲੋਕ ਛੱਡ ਦਿੰਦੇ ਹਨ, ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਡੇਟਾ ਬਾਰੇ ਅਸਲ ਸਵਾਲ ਦਾ ਜਵਾਬ ਸਿਰਫ਼ ਉਹੀ ਦਿੰਦਾ ਹੈ।

ਜਾਂਚ 1: ਟਨਲ ਅਸਲ ਵਿੱਚ ਕਿਹੜਾ ਗੇਟਵੇ ਖਤਮ ਕਰਦਾ ਹੈ

ਦੋਵੇਂ ਪ੍ਰਬੰਧ ਸਮਰਥਿਤ ਹਨ ਅਤੇ Site-to-Site VPN ਆਰਕੀਟੈਕਚਰ ਗਾਈਡ ਉਹਨਾਂ ਨੂੰ ਨਾਲ-ਨਾਲ ਬਿਆਨ ਕਰਦੀ ਹੈ, ਇਸ ਲਈ ਅਕਸਰ ਸਾਲ ਭਰ ਪੁਰਾਣੇ ਡਾਇਗ੍ਰਾਮ ਦੀ ਥਾਂ API ਨੂੰ ਪੁੱਛੋ। ਇੱਕ ਕਨੈਕਸ਼ਨ 'ਤੇ ਸਿਰਫ਼-ਪੜ੍ਹਨ ਵਾਲੀ ਕਿਊਰੀ VPN ਟਾਰਗਿਟ ਖੇਤਰ ਵਾਪਸ ਕਰਦੀ ਹੈ:

aws ec2 describe-vpn-connections --region eu-west-1   --vpn-connection-ids vpn-0123456789abcdef0   --query 'VpnConnections[0].{VGW:VpnGatewayId,TGW:TransitGatewayId,CGW:CustomerGatewayId,Category:Category}'

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

ਉੱਥੇ ਹੁੰਦਿਆਂ ਟਨਲ ਵੀ ਜਾਂਚੋ। ਕਨੈਕਸ਼ਨ ਰਿਡੰਡੈਂਸੀ ਲਈ ਦੋ IPsec ਟਨਲ ਲੈ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਜਿਸ ਕਨੈਕਸ਼ਨ ਦਾ ਦੂਜਾ ਟਨਲ ਕਦੇ ਨਹੀਂ ਉੱਠਿਆ ਉਹ ਉਪਲਬਧਤਾ ਲਈ ਅਸਲ ਖੋਜ ਹੈ, ਭਾਵੇਂ ਇਹ ਐਨਕ੍ਰਿਪਸ਼ਨ ਸੀਮਾ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਬਦਲਦਾ:

aws ec2 describe-vpn-tunnels --region eu-west-1   --filters Name=vpn-connection-id,Values=vpn-0123456789abcdef0   --query 'VpnTunnels[].{Outside:OutsideIpAddress,State:State,Status:Status}'

ਜਾਂਚ 2: ਅੰਦਰੂਨੀ ਪੈਕੇਟ ਅਜੇ ਵੀ ਕੀ ਲੈ ਜਾਂਦਾ ਹੈ

IPsec ਖਤਮ ਹੋਣ ਤੋਂ ਬਾਅਦ AWS ਡੀਕੈਪਸੁਲੇਟਡ ਪੈਕੇਟ ਨੂੰ ਉਸ ਮਾਰਗ ਰਾਹੀਂ ਅੱਗੇ ਭੇਜਦਾ ਹੈ ਜੋ ਇਸ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਸੀ। ਉਸ ਬਿੰਦੂ ਤੋਂ ਟ੍ਰੈਫਿਕ ਆਮ VPC ਟ੍ਰੈਫਿਕ ਹੈ, ਅਤੇ VPN ਦੀ ਸੁਰੱਖਿਆ ਖਤਮ ਹੋ ਗਈ ਹੈ। ਇਹ ਸੇਵਾ ਵਿੱਚ ਖਾਲੀ ਥਾਂ ਨਹੀਂ ਹੈ; ਇਹ ਸੀਮਾ ਦਾ ਅਰਥ ਹੈ, ਅਤੇ ਚੈੱਕਲਿਸਟ ਦੀ ਗੱਲ ਇਹ ਹੈ ਕਿ ਇਸ ਨੂੰ ਸਪਸ਼ਟ ਕਿਹਾ ਜਾਵੇ, "VPN ਐਨਕ੍ਰਿਪਟਿਡ ਹੈ" ਨੂੰ "ਡੇਟਾ ਸ਼ੁਰੂ ਤੋਂ ਅੰਤ ਤੱਕ ਐਨਕ੍ਰਿਪਟਿਡ ਹੈ" ਦੀ ਥਾਂ ਖੜ੍ਹਨ ਨਾ ਦੇਣਾ।

ਹੁਣ ਦੇਖੋ ਕਿ ਅੰਦਰ ਕੀ ਸੀ। ਜੇ ਅੰਦਰੂਨੀ ਪੈਕੇਟ ਸਾਦੇ ਟੈਕਸਟ ਦਾ ਐਪਲੀਕੇਸ਼ਨ ਪ੍ਰੋਟੋਕੋਲ ਹੈ, ਤਾਂ ਜਦ ਤੱਕ ਕੋਈ ਹੋਰ ਇਸ ਨੂੰ ਐਨਕ੍ਰਿਪਟ ਨਹੀਂ ਕਰਦਾ, ਹੇਠਾਂ ਕੁਝ ਵੀ ਗੋਪਨੀਯਤਾ ਨਹੀਂ ਜੋੜਦਾ। ਜੇ ਅੰਦਰੂਨੀ ਪੈਕੇਟ ਪਹਿਲਾਂ ਹੀ TLS ਸੈਸ਼ਨ ਲੈ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਬਾਹਰੀ IPsec ਹਟਾਉਣ ਨਾਲ ਉਸ ਸੈਸ਼ਨ ਵਿੱਚ ਕੁਝ ਨਹੀਂ ਬਦਲਦਾ: ਇਹ ਆਪਣੇ ਅੰਤ ਬਿੰਦੂ ਤੱਕ ਸੁਰੱਖਿਅਤ ਰਹਿੰਦਾ ਹੈ, ਉਹ ਅੰਤ ਬਿੰਦੂ ਜਿੱਥੇ ਵੀ ਹੋਵੇ।

ਆਮ ਵੱਧ-ਸੁਧਾਰ ਇਹ ਹੈ ਕਿ ਗੇਟਵੇ ਪਿੱਛੇ ਸਭ ਕੁਝ ਖੁੱਲ੍ਹਾ ਹੈ। ਐਸਾ ਨਹੀਂ ਹੈ। ਸੇਵਾ ਢੋਆ-ਢੁਆਈ, ਸਟੋਰੇਜ ਐਨਕ੍ਰਿਪਸ਼ਨ ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ TLS ਵੱਖਰੀਆਂ ਸ਼ਰਤਾਂ ਵਾਲੇ ਵੱਖਰੇ ਤੰਤਰ ਹਨ, ਅਤੇ ਹਰ ਇੱਕ ਦਾ ਮੁਲਾਂਕਣ VPN ਦੀ ਸ਼ਕਲ ਤੋਂ ਅਨੁਮਾਨ ਲਾਉਣ ਦੀ ਥਾਂ ਉਸ ਦੀਆਂ ਆਪਣੀਆਂ ਸ਼ਰਤਾਂ 'ਤੇ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ACCEPT ਦਿਖਾਉਂਦੀ ਫਲੋ ਲੌਗ ਐਂਟਰੀ ਸਾਬਤ ਕਰਦੀ ਹੈ ਕਿ ਰਾਊਟਿੰਗ ਕੰਮ ਕੀਤਾ ਅਤੇ ਗੋਪਨੀਯਤਾ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦੀ, ਅਤੇ ਇਹ ਚੈੱਕਲਿਸਟ ਉਹੀ ਗਲਤੀ ਰੋਕਣ ਲਈ ਹੈ।

ਜਾਂਚ 3: ਗੇਟਵੇ ਪਿੱਛੇ TLS ਕੌਣ ਖਤਮ ਕਰਦਾ ਹੈ

ਪਤੇ ਦਾ ਨਹੀਂ, ਸਰੋਤੇ ਦਾ ਪਿੱਛਾ ਕਰੋ। ਜੇ ਲੋਡ ਬੈਲੰਸਰ ਜਾਂ ਪ੍ਰੌਕਸੀ TLS ਖਤਮ ਕਰਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਡੇ ਕਲਾਇੰਟ ਦਾ ਕਨੈਕਸ਼ਨ ਉੱਥੇ ਹੀ ਖਤਮ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਪ੍ਰੌਕਸੀ ਬੈਕਐਂਡ ਨਾਲ ਦੂਜਾ ਕਨੈਕਸ਼ਨ ਖੋਲ੍ਹਦਾ ਹੈ ਜੋ ਸਾਦਾ ਟੈਕਸਟ ਜਾਂ ਵੱਖਰੀ ਭਰੋਸਾ ਲੜੀ ਵਾਲਾ TLS ਹੋ ਸਕਦਾ ਹੈ। ਨਿੱਜੀ IP ਪਤਾ ਅਤੇ ਮੇਲ ਖਾਂਦਾ ਮਾਰਗ ਉਸ ਦੂਜੇ ਕਨੈਕਸ਼ਨ ਦਾ ਸਬੂਤ ਨਹੀਂ ਹਨ।

ਜਿਸ ਅੰਤ ਬਿੰਦੂ ਦੀ ਤੁਹਾਨੂੰ ਸੱਚਮੁੱਚ ਪਰਵਾਹ ਹੈ ਉਸ ਨੂੰ VPC ਦੇ ਅੰਦਰੋਂ ਜਾਂਚੋ, ਐਪਲੀਕੇਸ਼ਨ ਵੱਲੋਂ ਵਰਤੇ ਨਾਮ ਨਾਲ, ਇੱਕ ਵਾਰ ਹੱਲ ਕੀਤੇ IP ਨਾਲ ਨਹੀਂ:

openssl s_client -connect internal.example:443 -servername internal.example -verify_return_error

ਬੇਨਤੀ ਜਿਸ-ਜਿਸ ਹੌਪ ਵਿੱਚੋਂ ਲੰਘਦੀ ਹੈ, ਹਰ ਇੱਕ ਲਈ ਇਹ ਦੁਹਰਾਓ। ਜੇ ਜਵਾਬ ਕਲਾਇੰਟ ਵੱਲ ਦੇ ਨਾਮ ਅਤੇ ਬੈਕਐਂਡ ਨਾਮ ਵਿਚਕਾਰ ਵੱਖਰਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਠੀਕ ਉਹੀ ਹਿੱਸਾ ਲੱਭ ਲਿਆ ਹੈ ਜਿਸ ਨੂੰ VPN ਨੇ ਕਦੇ ਨਹੀਂ ਢੱਕਿਆ, ਅਤੇ ਉਹੀ ਲਿਖਣ ਯੋਗ ਖੋਜ ਹੈ।

ਨਤੀਜਾ ਫੈਸਲੇ ਵਜੋਂ ਨਹੀਂ, ਹਿੱਸਿਆਂ ਵਜੋਂ ਦਰਜ ਕਰੋ

ਇਸ ਚੈੱਕਲਿਸਟ ਦਾ ਨਤੀਜਾ ਇੱਕ ਛੋਟੀ ਸਾਰਣੀ ਹੈ ਜਿਸ ਵਿੱਚ ਹਰ ਹਿੱਸੇ ਲਈ ਇੱਕ ਕਤਾਰ ਹੈ: ਗਾਹਕ ਗੇਟਵੇ ਤੋਂ AWS VPN ਟਾਰਗਿਟ ਤੱਕ, ਗੇਟਵੇ ਤੋਂ ਵਰਕਲੋਡ ਤੱਕ, ਵਰਕਲੋਡ ਤੋਂ ਡੇਟਾ ਸਟੋਰ ਤੱਕ, ਅਤੇ ਵਿਚਕਾਰ ਕੋਈ ਵੀ ਪ੍ਰੌਕਸੀ ਹੌਪ। ਹਰ ਕਤਾਰ ਦੱਸਦੀ ਹੈ ਕਿ ਇਸ ਦੀ ਰੱਖਿਆ ਕੌਣ ਕਰਦਾ ਹੈ ਅਤੇ ਉਹ ਸੁਰੱਖਿਆ ਕਿਸ 'ਤੇ ਨਿਰਭਰ ਹੈ। ਤੰਤਰ ਅਤੇ ਅੰਤ ਬਿੰਦੂ ਤੋਂ ਬਿਨਾਂ "ਐਨਕ੍ਰਿਪਟਿਡ" ਕੋਈ ਕਤਾਰ ਨਹੀਂ ਹੈ।

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

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