AWS Client VPN o Site-to-Site: comproveu qui obre la connexió

Quatre comprovacions ho decideixen, i cap d'elles no és el nom del protocol. Qui obre la connexió, què autentica AWS, com s'adjunta la connexió a la vostra xarxa i quin encaminament i quina política hi van associats. Responeu-ho per ordre i la tria de producte normalment es fa tota sola; responeu-ho després d'haver comprat un disseny i acabareu defensant un túnel que resol la meitat equivocada del problema. Cap de les quatre us demana triar un xifratge, i per això un disseny que comença pel protocol sol ser senyal que els requisits no es van escriure mai.

Feu cada comprovació contra el punt final, el client i la família d'adreces que realment pensau utilitzar, no contra la categoria. Els productes VPN gestionats difereixen dels blocs de construcció OpenVPN i IPsec als quals s'assemblen.

Primer, qui obre la connexió

Si allò que necessita accés és un portàtil, un telèfon o l'estació de treball d'un sol administrador, la connexió comença en un dispositiu remot i el disseny és accés de client remot. Si allò que necessita accés és una branca plena de màquines darrere d'un sol encaminador, la connexió comença en aquest encaminador i el disseny és passarel·la a passarel·la. Aquesta és la comprovació que resol la majoria de casos, i és la que la gent omet quan la presentació d'un proveïdor ja ha emmarcat la conversa al voltant de xifratges.

Atureu-vos aquí si no podeu anomenar el component que inicia. Un disseny que intenta servir tots dos casos amb un sol túnel sol acabar amb una sessió de client que es fa passar per una passarel·la.

Segon, què autentica AWS

Amb Client VPN, AWS autentica la identitat de client o d'usuari configurada: certificats, un directori o una identitat federada, segons la configuració. Amb Site-to-Site VPN, AWS autentica la identitat de l'igual de la passarel·la. Aquesta diferència no és estètica. Un model escala afegint usuaris i revocant-ne les credencials; l'altre escala confiant en tot el que hi ha darrere d'una sola passarel·la.

L'autenticació de la passarel·la no autentica cada empleat ni cada aplicació que hi ha darrere, així que manteniu les identitats d'aplicació i l'accés a nivell de recurs fins i tot quan el túnel mateix sigui de confiança. Una branca l'encaminador de la qual té una identitat d'igual vàlida no s'ha de llegir automàticament com si cada taula d'aquell edifici estigués autoritzada.

Tercer, com s'adjunta la connexió

Client VPN s'adjunta mitjançant associacions de subxarxa de VPC o una connexió directa a Transit Gateway admesa. Site-to-Site VPN s'adjunta a un objectiu d'AWS VPN, habitualment una passarel·la privada virtual o una Transit Gateway. La guia d'arquitectura de Client VPN documenta l'opció de Transit Gateway, i la seva existència no converteix una sessió de portàtil en una passarel·la de branca ni elimina l'autenticació i l'autorització de client descrites més amunt.

Comproveu l'adjunció que el vostre compte i la vostra regió realment admeten abans de dissenyar-hi rutes al voltant, i després comproveu de qui és aquesta adjunció. Una opció que existeix a la documentació però que es troba en una xarxa que no podeu configurar no és una opció.

Quart, quin encaminament i quina política hi van associats

Client VPN aporta gestió de connexions de client i regles d'autorització per a les xarxes de destinació que permeteu. Un usuari connectat encara necessita la ruta prevista fins al punt final, una regla d'autorització que la permeti i l'accés que el recurs mateix requereixi. Site-to-Site VPN encamina entre xarxes representades per una passarel·la de client, fent servir rutes estàtiques admeses o BGP segons el disseny, de manera que les màquines individuals darrere de l'encaminador de branca no necessiten cadascuna un inici de sessió de client.

No inferiu comportament no admès a partir de la categoria en cap direcció. Les VPN d'accés remot no són universalment incapaces de portar trànsit de retorn ni de suportar disposicions de passarel·la, i IPsec no queda bloquejat automàticament pel NAT — AWS documenta el travessament de NAT i els requisits de passarel·la de client, i la configuració de passarel·la admesa és la restricció real. Comproveu les restriccions del vostre punt final abans d'exigir connexions iniciades cap als clients o de reenviar una LAN darrere d'una sessió. La mateixa precaució val per a les famílies d'adreces: un punt final que funciona sobre IPv4 no implica un camí IPv6, així que confirmeu la família que el vostre client o passarel·la negociarà realment.

Site-to-Site VPN us dona dos túnels per connexió, i aquesta redundància és una tasca de disseny més que una funció que pugueu donar per feta. L'operació de la passarel·la de client, la commutació per error de rutes i la cobertura de proves s'han de planificar; comparar una sessió de portàtil amb un servidor VPN abstracte no demostra res sobre cap dels dos.

On es troben els dos dissenys

Els serveis no són excloents, i la forma de producció habitual els fa servir tots dos: empleats a Client VPN, xarxes de branca a Site-to-Site, amb rutes explícites i política d'accés entre les destinacions que han de parlar. La taula és un resum de les quatre comprovacions, no un substitut de fer-les.

Una cosa que cap dels dos productes substitueix: TLS cap a una aplicació el requisit de xifratge de la qual va més enllà del punt final de la VPN. Si el vostre abast de compliment acaba a l'aplicació, el túnel és transport i el certificat continua sent el control.

Escriviu les quatre respostes abans de la revisió de disseny, una línia cadascuna. Quan dues no coincideixen — per exemple, un disseny de client autenticat per usuari amb un requisit d'encaminament de mida de branca — aquesta discrepància és la troballa, i és més barat veure-la ara que durant la migració.