VGW eða TGW? Hvar IPsec-göng AWS Site-to-Site enda

Fólk spyr hvar AWS Site-to-Site VPN hættir að vernda pakkann og býst við einu svari: við hliðið. Gagnlega útgáfan af því svari nefnir hvaða hlið, því sýndareinkahlið og gegnumstreymishlið eru mismunandi fyrirkomulag með mismunandi viðhengisobjektum, og sá sem rýnir og gerir ráð fyrir hinu ranga byggir restina af matinu á skýringarmynd sem er ekki til. Farðu í gegnum þrjár athuganir hér fyrir neðan í röð. Hver þeirra annaðhvort staðfestir mörkin eða segir þér að fyrra svar hafi verið um aðra auðlind.

Nefndu þrjá endapunkta áður en þú metur nokkuð

Dulritunaryfirferð á þessari leið þarf þrjá nefnda hluti: viðskiptavinahliðið, AWS VPN-markið sem lýkur IPsec, og endapunkt forritsins sem tekur við innri pakkanum. Skrifaðu þá niður með auðlindanúmerum sínum áður en þú opnar eina einustu stjórnborðssíðu, því allt eftir þennan punkt er fullyrðing um einn af þessum þremur.

Viðskiptavinahliðið er þitt og stillingar þess eru sýnilegar þér. AWS-markið er stýrð auðlind, og mistökin eru að gera ráð fyrir henni: VPN-tenging getur tengst sýndareinkahliði eða beint gegnumstreymishliði, og hvorugt felur í sér hitt. Þriðji endapunkturinn er sá sem fólk sleppir, og hann er sá eini sem svarar raunverulegu spurningunni um forritsgögn.

Athugun 1: hvaða hlið endar göngin í raun

Bæði fyrirkomulagið eru studd og arkitektúrleiðbeiningar Site-to-Site VPN lýsa þeim hlið við hlið, svo spurðu API-ið frekar en skýringarmynd sem er oft ársgömul. Lestrarfyrirspurn á einni tengingu skilar VPN-marksreitum:

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

Aðgreiningurinn er TransitGatewayId, ekki VpnGatewayId. Tenging með tómt TransitGatewayId endar á sjálfstæðu sýndareinkahliði, en tenging með það reit sett endar á VPN-viðhengi gegnumstreymishliðs, og VpnGatewayId getur samt verið fyllt í því tilviki því það getur nefnt burðarhlið viðhengisins. Lestu TGW-reitinn fyrst og staðfestu svo tegund viðhengis úr viðhengalistanum frekar en úr reitsheiti, því VPC-viðhengi á því gegnumstreymishliði er ekki VPN-viðhengið. Að finna áfangatilvikið í tengdu VPC segir þér ekkert um hvaða VPN-viðhengi flutti pakkann.

Meðan þú ert þar skaltu athuga göngin. Tengingin ber tvö IPsec-göng til vara, og tenging þar sem annað gengið hefur aldrei komist upp er raunveruleg niðurstaða fyrir framboð þótt hún breyti engu um dulritunarmörkin:

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

Athugun 2: hvað innri pakkinn ber enn

Þegar IPsec lýkur sendir AWS afhjúpaða pakkann áfram eftir þeirri leið sem passaði við hann. Frá þeim punkti er umferðin venjuleg VPC-umferð, og vernd VPN hefur lokið. Það er ekki gat í þjónustunni; það er merking mörkanna, og atriðið á gátlistanum er að segja það skýrt í stað þess að láta "VPN er dulkóðað" standa fyrir "gögnin eru dulkóðuð frá enda til enda".

Skoðaðu nú hvað var inni. Ef innri pakkinn er forritssamskiptareglur í hreinum texta bætir ekkert neðar við trúnaði fyrr en eitthvað annað dulkóðar hann. Ef innri pakkinn ber þegar TLS-lotu breytir fjarlæging ytri IPsec engu fyrir þá lotu: hún helst vernduð til síns eigin endapunkts, hvar sem sá endapunktur er.

Algeng ofleiðrétting er að álykta að allt bak við hliðið sé opið. Það er ekki. Þjónustuflutningur, geymsludulritun og forrits-TLS eru aðskildir fyrirkomulagar með aðskildum skilyrðum, og hvert þeirra verður að meta á eigin forsendum frekar en að álykta það af lögun VPN. Færsla í flæðiskrá sem sýnir ACCEPT sannar að leiðsögnin virkaði og segir ekkert um trúnað, sem er einmitt mistökin sem þessi gátlisti er til að koma í veg fyrir.

Athugun 3: hvað endar TLS bak við hliðið

Fylgdu hlustandanum, ekki vistfanginu. Ef hleðslujafnari eða milliþjónn endar TLS, endar tengingin sem biðlarinn þinn heldur þar, og milliþjónninn opnar aðra tengingu við bakendann sem getur verið hreinn texti eða TLS með annarri traustkeðju. Einkareikningsvistfang og samsvarandi leið eru ekki sönnun um þá aðra tengingu.

Prófaðu endapunktinn sem þér þykir raunverulega vænt um innan úr VPC, með nafninu sem forritið notar frekar en IP sem þú leystir einu sinni:

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

Endurtaktu það fyrir hvert stökk sem beiðnin fer í gegnum. Ef svarið er mismunandi milli nafnsins sem snýr að biðlaranum og nafns bakendans hefur þú fundið nákvæmlega þann hluta sem VPN náði aldrei yfir, og það er niðurstaðan sem á að skrifa niður.

Skráðu niðurstöðuna sem hluta, ekki sem dóm

Úttak þessa gátlista er lítill tafla með einni röð fyrir hvern hluta: viðskiptavinahlið að AWS VPN-marki, hlið að vinnuálagi, vinnuálag að gagnageymslu, og hvert milliþjónsstökk þar á milli. Hver röð segir hvað verndar hana og hvað sú vernd byggist á. "Dulkóðað" án fyrirkomulags og án endapunkts er ekki röð.

Svaraðu svo upprunalegu kröfunni með sömu orðum og hún var sett fram. Ef krafan er að gögnin haldist trúnaðarþegar þar til vinnuálagið tekur við þeim, uppfyllir VPN aðeins fyrsta hlutann, og hinar raðirnar þurfa forritsflutning, þjónustu-TLS eða geymsludulritun sem stillt er og staðfest sérstaklega.

Haltu tengingarnúmerunum, stöðu ganganna og efni skírteinanna í skránni. Þegar einhver kemur aftur að hönnuninni eftir hálft ár svara þessi þrjú gagnsöfn mörkunum spurningunni á nokkrum mínútum í stað þess að hefja rökræðuna upp á nýtt út frá skýringarmynd.