AWS Client VPN eller Site-to-Site: se, hvem der åbner forbindelsen

Fire kontroller afgør dette, og ingen af dem er protokollens navn. Hvem åbner forbindelsen, hvad AWS autentificerer, hvordan forbindelsen knyttes til dit netværk, og hvilken routing og politik der følger med. Besvar dem i rækkefølge, og produktvalget træffer normalt sig selv; besvar dem, efter du har købt et design, og du ender med at forsvare en tunnel, der løser den forkerte halvdel af problemet. Ingen af de fire beder dig vælge en cipher, og derfor er et protokol-først-design normalt et tegn på, at kravene aldrig blev skrevet ned.

Kør hver kontrol mod det faktiske endpoint, den faktiske klient og den adressefamilie, du planlægger at bruge, ikke mod kategorien. Administrerede VPN-produkter adskiller sig fra de OpenVPN- og IPsec-byggeklodser, de ligner.

Først, hvem åbner forbindelsen

Hvis det, der skal have adgang, er en bærbar computer, en telefon eller en enkelt administratorkonto-arbejdsstation, starter forbindelsen på en fjernenhed, og designet er fjernklientadgang. Hvis det, der skal have adgang, er en filial fuld af maskiner bag én router, starter forbindelsen på den router, og designet er gateway-til-gateway. Det er den kontrol, der afgør de fleste sager, og det er den, folk springer over, når en leverandørpræsentation allerede har rammet samtalen ind omkring ciphere.

Stop her, hvis du ikke kan navngive den komponent, der igangsætter. Et design, der forsøger at betjene begge sager med én tunnel, ender normalt med en klientsession, der udgiver sig for at være en gateway.

Dernæst, hvad AWS autentificerer

Med Client VPN autentificerer AWS den konfigurerede klient- eller brugeridentitet: certifikater, en mappe eller en fødereret identitet, afhængigt af opsætningen. Med Site-to-Site VPN autentificerer AWS gateway-peerens identitet. Den forskel er ikke kosmetisk. Den ene model skalerer ved at tilføje brugere og tilbagekalde deres legitimationsoplysninger; den anden skalerer ved at stole på alt, hvad der står bag én gateway.

Gateway-autentificering autentificerer ikke hver medarbejder eller applikation bag den, så behold applikationsidentiteter og adgang på ressourceniveau, selv når selve tunnelen er betroet. En filial, hvis router har en gyldig peer-identitet, bør ikke automatisk læses som om hvert skrivebord i den bygning er autoriseret.

For det tredje, hvordan forbindelsen knyttes

Client VPN knyttes via VPC-undernetstilknytninger eller en understøttet direkte Transit Gateway-tilknytning. Site-to-Site VPN knyttes til et AWS VPN-mål, oftest en virtuel privat gateway eller en Transit Gateway. Client VPN-arkitekturvejledningen dokumenterer Transit Gateway-muligheden, og dens eksistens gør ikke en bærbar session til en filialgateway eller fjerner den klientautentificering og -autorisation, der er beskrevet ovenfor.

Kontroller den tilknytning, som din konto og region faktisk understøtter, før du designer ruter omkring den, og kontroller derefter, hvem der ejer den tilknytning. En mulighed, der findes i dokumentationen, men ligger på et netværk, du ikke kan konfigurere, er ikke en mulighed.

For det fjerde, hvilken routing og politik der følger med

Client VPN bringer klientforbindelsesstyring og autorisationsregler for de destinationsnetværk, du tillader. En tilsluttet bruger har stadig brug for den tilsigtede endpoint-rute, en autorisationsregel, der tillader den, og den adgang, som selve ressourcen kræver. Site-to-Site VPN router mellem netværk repræsenteret af en kundegateway ved hjælp af understøttede statiske ruter eller BGP afhængigt af designet, så individuelle maskiner bag filialrouteren har ikke hver især brug for et klientlogin.

Udled ikke ikke-understøttet adfærd af kategorien i nogen af retningerne. Fjernadgangs-VPN'er er ikke universelt ude af stand til at bære returtrafik eller understøtte gateway-arrangementer, og IPsec blokeres ikke automatisk af NAT — AWS dokumenterer NAT-traversal og kundegateway-krav, og den understøttede gateway-konfiguration er den reelle begrænsning. Kontroller begrænsningerne for dit endpoint, før du kræver forbindelser, der startes mod klienter, eller videresender et LAN bag en enkelt session. Samme forsigtighed gælder for adressefamilier: et endpoint, der virker over IPv4, indebærer ikke en IPv6-rute, så bekræft den familie, din klient eller gateway faktisk vil forhandle.

Site-to-Site VPN giver dig to tunneler per forbindelse, og den redundans er en designopgave snarere end en funktion, du kan tage for givet. Kundegateway-drift, rute-failover og testdækning skal alle planlægges; at sammenligne en bærbar session med en abstrakt VPN-server beviser intet om nogen af dem.

Hvor de to designs mødes

Tjenesterne udelukker ikke hinanden, og den almindelige produktionsform bruger begge: medarbejdere på Client VPN, filialnetværk på Site-to-Site, med eksplicitte ruter og adgangspolitik mellem de destinationer, der skal tale sammen. Tabellen er en opsummering af de fire kontroller, ikke en erstatning for at udføre dem.

Én ting, som ingen af de to produkter erstatter: TLS til en applikation, hvis krypteringskrav rækker ud over VPN-endpointet. Hvis dit compliance-omfang slutter ved applikationen, er tunnelen transport, og certifikatet er stadig kontrollen.

Skriv de fire svar ned før designgennemgangen, ét på hver linje. Når to af dem er uenige — for eksempel et brugerautentificeret klientdesign med et routingkrav i filialstørrelse — er den uenighed fundet, og det er billigere at se det nu end under overgangen.