VGW vai TGW? Mihin AWS Site-to-Site -palvelun IPsec-tunneli päättyy

Ihmiset kysyvät, mihin AWS Site-to-Site VPN lakkaa suojaamasta pakettia, ja odottavat yhtä vastausta: yhdyskäytävään. Sen vastauksen hyödyllinen versio nimeää, mikä yhdyskäytävä, koska virtuaalinen yksityinen yhdyskäytävä ja siirtoverkon yhdyskäytävä ovat erilaisia järjestelyjä, joilla on erilaiset liitokset, ja arvioija, joka olettaa väärän, rakentaa loppuarvion kartalle, jota ei ole olemassa. Käy kolme alla olevaa tarkistusta järjestyksessä. Jokainen joko vahvistaa rajan tai kertoo, että edellinen vastaus koski toista resurssia.

Nimeä kolme päätepistettä ennen kuin arvioit mitään

Tämän polun salauskatsaus tarvitsee kolme nimettyä asiaa: asiakasyhdyskäytävän, AWS VPN -kohteen, joka päättää IPsecin, ja sovelluksen päätepisteen, joka vastaanottaa sisäpaketin. Kirjoita ne resurssitunnuksineen ennen kuin avaat yhtäkään konsolisivua, sillä kaikki tämän pisteen jälkeen on väite yhdestä noista kolmesta.

Asiakasyhdyskäytävä on sinun ja sen kokoonpano on nähtävissä sinulle. AWS-kohde on hallittu resurssi, ja virhe on olettaa se: VPN-yhteys voi liittyä virtuaaliseen yksityiseen yhdyskäytävään tai suoraan siirtoverkon yhdyskäytävään, eikä kumpikaan edellytä toista. Kolmas päätepiste on se, jonka ihmiset ohittavat, ja se on ainoa, joka vastaa varsinaiseen kysymykseen sovelluksen tiedoista.

Tarkistus 1: mikä yhdyskäytävä todella päättää tunnelin

Molemmat järjestelyt ovat tuettuja ja Site-to-Site VPN:n arkkitehtuuriopas kuvaa ne rinnakkain, joten kysy API:lta äläkä kartalta, joka on usein vuoden vanha. Yhtä yhteyttä koskeva vain luku -kysely palauttaa VPN-kohteen kentät:

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

Erottava tekijä on TransitGatewayId, ei VpnGatewayId. Yhteys, jonka TransitGatewayId on tyhjä, päättyy erilliseen virtuaaliseen yksityiseen yhdyskäytävään, kun taas yhteys, jossa tämä kenttä on asetettu, päättyy siirtoverkon yhdyskäytävän VPN-liitokseen, ja VpnGatewayId voi silti olla täytetty siinä tapauksessa, koska se voi nimetä liitoksen taustalla olevan yhdyskäytävän. Lue ensin TGW-kenttä ja vahvista sitten liitoksen tyyppi liitosluettelosta eikä kentän nimestä, sillä VPC-liitos tuossa siirtoverkon yhdyskäytävässä ei ole VPN-liitos. Kohdeinstanssin löytäminen liitetystä VPC:stä ei kerro mitään siitä, mikä VPN-liitos paketin kuljetti.

Kun olet siellä, tarkista tunnelit. Yhteys kuljettaa kahta IPsec-tunnelia redundanssin vuoksi, ja yhteys, jonka toinen tunneli ei ole koskaan noussut, on todellinen löydös käytettävyyden kannalta, vaikka se ei muuta salausrajaa mitenkään:

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

Tarkistus 2: mitä sisäpaketti vielä kuljettaa

Kun IPsec päättyy, AWS välittää puretun paketin reitillä, joka siihen sopi. Siitä pisteestä lähtien liikenne on tavallista VPC-liikennettä ja VPN:n suoja on päättynyt. Tämä ei ole palvelun aukko; tämä on rajan merkitys, ja tarkistuslistan kohta on sanoa se selvästi sen sijaan, että antaisi "VPN on salattu" -lauseen korvata "tiedot on salattu päästä päähän".

Tutki nyt, mitä sisällä oli. Jos sisäpaketti on sovellusprotokolla selkokielisenä, mikään alavirrassa ei lisää luottamuksellisuutta ennen kuin jokin muu salaa sen. Jos sisäpaketti kuljettaa jo TLS-istuntoa, ulomman IPsecin poisto ei muuta siinä istunnossa mitään: se pysyy suojattuna omaan päätepisteeseensä asti, missä ikinä se päätepiste onkaan.

Tavallinen ylikorjaus on päätellä, että kaikki yhdyskäytävän takana on paljastettu. Ei ole. Palvelun siirto, tallennuksen salaus ja sovelluksen TLS ovat erillisiä mekanismeja erillisin ehdoin, ja jokainen on arvioitava omilla ehdoillaan eikä pääteltävä VPN:n muodosta. ACCEPT-tilan näyttävä virtaustapahtuma todistaa, että reititys toimi, eikä kerro luottamuksellisuudesta mitään, ja juuri se on virhe, jonka estämiseksi tämä tarkistuslista on olemassa.

Tarkistus 3: mikä päättää TLS:n yhdyskäytävän takana

Seuraa kuuntelijaa, älä osoitetta. Jos kuormantasaaja tai välityspalvelin päättää TLS:n, asiakkaasi pitämä yhteys päättyy siihen, ja välityspalvelin avaa toisen yhteyden taustajärjestelmään, joka voi olla selkokieltä tai TLS toisella luottamisketjulla. Yksityinen IP-osoite ja sopiva reitti eivät ole todiste tuosta toisesta yhteydestä.

Testaa päätepiste, josta todella välität, VPC:n sisältä, sovelluksen käyttämällä nimellä eikä IP:llä, jonka ratkaisit kerran:

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

Toista se jokaiselle hypylle, jonka pyyntö kulkee. Jos vastaus eroaa asiakkaalle näkyvän nimen ja taustajärjestelmän nimen välillä, olet löytänyt täsmälleen sen segmentin, jota VPN ei koskaan kattanut, ja se on löydös, joka pitää kirjata.

Kirjaa tulos segmentteinä, ei tuomiona

Tämän tarkistuslistan tulos on pieni taulukko, jossa on yksi rivi segmenttiä kohden: asiakasyhdyskäytävästä AWS VPN -kohteeseen, yhdyskäytävästä työkuormaan, työkuormasta tietovarastoon ja mikä tahansa välityspalvelinhyppy niiden välissä. Jokainen rivi kertoo, mikä sitä suojaa ja mistä se suoja riippuu. "Salattu" ilman mekanismia ja ilman päätepistettä ei ole rivi.

Vastaa sitten alkuperäiseen vaatimukseen samoilla termeillä, joilla se esitettiin. Jos vaatimus on, että tiedot pysyvät luottamuksellisina siihen asti, että työkuorma vastaanottaa ne, VPN täyttää vain ensimmäisen segmentin, ja jäljellä olevat rivit tarvitsevat sovelluksen siirron, palvelun TLS:n tai tallennuksen salauksen erikseen määritettynä ja vahvistettuna.

Pidä yhteystunnukset, tunnelien tilat ja varmenteiden subjektit kirjauksessa. Kun joku palaa suunnitelmaan kuuden kuukauden kuluttua, nuo kolme artefaktia vastaavat rajaksymykseen minuuteissa sen sijaan, että väittely aloitettaisiin uudelleen kartalta.