VGW o TGW? Saan nagtatapos ang IPsec tunnel ng AWS Site-to-Site

Nagtatanong ang mga tao kung saan tumitigil ang AWS Site-to-Site VPN sa pagprotekta sa packet at umaasa ng isang sagot: sa gateway. Ang kapaki-pakinabang na bersyon ng sagot ay nagsasabi kung aling gateway, dahil ang virtual private gateway at transit gateway ay magkaibang kaayusan na may magkaibang attachment object, at ang reviewer na nagpapalagay ng mali ay nagtatayo ng natitirang assessment sa isang diagram na wala naman. Gawin ang tatlong pagsusuri sa ibaba nang sunod-sunod. Ang bawat isa ay nagpapatunay sa hangganan o nagsasabi sa iyo na ang dating sagot ay tungkol sa ibang resource.

Pangalanan ang tatlong endpoint bago magsuri ng anuman

Ang encryption review ng path na ito ay nangangailangan ng tatlong pinangalanang bagay: ang customer gateway, ang AWS VPN target na nagtatapos sa IPsec, at ang application endpoint na tumatanggap ng panloob na packet. Isulat ang mga ito kasama ang kanilang resource identifier bago magbukas ng kahit isang pahina ng console, dahil lahat ng sumunod sa puntong ito ay pahayag tungkol sa isa sa tatlong iyon.

Ang customer gateway ay sa iyo at ang configuration nito ay nakikita mo. Ang AWS target ay managed resource, at ang pagkakamali ay ang ipalagay ito: ang VPN connection ay maaaring mag-attach sa virtual private gateway o direkta sa transit gateway, at wala sa dalawa ang nagsasama ng isa pa. Ang ikatlong endpoint ay ang madalas laktawan ng mga tao, at ito lang ang sumasagot sa tunay na tanong tungkol sa application data.

Pagsusuri 1: aling gateway ang tunay na nagtatapos sa tunnel

Parehong sinusuportahan ang dalawang kaayusan at ang architecture guide ng Site-to-Site VPN ay inilalarawan sila nang magkatabi, kaya tanungin ang API sa halip na diagram na kadalasan ay isang taon na. Ang read-only na query sa isang connection ay nagbabalik ng mga field ng VPN target:

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}'

Ang discriminating factor ay TransitGatewayId, hindi VpnGatewayId. Ang connection na may TransitGatewayId na walang laman ay nagtatapos sa standalone na virtual private gateway, habang ang connection na may nakatakdang field na iyon ay nagtatapos sa VPN attachment ng transit gateway, at ang VpnGatewayId ay maaaring puno pa rin sa kasong iyon dahil maaari nitong pangalanan ang backing gateway ng attachment. Basahin muna ang TGW field, pagkatapos ay tiyakin ang uri ng attachment mula sa listahan ng attachment, hindi mula sa pangalan ng field, dahil ang VPC attachment sa transit gateway na iyon ay hindi ang VPN attachment. Ang paghahanap ng destination instance sa isang konektadong VPC ay walang sinasabi tungkol sa kung aling VPN attachment ang nagdala ng packet.

Habang nandoon ka, tingnan din ang mga tunnel. Ang connection ay nagdadala ng dalawang IPsec tunnel para sa redundancy, at ang connection na ang pangalawang tunnel ay hindi kailanman umangat ay tunay na natuklasan para sa availability kahit na wala itong binabago sa hangganan ng encryption:

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}'

Pagsusuri 2: ano pa ang dinadala ng panloob na packet

Kapag natapos ang IPsec, ipinapasa ng AWS ang decapsulated na packet sa rutang tumugma dito. Mula sa puntong iyon ang trapiko ay ordinaryong VPC traffic, at tapos na ang proteksyon ng VPN. Hindi ito butas sa serbisyo; ito ang ibig sabihin ng hangganan, at ang item sa checklist ay sabihin ito nang malinaw sa halip na hayaan ang "naka-encrypt ang VPN" na pumalit sa "naka-encrypt ang data mula simula hanggang dulo".

Ngayon suriin kung ano ang nasa loob. Kung ang panloob na packet ay application protocol sa plaintext, walang nagdaragdag ng confidentiality sa ibaba hanggang may ibang mag-encrypt nito. Kung ang panloob na packet ay may dalang TLS session na, ang pagtanggal ng panlabas na IPsec ay walang binabago para sa session na iyon: nananatili itong protektado hanggang sa sarili nitong endpoint, nasaan man ang endpoint na iyon.

Ang karaniwang labis na pagwawasto ay ang tapusin na lahat ng nasa likod ng gateway ay nakalantad. Hindi. Ang service transport, storage encryption at application TLS ay magkahiwalay na mekanismo na may magkahiwalay na kondisyon, at ang bawat isa ay dapat suriin sa sarili nitong mga tuntunin sa halip na hanguin mula sa hugis ng VPN. Ang flow log entry na nagpapakita ng ACCEPT ay nagpapatunay na gumana ang routing at walang sinasabi tungkol sa confidentiality, at iyon mismo ang pagkakamaling dapat pigilan ng checklist na ito.

Pagsusuri 3: ano ang nagtatapos sa TLS sa likod ng gateway

Sundin ang listener, hindi ang address. Kung ang load balancer o proxy ay nagtatapos sa TLS, ang connection na hawak ng iyong client ay nagtatapos doon, at ang proxy ay nagbubukas ng pangalawang connection sa backend na maaaring plaintext o TLS na may ibang trust chain. Ang pribadong IP address at tugmang ruta ay hindi ebidensya tungkol sa pangalawang connection na iyon.

Subukan ang endpoint na talagang mahalaga sa iyo mula sa loob ng VPC, gamit ang pangalang ginagamit ng application at hindi ang IP na naresolba mo minsan:

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

Ulitin ito para sa bawat hop na dinadaanan ng request. Kung ang sagot ay naiiba sa pagitan ng pangalang nakaharap sa client at ng pangalan ng backend, natagpuan mo mismo ang segment na hindi kailanman sinaklaw ng VPN, at iyon ang natuklasang dapat isulat.

Itala ang resulta bilang mga segment, hindi bilang hatol

Ang output ng checklist na ito ay isang maliit na talahanayan na may isang hilera bawat segment: customer gateway hanggang AWS VPN target, gateway hanggang workload, workload hanggang data store, at anumang proxy hop sa pagitan. Sinasabi ng bawat hilera kung ano ang nagpoprotekta rito at ano ang nakasalalay sa proteksyong iyon. Ang "naka-encrypt" na walang mekanismo at walang endpoint ay hindi hilera.

Pagkatapos sagutin ang orihinal na pangangailangan sa parehong mga salitang ginamit nang itanong ito. Kung ang pangangailangan ay manatiling kumpidensyal ang data hanggang matanggap ito ng workload, ang VPN ay tumutugon lamang sa unang segment, at ang natitirang mga hilera ay nangangailangan ng application transport, service TLS o storage encryption na hiwalay na na-configure at na-verify.

Itago ang mga connection identifier, estado ng tunnel at subject ng certificate sa talaan. Kapag may bumalik sa disenyo pagkalipas ng anim na buwan, ang tatlong artifact na iyon ay sasagot sa tanong ng hangganan sa ilang minuto sa halip na simulan muli ang pagtatalo mula sa isang diagram.