AWS Client VPN aŭ Site-to-Site: kontrolu, kiu malfermas la konekton

Kvar kontroloj decidas tion, kaj neniu el ili estas la nomo de la protokolo. Kiu malfermas la konekton, kion AWS aŭtentikigas, kiel la konekto aliĝas al via reto, kaj kiuj enkursigado kaj politiko venas kun ĝi. Respondu ĉi tion laŭorde kaj la produkta elekto kutime faras sin mem; respondu poste, post kiam vi jam aĉetis dezajnon, kaj vi finos defendante tunelon, kiu solvas la malĝustan duonon de la problemo. Neniu el la kvar petas ke vi elektu ĉifron, kaj tial protokolo-unua dezajno kutime estas signo, ke la postuloj neniam estis skribitaj.

Faru ĉiun kontrolon kontraŭ la fakta finpunkto, kliento kaj adresfamilio, kiujn vi planas uzi, ne kontraŭ la kategorio. Administrataj VPN-produktoj diferencas de la konstruaj blokoj OpenVPN kaj IPsec, kiujn ili similas.

Unue, kiu malfermas la konekton

Se tio, kio bezonas aliron, estas tekkomputilo, telefono aŭ labortablo de unu administranto, la konekto komenciĝas ĉe fora aparato kaj la dezajno estas fora klienta aliro. Se tio, kio bezonas aliron, estas filio plena de maŝinoj malantaŭ unu enkursigilo, la konekto komenciĝas ĉe tiu enkursigilo kaj la dezajno estas enirejo-al-enirejo. Ĉi tiu estas la kontrolo, kiu solvas plej multajn kazojn, kaj ĝi estas tiu, kiun homoj preterlasas kiam la prezento de vendisto jam kadrigis la interparolon ĉirkaŭ ĉifroj.

Haltu ĉi tie, se vi ne povas nomi la komponanton, kiu komencigas. Dezajno, kiu provas servi ambaŭ kazojn per unu tunelo, kutime finiĝas per klienta seanco, kiu ŝajnigas esti enirejo.

Due, kion AWS aŭtentikigas

Kun Client VPN, AWS aŭtentikigas la agorditan klientan aŭ uzantan identecon: atestilojn, dosierujon aŭ federitan identecon, laŭ la agordo. Kun Site-to-Site VPN, AWS aŭtentikigas la identecon de la enireja kunulo. Tiu diferenco ne estas kosmetika. Unu modelo skaliĝas aldonante uzantojn kaj revokante iliajn akreditaĵojn; la alia skaliĝas fidante ĉion, kio staras malantaŭ unu enirejo.

Enireja aŭtentikigo ne aŭtentikigas ĉiun dungiton aŭ aplikaĵon malantaŭ ĝi, do konservu aplikaĵajn identecojn kaj aliron je rimeda nivelo eĉ kiam la tunelo mem estas fidata. Filio, kies enkursigilo posedas validan kunulan identecon, ne devus aŭtomate legiĝi kvazaŭ ĉiu labortablo en tiu konstruaĵo estus rajtigita.

Trie, kiel la konekto aliĝas

Client VPN aliĝas per VPC-subretaj asocioj aŭ per subtenata rekta Transit Gateway-aliĝo. Site-to-Site VPN aliĝas al AWS VPN-celo, kutime virtuala privata enirejo aŭ Transit Gateway. La arkitektura gvidilo de Client VPN dokumentas la opcion Transit Gateway, kaj ĝia ekzisto ne transformas tekkomputilan seancon en filian enirejon nek forigas la klientan aŭtentikigon kaj rajtigon priskribitajn supre.

Kontrolu la aliĝon, kiun via konto kaj regiono fakte subtenas, antaŭ ol dezajni enkursigojn ĉirkaŭ ĝi, poste kontrolu, kiu posedas tiun aliĝon. Opcio, kiu ekzistas en la dokumentaro sed sidas en reto, kiun vi ne povas agordi, ne estas opcio.

Kvare, kiuj enkursigado kaj politiko venas kun ĝi

Client VPN alportas klientan konektadministradon kaj rajtigajn regulojn por la celretoj, kiujn vi permesas. Konektita uzanto ankoraŭ bezonas la celitan enkursigon al la finpunkto, rajtigan regulon, kiu permesas ĝin, kaj kiun ajn aliron la rimedo mem postulas. Site-to-Site VPN enkursigas inter retoj reprezentataj de klienta enirejo, uzante subtenatajn statikajn enkursigojn aŭ BGP laŭ la dezajno, do unuopaj maŝinoj malantaŭ la filia enkursigilo ne bezonas ĉiu sian klientan ensaluton.

Ne deduktu nesubtenatan konduton el la kategorio en ajna direkto. Foraj aliraj VPN-oj ne estas universe nekapablaj porti revenan trafikon aŭ subteni enirejajn aranĝojn, kaj IPsec ne estas aŭtomate blokata de NAT — AWS dokumentas NAT-trapasadon kaj postulojn pri klienta enirejo, kaj la subtenata enireja agordo estas la reala limigo. Kontrolu la limigojn por via finpunkto antaŭ ol postuli konektojn komencitajn al klientoj aŭ plusendi LAN-on malantaŭ unu seanco. La sama singardo validas por adresfamilioj: finpunkto, kiu funkcias super IPv4, ne implicas IPv6-vojon, do konfirmu la familion, kiun via kliento aŭ enirejo fakte intertraktos.

Site-to-Site VPN donas al vi du tunelojn por konekto, kaj tiu redundo estas dezajna tasko, ne trajto, kiun vi povas supozi. Funkciado de la klienta enirejo, enkursiga malsukcesa transiro kaj testa kovrado ĉiuj devas esti planitaj; kompari unu tekkomputilan seancon kun abstrakta VPN-servilo pruvas nenion pri iu ajn el ili.

Kie la du dezajnoj renkontiĝas

La servoj ne estas ekskluzivaj, kaj la ordinara produkta formo uzas ambaŭ: dungitoj ĉe Client VPN, filiaj retoj ĉe Site-to-Site, kun eksplicitaj enkursigoj kaj alirpolitiko inter la celoj, kiuj devas interparoli. La tabelo estas resumo de la kvar kontroloj, ne anstataŭaĵo por plenumi ilin.

Unu afero, kiun neniu el la du produktoj anstataŭas: TLS al aplikaĵo, kies ĉifrada postulo etendiĝas preter la VPN-finpunkto. Se via konformiga amplekso finiĝas ĉe la aplikaĵo, la tunelo estas transporto kaj la atestilo restas la kontrolo.

Skribu la kvar respondojn antaŭ la dezajna revizio, unu linion ĉiu. Kiam du el ili malkonsentas — ekzemple, uzanto-aŭtentikigita klienta dezajno kun enkursiga postulo filigranda — tiu malkonsento estas la trovajo, kaj estas pli malmultekoste vidi ĝin nun ol dum la transiro.