VGW ar TGW? Kur baigiasi „AWS Site-to-Site“ IPsec tunelis

Žmonės klausia, kur „AWS Site-to-Site VPN“ nustoja saugoti paketą, ir tikisi vieno atsakymo: prie vartų. Naudinga to atsakymo versija įvardija, kurie vartai, nes virtualūs privatūs vartai ir tranzito vartai yra skirtingos struktūros su skirtingais priedo objektais, o recenzentas, kuris daro prielaidą apie netinkamus, likusį vertinimą stato ant diagramos, kurios nėra. Atlikite tris patikras žemiau iš eilės. Kiekviena arba patvirtina ribą, arba pasako, kad ankstesnis atsakymas buvo apie kitą išteklių.

Įvardykite tris galinius taškus prieš ką nors vertindami

Šio kelio šifravimo apžvalgai reikia trijų įvardytų dalykų: kliento vartų, AWS VPN tikslo, kuris užbaigia IPsec, ir programos galinio taško, kuris priima vidinį paketą. Užsirašykite juos su išteklių identifikatoriais prieš atidarydami nė vieną konsolės puslapį, nes viskas po šio taško yra teiginys apie vieną iš tų trijų.

Kliento vartai yra jūsų, o jų konfigūracija jums matoma. AWS tikslas yra valdomas išteklius, o klaida yra jį preziumuoti: VPN ryšys gali prisijungti prie virtualių privačių vartų arba tiesiogiai prie tranzito vartų, ir nė vienas nereiškia kito. Trečiasis galinis taškas yra tas, kurį žmonės praleidžia, ir jis vienintelis atsako į tikrąjį klausimą apie programos duomenis.

Patikra 1: kurie vartai iš tikrųjų užbaigia tunelį

Abi struktūros palaikomos, ir „Site-to-Site VPN“ architektūros vadovas aprašo jas greta, todėl klauskite API, o ne diagramos, kuriai dažnai jau metai. Vieno ryšio tik skaitymo užklausa grąžina VPN tikslo laukus:

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

Skiriamasis požymis yra TransitGatewayId, o ne VpnGatewayId. Ryšys, kuriame TransitGatewayId tuščias, baigiasi prie atskirų virtualių privačių vartų, o ryšys, kuriame tas laukas nustatytas, baigiasi prie tranzito vartų VPN priedo, ir VpnGatewayId tokiu atveju gali vis dar būti užpildytas, nes gali įvardyti priedą laikantį vartus. Pirmiausia perskaitykite TGW lauką, tada patvirtinkite priedo tipą iš priedų sąrašo, o ne iš lauko pavadinimo, nes to tranzito vartų VPC priedas nėra VPN priedas. Radus tikslinį egzempliorių prijungtame VPC, nieko nesužinosite apie tai, kuris VPN priedas pernešė paketą.

Kol ten esate, patikrinkite tunelius. Ryšys neša du IPsec tunelius dėl pertekliaus, o ryšys, kurio antrasis tunelis niekada nebuvo pakeltas, yra tikras radinys prieinamumo požiūriu, nors šifravimo ribos nekeičia:

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

Patikra 2: ką vidinis paketas dar neša

Kai IPsec baigiasi, AWS persiunčia iškapsuliuotą paketą maršrutu, kuris jam tiko. Nuo to taško srautas yra įprastas VPC srautas, o VPN apsauga baigėsi. Tai ne spraga paslaugoje; tai yra ribos prasmė, o kontrolinio sąrašo punktas yra tai pasakyti aiškiai, o ne leisti „VPN yra užšifruotas“ atstoti „duomenys užšifruoti nuo galo iki galo“.

Dabar išnagrinėkite, kas buvo viduje. Jei vidinis paketas yra atviro teksto programos protokolas, niekas pasroviui neprideda konfidencialumo, kol kas nors kitas jo neužšifruoja. Jei vidinis paketas jau neša TLS sesiją, išorinio IPsec pašalinimas tai sesijai nieko nekeičia: ji lieka apsaugota iki savo galinio taško, kad ir kur tas galinis taškas būtų.

Įprasta per didelė pataisa yra daryti išvadą, kad viskas už vartų yra atskleista. Taip nėra. Paslaugos transportas, saugyklos šifravimas ir programos TLS yra atskiri mechanizmai su atskiromis sąlygomis, ir kiekvienas turi būti vertinamas pagal savo sąlygas, o ne išvedamas iš VPN formos. Srauto žurnalo įrašas su ACCEPT įrodo, kad maršrutizavimas veikė, ir nieko nesako apie konfidencialumą, o tai yra būtent ta klaida, kurios šis kontrolinis sąrašas skirtas išvengti.

Patikra 3: kas užbaigia TLS už vartų

Sekite klausytoją, o ne adresą. Jei apkrovos balansuotojas arba tarpinė užbaigia TLS, jūsų kliento ryšys baigiasi ten, o tarpinė atidaro antrą ryšį su užnugariu, kuris gali būti atviras tekstas arba TLS su kita pasitikėjimo grandine. Privatus IP adresas ir atitinkantis maršrutas nėra to antro ryšio įrodymas.

Išbandykite galinį tašką, kuris jums tikrai svarbus, iš VPC vidaus, su vardu, kurį naudoja programa, o ne su IP, kurį kartą išsprendėte:

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

Pakartokite tai kiekvienam šuoliui, per kurį praeina užklausa. Jei atsakymas skiriasi tarp klientui nukreipto vardo ir užnugario vardo, radote būtent tą segmentą, kurio VPN niekada neapėmė, ir tai yra radinys, kurį reikia užrašyti.

Rezultatą užrašykite kaip segmentus, o ne kaip nuosprendį

Šio kontrolinio sąrašo išvestis yra maža lentelė su viena eilute kiekvienam segmentui: kliento vartai iki AWS VPN tikslo, vartai iki darbo krūvio, darbo krūvis iki duomenų saugyklos ir bet koks tarpinės šuolis tarp jų. Kiekviena eilutė sako, kas ją saugo ir nuo ko ta apsauga priklauso. „Užšifruota“ be mechanizmo ir be galinio taško nėra eilutė.

Tada atsakykite į pradinį reikalavimą tais pačiais terminais, kuriais jis buvo iškeltas. Jei reikalavimas yra, kad duomenys liktų konfidencialūs, kol darbo krūvis juos gaus, VPN tenkina tik pirmą segmentą, o likusioms eilutėms reikia programos transporto, paslaugos TLS arba saugyklos šifravimo, sukonfigūruotų ir patikrintų atskirai.

Saugokite ryšio identifikatorius, tunelių būsenas ir sertifikatų subjektus įraše. Kai kas nors po pusės metų grįš prie dizaino, tie trys artefaktai per minutes atsakys į ribos klausimą, o ne pradės ginčą iš naujo nuo diagramos.