AWS Client VPN vai Site-to-Site: tarkista, kuka avaa yhteyden

Neljä tarkistusta ratkaisevat tämän, eikä mikään niistä ole protokollan nimi. Kuka avaa yhteyden, mitä AWS todentaa, miten yhteys liittyy verkkoosi ja mitä reititystä ja käytäntöä sen mukana tulee. Vastaa näihin järjestyksessä, niin tuotevalinta tekee itsensä yleensä; vastaa vasta kun olet jo ostanut suunnittelun, niin puolustat tunnelia, joka ratkaisee ongelman väärän puoliskon. Mikään neljästä ei pyydä sinua valitsemaan salausta, minkä vuoksi protokollasta alkava suunnittelu on yleensä merkki siitä, ettei vaatimuksia koskaan kirjoitettu.

Tee jokainen tarkistus sitä todellista päätepistettä, asiakasta ja osoiteperhettä vasten, jota aiot käyttää, älä kategoriaa vasten. Hallinnoidut VPN-tuotteet eroavat niistä OpenVPN- ja IPsec-rakennuspalikoista, joita ne muistuttavat.

Ensiksi, kuka avaa yhteyden

Jos pääsyä tarvitseva asia on kannettava, puhelin tai yhden ylläpitäjän työasema, yhteys alkaa etälaitteesta ja suunnittelu on etäasiakaskäyttöä. Jos pääsyä tarvitseva asia on yhden reitittimen takana olevista koneista täynnä oleva sivukonttori, yhteys alkaa siitä reitittimestä ja suunnittelu on yhdyskäytävä-yhdyskäytävälle. Tämä on tarkistus, joka ratkaisee useimmat tapaukset, ja juuri sen ihmiset ohittavat, kun toimittajan esitys on jo kehystänyt keskustelun salausten ympärille.

Pysähdy tähän, jos et pysty nimeämään komponenttia, joka käynnistää yhteyden. Suunnittelu, joka yrittää palvella molempia tapauksia yhdellä tunnelilla, päätyy yleensä asiakasistuntoon, joka esittää olevansa yhdyskäytävä.

Toiseksi, mitä AWS todentaa

Client VPN:ssä AWS todentaa määritetyn asiakas- tai käyttäjätunnisteen: varmenteet, hakemiston tai liitetyn identiteetin kokoonpanosta riippuen. Site-to-Site VPN:ssä AWS todentaa yhdyskäytävän vastapuolen identiteetin. Tämä ero ei ole kosmeettinen. Toinen malli skaalautuu lisäämällä käyttäjiä ja peruuttamalla heidän tunnuksensa; toinen skaalautuu luottamalla kaikkeen, mikä on yhden yhdyskäytävän takana.

Yhdyskäytävän todentaminen ei todista sen takana olevia työntekijöitä tai sovelluksia, joten pidä sovellusten identiteetit ja resurssitason käyttöoikeudet voimassa, vaikka tunnelia itseään pidettäisiin luotettuna. Sivukonttoria, jonka reitittimellä on kelvollinen vastapuoli-identiteetti, ei pitäisi automaattisesti lukea niin, että jokainen sen rakennuksen työpöytä on valtuutettu.

Kolmanneksi, miten yhteys liittyy

Client VPN liittyy VPC-aliverkkoliitosten tai tuetun suoran Transit Gateway -liitoksen kautta. Site-to-Site VPN liittyy AWS VPN -kohteeseen, tavallisesti virtuaaliseen yksityiseen yhdyskäytävään tai Transit Gateway -yhdyskäytävään. Client VPN:n arkkitehtuuriohje dokumentoi Transit Gateway -vaihtoehdon, eikä sen olemassaolo muuta kannettavan istuntoa sivukonttorin yhdyskäytäväksi tai poista edellä kuvattua asiakkaan todentamista ja valtuutusta.

Tarkista liitos, jota tilisi ja alueesi todella tukevat, ennen kuin suunnittelet reitit sen ympärille, ja tarkista sitten, kuka omistaa liitoksen. Vaihtoehto, joka on dokumentaatiossa mutta sijaitsee verkossa, jota et voi määrittää, ei ole vaihtoehto.

Neljänneksi, mitä reititystä ja käytäntöä sen mukana tulee

Client VPN tuo asiakasyhteyksien hallinnan ja valtuutussäännöt niille kohdeverkoille, jotka sallit. Yhdistetyllä käyttäjällä on edelleen oltava aiottu reitti päätepisteeseen, sen salliva valtuutussääntö ja se käyttöoikeus, jota itse resurssi vaatii. Site-to-Site VPN reitittää asiakasyhdyskäytävän edustamien verkkojen välillä käyttäen tuettuja staattisia reittejä tai BGP:tä suunnittelusta riippuen, joten sivukonttorin reitittimen takana olevat yksittäiset koneet eivät tarvitse kukin omaa asiakaskirjautumista.

Älä päättele kategorian tukematonta käyttäytymistä kumpaankaan suuntaan. Etäkäyttö-VPN:t eivät ole yleisesti kyvyttömiä kuljettamaan paluuliikennettä tai tukemaan yhdyskäytäväjärjestelyitä, eikä IPsec:tä estä automaattisesti NAT — AWS dokumentoi NAT-läpäisyn ja asiakasyhdyskäytävän vaatimukset, ja todellinen rajoite on tuettu yhdyskäytäväkokoonpano. Tarkista päätepisteesi rajoitukset ennen kuin vaadit asiakkaita kohti käynnistettäviä yhteyksiä tai välität LANin yhden istunnon taakse. Sama varovaisuus koskee osoiteperheitä: IPv4:n yli toimiva päätepiste ei tarkoita IPv6-polkua, joten vahvista perhe, josta asiakkaasi tai yhdyskäytäväsi todella neuvottelee.

Site-to-Site VPN antaa kaksi tunnelia yhteyttä kohden, ja se redundanssi on suunnittelutehtävä eikä ominaisuus, jonka voi olettaa. Asiakasyhdyskäytävän toiminta, reittien vikasieto ja testikattavuus on kaikki suunniteltava; yhden kannettavan istunnon vertaaminen abstraktiin VPN-palvelimeen ei todista kummastakaan mitään.

Missä kaksi suunnittelua kohtaavat

Palvelut eivät sulje toisiaan pois, ja tavallinen tuotantomuoto käyttää molempia: työntekijät Client VPN:ssä, sivukonttorien verkot Site-to-Site:ssä, selkeillä reiteillä ja käyttöoikeuskäytännöllä niiden kohteiden välillä, joiden on puhuttava keskenään. Taulukko on neljän tarkistuksen yhteenveto, ei niiden tekemisen sijainen.

Yksi asia, jota kumpikaan tuote ei korvaa: TLS sovellukseen, jonka salausvaatimus ulottuu VPN:n päätepistettä pidemmälle. Jos vaatimustenmukaisuusalueesi päättyy sovellukseen, tunneli on siirtoa ja varmenne on edelleen se valvontakeino.

Kirjoita neljä vastausta ennen suunnittelukatselmusta, kukin yhdelle riville. Kun kaksi niistä on ristiriidassa — sanotaan vaikka käyttäjätodennettu asiakassuunnittelu ja sivukonttorin kokoinen reititysvaatimus —, se ristiriita on löydös, ja se on halvempaa nähdä nyt kuin siirtymän aikana.