AWS Client VPN eller Site-to-Site: sjekk hvem som åpner forbindelsen

Fire kontroller avgjør dette, og ingen av dem er protokollens navn. Hvem som åpner forbindelsen, hva AWS autentiserer, hvordan forbindelsen kobles til nettverket ditt, og hvilken ruting og policy som følger med. Svar på dem i rekkefølge, og produktvalget tar seg vanligvis selv; svar etter at du allerede har kjøpt et design, og du ender med å forsvare en tunnel som løser feil halvdel av problemet. Ingen av de fire ber deg velge en cipher, og derfor er et protokoll-først-design vanligvis et tegn på at kravene aldri ble skrevet ned.

Kjør hver kontroll mot det faktiske endepunktet, klienten og adressefamilien du planlegger å bruke, ikke mot kategorien. Administrerte VPN-produkter er forskjellige fra OpenVPN- og IPsec-byggeklossene de ligner på.

Først, hvem åpner forbindelsen

Hvis det som trenger tilgang er en laptop, en telefon eller arbeidsstasjonen til én administrator, starter forbindelsen på en fjernenhet, og designet er fjernklienttilgang. Hvis det som trenger tilgang er en filial full av maskiner bak én ruter, starter forbindelsen på den ruteren, og designet er gateway-til-gateway. Dette er kontrollen som avgjør de fleste tilfellene, og det er den folk hopper over når en leverandørpresentasjon allerede har rammet inn samtalen rundt ciphere.

Stopp her hvis du ikke kan navngi komponenten som initierer. Et design som prøver å betjene begge tilfellene med én tunnel, ender vanligvis med en klientsesjon som utgir seg for å være en gateway.

Deretter, hva AWS autentiserer

Med Client VPN autentiserer AWS den konfigurerte klient- eller brukeridentiteten: sertifikater, en katalog eller en føderert identitet, avhengig av oppsettet. Med Site-to-Site VPN autentiserer AWS gateway-peerens identitet. Den forskjellen er ikke kosmetisk. Den ene modellen skalerer ved å legge til brukere og tilbakekalle legitimasjonen deres; den andre skalerer ved å stole på alt som står bak én gateway.

Gateway-autentisering autentiserer ikke hver ansatt eller applikasjon bak den, så behold applikasjonsidentiteter og tilgang på ressursnivå selv når selve tunnelen er betrodd. En filial der ruteren har en gyldig peer-identitet, bør ikke automatisk leses som om hver pult i den bygningen er autorisert.

For det tredje, hvordan forbindelsen kobles til

Client VPN kobles til via VPC-subnettilordninger eller en støttet direkte Transit Gateway-tilkobling. Site-to-Site VPN kobles til et AWS VPN-mål, vanligvis en virtuell privat gateway eller en Transit Gateway. Client VPN-arkitekturveiledningen dokumenterer Transit Gateway-alternativet, og at det finnes gjør ikke en laptopsesjon til en filialgateway eller fjerner klientautentiseringen og autorisasjonen beskrevet ovenfor.

Kontroller tilkoblingen kontoen og regionen din faktisk støtter før du designer ruter rundt den, og kontroller deretter hvem som eier den tilkoblingen. Et alternativ som finnes i dokumentasjonen, men ligger på et nettverk du ikke kan konfigurere, er ikke et alternativ.

For det fjerde, hvilken ruting og policy som følger med

Client VPN gir klienttilkoblingsstyring og autorisasjonsregler for destinasjonsnettverkene du tillater. En tilkoblet bruker trenger fortsatt den tiltenkte ruten til endepunktet, en autorisasjonsregel som tillater den, og den tilgangen ressursen selv krever. Site-to-Site VPN ruter mellom nettverk representert av en kundegateway, ved hjelp av støttede statiske ruter eller BGP avhengig av designet, så individuelle maskiner bak filialruteren trenger ikke hver sin klientpålogging.

Ikke utled ikke-støttet atferd fra kategorien i noen retning. Fjern tilgang-VPN-er er ikke universelt ute av stand til å bære returtrafikk eller støtte gateway-oppsett, og IPsec blokkeres ikke automatisk av NAT — AWS dokumenterer NAT-traversering og kundegateway-krav, og den støttede gateway-konfigurasjonen er den reelle begrensningen. Kontroller begrensningene for endepunktet ditt før du krever forbindelser som startes mot klienter, eller videresender et LAN bak én sesjon. Samme forsiktighet gjelder adressefamilier: et endepunkt som fungerer over IPv4 innebærer ikke en IPv6-rute, så bekreft familien klienten eller gatewayen din faktisk vil forhandle om.

Site-to-Site VPN gir deg to tunneler per forbindelse, og den redundansen er en designoppgave snarere enn en funksjon du kan ta for gitt. Kundegateway-drift, rute-failover og testdekning må alle planlegges; å sammenligne én laptopsesjon med en abstrakt VPN-server beviser ingenting om noen av dem.

Der de to designene møtes

Tjenestene utelukker ikke hverandre, og den vanlige produksjonsformen bruker begge: ansatte på Client VPN, filialnettverk på Site-to-Site, med eksplisitte ruter og tilgangspolicy mellom destinasjonene som må snakke sammen. Tabellen er en oppsummering av de fire kontrollene, ikke en erstatning for å utføre dem.

Én ting ingen av de to produktene erstatter: TLS til en applikasjon der krypteringskravet strekker seg utover VPN-endepunktet. Hvis samsvarsomfanget ditt slutter ved applikasjonen, er tunnelen transport og sertifikatet er fortsatt kontrollen.

Skriv ned de fire svarene før designgjennomgangen, ett på hver linje. Når to av dem er uenige — for eksempel et brukerautentisert klientdesign med et rutebehov på filialstørrelse — er den uenigheten funnet, og det er billigere å se det nå enn under overgangen.