AWS Client VPN eller Site-to-Site: sjekk kven som opnar sambandet

Fire kontrollar avgjer dette, og ingen av dei er namnet på protokollen. Kven som opnar sambandet, kva AWS autentiserer, korleis sambandet vert knytt til nettet ditt, og kva ruting og policy som fylgjer med. Svar på dei i rekkjefylgje, og produktvalet gjer seg vanlegvis sjølv; svar etter at du alt har kjøpt eit design, og du endar med å forsvare ein tunnel som løyser feil helvta av problemet. Ingen av dei fire ber deg velje eit chiffersystem, og difor er eit protokoll-fyrst-design vanlegvis eit teikn på at krava aldri vart skrivne ned.

Køyr kvar kontroll mot det faktiske endepunktet, klienten og den adressefamilien du planlegg å bruke, ikkje mot kategorien. Styrte VPN-produkt skil seg frå OpenVPN- og IPsec-byggjeklossane dei liknar på.

Fyrst, kven opnar sambandet

Viss det som treng tilgang er ei berbar datamaskin, ein telefon eller arbeidsstasjonen til ein administrator, startar sambandet på ei fjermeining, og designet er fjernklienttilgang. Viss det som treng tilgang er ein filial full av maskinar bak ein ruter, startar sambandet på den ruteren, og designet er gateway-til-gateway. Dette er kontrollen som avgjer dei fleste tilfella, og det er den folk hoppar over når ein leverandørpresentasjon alt har ramma inn samtalen rundt chiffersystem.

Stopp her viss du ikkje kan namngje komponenten som initierer. Eit design som prøver å tene båe tilfella med ein tunnel, endar vanlegvis med ein klientøkt som gir seg ut for å vere ein gateway.

Deretter, kva AWS autentiserer

Med Client VPN autentiserer AWS den konfigurerte klient- eller brukaridentiteten: sertifikat, ein katalog eller ein føderert identitet, avhengig av oppsettet. Med Site-to-Site VPN autentiserer AWS identiteten til gateway-partnaren. Den skilnaden er ikkje kosmetisk. Den eine modellen skalerer ved å leggje til brukarar og trekkje attende legitimasjonen deira; den andre skalerer ved å stole på alt som står bak ein einaste gateway.

Gateway-autentisering autentiserer ikkje kvar tilsett eller kvar applikasjon bak han, så hald applikasjonsidentitetar og tilgang på ressursnivå oppe sjølv når sjølve tunnelen er tiltrudd. Ein filial der ruteren har ein gyldig partnaridentitet, bør ikkje automatisk lesast som om kvar pult i den bygningen er autorisert.

For det tredje, korleis sambandet vert knytt til

Client VPN vert knytt til via VPC-subnett-tildelingar eller ei støtta direkte Transit Gateway-tilknyting. Site-to-Site VPN vert knytt til eit AWS VPN-mål, vanlegvis ein virtuell privat gateway eller ein Transit Gateway. Client VPN-arkitekturrettleiinga dokumenterer Transit Gateway-alternativet, og at det finst gjer ikkje ei berbar datamaskin-økt om til ein filialgateway eller fjernar klientautentiseringa og autorisasjonen som er skildra ovanfor.

Kontroller tilknytinga som kontoen og regionen din faktisk støttar før du designar ruter rundt henne, og kontroller deretter kven som eig den tilknytinga. Eit alternativ som finst i dokumentasjonen, men ligg på eit nett du ikkje kan konfigurere, er ikkje eit alternativ.

For det fjerde, kva ruting og policy som fylgjer med

Client VPN gir klienttilknytingsstyring og autorisasjonsreglar for dei målretta netta du tillèt. Ein tilknytt brukar treng framleis den tiltenkte ruta til endepunktet, ein autorisasjonsregel som tillèt henne, og den tilgangen ressursen sjølv krev. Site-to-Site VPN rutar mellom nett som er representerte av ein kundegateway, ved hjelp av støtta statiske ruter eller BGP avhengig av designet, så individuelle maskinar bak filialruteren treng ikkje kvar si klientinnlogging.

Ikkje utleie ikkje-støtta åtferd frå kategorien i noka retning. Fjernåtkomst-VPN er ikkje universelt ute av stand til å bere returtrafikk eller støtte gateway-oppsett, og IPsec vert ikkje automatisk blokkert av NAT — AWS dokumenterer NAT-traversering og krav til kundegateway, og den støtta gateway-konfigurasjonen er den reelle avgrensinga. Kontroller avgrensingane for endepunktet ditt før du krev samband som vert starta mot klientar, eller videresender eit LAN bak ei økt. Same varsemd gjeld adressefamiliar: eit endepunkt som fungerer over IPv4 tyder ikkje på ei IPv6-rute, så stadfest familien klienten eller gatewayen din faktisk vil forhandle om.

Site-to-Site VPN gir deg to tunnelar per samband, og den redundansen er ei designoppgåve snarare enn ein funksjon du kan ta for gitt. Drift av kundegateway, rute-failover og testdekning må alle planleggjast; å samanlikne éi berbar datamaskin-økt med ein abstrakt VPN-tenar beviser ingenting om nokon av dei.

Der dei to designa møtest

Tenestene utelukkar ikkje kvarandre, og den vanlege produksjonsforma brukar båe: tilsette på Client VPN, filialnett på Site-to-Site, med eksplisitte ruter og tilgangspolicy mellom måla som må snakke saman. Tabellen er ei oppsummering av dei fire kontrollane, ikkje ei erstatning for å utføre dei.

Éin ting ingen av dei to produkta erstattar: TLS til ein applikasjon der krypteringskravet strekkjer seg utover VPN-endepunktet. Viss samsvarsomfanget ditt sluttar ved applikasjonen, er tunnelen transport og sertifikatet er framleis kontrollen.

Skriv ned dei fire svara før designgjennomgangen, eitt på kvar linje. Når to av dei er usamde — til dømes eit brukarautentisert klientdesign med eit rutekrav på filialstorleik — er den usemda funnet, og det er billegare å sjå det no enn under overgangen.