VGW of TGW? Wêr't de AWS Site-to-Site IPsec-tunnel einiget

Minsken freegje wêr't in AWS Site-to-Site VPN ophâldt it pakket te beskermjen en ferwachtsje ien antwurd: by de gateway. De nuttige ferzje fan dat antwurd neamt hokker gateway, want in firtuele partikuliere gateway en in transito-gateway binne ferskillende regelingen mei ferskillende oanhechtingsobjecten, en de beoardieler dy't de ferkearde oannimt, bout de rest fan 'e beoardieling op in diagram dat net bestiet. Wurkje de trije kontrôles hjirûnder yn folchoarder ôf. Elk befêstiget óf de grins óf seit dat it foarige antwurd oer in oare boarne gie.

Neam de trije einpunten foardat jo wat beoardielje

In fersiferingsresinsje fan dit paad hat trije neamde dingen nedich: de klantgateway, it AWS VPN-doel dat IPsec beëiniget, en it einpunt fan 'e applikaasje dat it ynderlike pakket ûntfangt. Skriuw se mei har boarne-identifisearders op foardat jo ien konsoleside iepenje, want alles nei dit punt is in útspraak oer ien fan dy trije.

De klantgateway is fan jo en syn konfiguraasje is foar jo sichtber. It AWS-doel is in beheard boarne, en de flater is om it oan te nimmen: in VPN-ferbining kin oan in firtuele partikuliere gateway of direkt oan in transito-gateway hechte, en gjinien betsjut de oare. It tredde einpunt is dat minsken oerslaan, en it is it iennige dat it echte fraachstik oer applikaasjegegevens beantwurdet.

Kontrôle 1: hokker gateway beëiniget de tunnel echt

Beide regelingen wurde stipe en de arsjitektuerhantlieding foar Site-to-Site VPN beskriuwt se neist elkoar, freegje dus de API yn stee fan in diagram dat faak in jier âld is. In lês-allinnich fraach oer ien ferbining jout de VPN-doelfjilden werom:

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

It ûnderskiedende elemint is TransitGatewayId, net VpnGatewayId. In ferbining mei TransitGatewayId leech einiget op in selsstannige firtuele partikuliere gateway, wylst in ferbining mei dat fjild ynsteld einiget op in VPN-oanhechting fan 'e transito-gateway, en VpnGatewayId kin yn dat gefal noch fol wêze, om't it de drage gateway fan 'e oanhechting neame kin. Lês earst it TGW-fjild en befêstigje dan it oanhechtingstype út 'e oanhechtingslist, net út in fjildnamme, want in VPC-oanhechting op dy transito-gateway is net de VPN-oanhechting. It bepaalde eksimplaar yn in ferbûn VPC fine seit neat oer hokker VPN-oanhechting it pakket droegen hat.

Wylst jo dêr binne, kontrolearje de tunnels. De ferbining draacht twa IPsec-tunnels foar oerstalligens, en in ferbining wêrfan't de twadde tunnel nea omheech kommen is, is in echte befinning foar beskikberens, ek al feroaret it neat oan 'e fersiferingsgrins:

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

Kontrôle 2: wat it ynderlike pakket noch draacht

Sadree't IPsec einiget, stjoert AWS it ûntkapsle pakket troch mei de rûte dy't derby paste. Fan dat punt ôf is it ferkear gewoan VPC-ferkear, en de beskerming fan 'e VPN is dien. Dat is gjin gat yn 'e tsjinst; dat is wat de grins betsjut, en it punt fan 'e checklist is om it gewoan te sizzen yn stee fan "de VPN is fersifere" foar "de gegevens binne fan ein oant ein fersifere" stean te litten.

Undersykje no wat der binnen wie. As it ynderlike pakket in applikaasjeprotokol yn iepen tekst is, foeget neat stroomôf fertroulikheid ta oant eat oars it fersiferet. As it ynderlike pakket al in TLS-sesje draacht, feroaret it fuortheljen fan 'e bûtenste IPsec neat foar dy sesje: it bliuwt beskerme oant syn eigen einpunt, wêr't dat einpunt ek is.

De gewoane oerkorreksje is om te konkludearjen dat alles efter de gateway bleatlein is. Dat is net sa. Tsjinstferfier, opslachfersifering en applikaasje-TLS binne aparte meganismen mei aparte betingsten, en elk moat op syn eigen betingsten beoardiele wurde yn stee fan út 'e foarm fan 'e VPN ôflaat te wurden. In flowlog-ynskriuwing mei ACCEPT bewiist dat it rûtsjen wurke en seit neat oer fertroulikheid, en dat is krekt de flater dy't dizze checklist foarkomme wol.

Kontrôle 3: wat TLS efter de gateway beëiniget

Folgje de lústerder, net it adres. As in loadbalancer of proxy TLS beëiniget, einiget de ferbining dy't jo klant hâldt dêr, en de proxy iepenet in twadde ferbining nei de backend dy't iepen tekst wêze kin of TLS mei in oare fertrouwensketen. In partikulier IP-adres en in bypassende rûte binne gjin bewiis oer dy twadde ferbining.

Test it einpunt dêr't jo echt om jouwe fan binnen de VPC, mei de namme dy't de applikaasje brûkt yn stee fan in IP dy't jo ien kear oplost hawwe:

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

Werhelje it foar elke hop dy't it fersyk passearret. As it antwurd ferskilt tusken de klantrjochte namme en de back-endnamme, hawwe jo krekt it segmint fûn dat de VPN nea besloech, en dat is de befinning om op te skriuwen.

Registrearje it resultaat as segminten, net as in oardiel

De útfier fan dizze checklist is in lytse tabel mei ien rige per segmint: klantgateway oant AWS VPN-doel, gateway oant wurklêst, wurklêst oant gegevensopslach, en elke proxy-hop dertusken. Elke rige seit wat it beskermet en wêr't dy beskerming fan ôfhinget. "Fersifere" sûnder meganisme en sûnder einpunt is gjin rige.

Beäntwurdzje dan de oarspronklike eask yn deselde termen as wêryn't er steld is. As de eask is dat gegevens fertroulik bliuwe oant de wurklêst se ûntfangt, foldocht de VPN allinnich oan it earste segmint, en de oerbleaune rigen hawwe applikaasjefierfer, tsjinst-TLS of opslachfersifering nedich dy't apart ynsteld en ferifiearre wurde.

Hâld de ferbinings-identifisearders, de tunnelsteaten en de sertifikaat-subjekten yn 'e registraasje. As immen oer seis moannen weromkomt op it ûntwerp, beäntwurdzje dy trije artefakten de grinsfrage yn minuten yn stee fan it debat op 'e nij fan in diagram ôf te begjinnen.