AWS Client VPN sau Site-to-Site: verificați cine deschide conexiunea

Patru verificări decid acest lucru și niciuna dintre ele nu este numele protocolului. Cine deschide conexiunea, ce autentifică AWS, cum se atașează conexiunea la rețeaua dumneavoastră și ce rutare și politică vin cu ea. Răspundeți în ordine și alegerea produsului se face de obicei singură; răspundeți după ce ați cumpărat deja un proiect și veți apăra un tunel care rezolvă jumătatea greșită a problemei. Niciuna dintre cele patru nu vă cere să alegeți un cifru, motiv pentru care un proiect care începe cu protocolul este de obicei semnul că cerințele nu au fost niciodată scrise.

Efectuați fiecare verificare față de punctul final, clientul și familia de adrese pe care intenționați să le folosiți, nu față de categorie. Produsele VPN gestionate diferă de blocurile OpenVPN și IPsec cu care seamănă.

În primul rând, cine deschide conexiunea

Dacă lucrul care are nevoie de acces este un laptop, un telefon sau stația de lucru a unui singur administrator, conexiunea începe pe un dispozitiv aflat la distanță, iar proiectul este acces la distanță pentru clienți. Dacă lucrul care are nevoie de acces este o filială plină de mașini în spatele unui singur router, conexiunea începe pe acel router, iar proiectul este gateway-la-gateway. Aceasta este verificarea care rezolvă majoritatea cazurilor și este cea pe care oamenii o sar atunci când prezentarea unui furnizor a încadrat deja discuția în jurul cifrurilor.

Opriți-vă aici dacă nu puteți numi componenta care inițiază. Un proiect care încearcă să servească ambele cazuri cu un singur tunel se termină de obicei cu o sesiune de client care se dă drept gateway.

În al doilea rând, ce autentifică AWS

Cu Client VPN, AWS autentifică identitatea de client sau de utilizator configurată: certificate, un director sau o identitate federată, în funcție de configurare. Cu Site-to-Site VPN, AWS autentifică identitatea partenerului gateway-ului. Această diferență nu este cosmetică. Un model se scalează adăugând utilizatori și revocându-le acreditările; celălalt se scalează încrezându-se în tot ce stă în spatele unui singur gateway.

Autentificarea gateway-ului nu autentifică fiecare angajat sau aplicație din spatele lui, așa că păstrați identitățile aplicațiilor și accesul la nivel de resursă chiar și atunci când tunelul însuși este de încredere. O filială al cărei router are o identitate de partener validă nu trebuie citită automat ca și cum fiecare birou din acea clădire ar fi autorizat.

În al treilea rând, cum se atașează conexiunea

Client VPN se atașează prin asocieri de subrețea VPC sau printr-o conexiune directă la Transit Gateway acceptată. Site-to-Site VPN se atașează la o țintă AWS VPN, de obicei un gateway privat virtual sau un Transit Gateway. Ghidul de arhitectură Client VPN documentează opțiunea Transit Gateway, iar existența ei nu transformă o sesiune de laptop într-un gateway de filială și nu elimină autentificarea și autorizarea clientului descrise mai sus.

Verificați atașarea pe care contul și regiunea dumneavoastră o acceptă cu adevărat înainte de a proiecta rute în jurul ei, apoi verificați cui aparține acea atașare. O opțiune care există în documentație dar se află într-o rețea pe care nu o puteți configura nu este o opțiune.

În al patrulea rând, ce rutare și politică vin cu ea

Client VPN aduce gestionarea conexiunilor clienților și reguli de autorizare pentru rețelele de destinație pe care le permiteți. Un utilizator conectat are în continuare nevoie de ruta prevăzută către punctul final, de o regulă de autorizare care o permite și de accesul pe care îl cere resursa însăși. Site-to-Site VPN rutează între rețele reprezentate de un gateway de client, folosind rute statice acceptate sau BGP în funcție de proiect, astfel încât mașinile individuale din spatele routerului filialei nu au fiecare nevoie de autentificare ca client.

Nu deduceți comportament neacceptat din categorie în nicio direcție. VPN-urile de acces la distanță nu sunt incapabile în mod universal să transporte trafic de retur sau să susțină aranjamente cu gateway, iar IPsec nu este blocat automat de NAT — AWS documentează traversarea NAT și cerințele pentru gateway-ul de client, iar constrângerea reală este configurația de gateway acceptată. Verificați restricțiile pentru punctul final înainte de a cere conexiuni inițiate către clienți sau de a redirecționa un LAN în spatele unei sesiuni. Aceeași prudență se aplică familiilor de adrese: un punct final care funcționează peste IPv4 nu implică o cale IPv6, așa că confirmați familia pe care clientul sau gateway-ul dumneavoastră o va negocia efectiv.

Site-to-Site VPN vă oferă două tuneluri pe conexiune, iar această redundanță este o sarcină de proiectare și nu o funcție pe care o puteți presupune. Operarea gateway-ului de client, comutarea rutelor la defecțiune și acoperirea testelor trebuie toate planificate; compararea unei sesiuni de laptop cu un server VPN abstract nu demonstrează nimic despre niciuna dintre ele.

Unde se întâlnesc cele două proiecte

Serviciile nu se exclud, iar forma obișnuită de producție le folosește pe amândouă: angajați pe Client VPN, rețelele filialelor pe Site-to-Site, cu rute explicite și politică de acces între destinațiile care trebuie să comunice. Tabelul este o recapitulare a celor patru verificări, nu un substitut pentru efectuarea lor.

Un lucru pe care niciunul dintre cele două produse nu îl înlocuiește: TLS către o aplicație a cărei cerință de criptare depășește punctul final VPN. Dacă domeniul dumneavoastră de conformitate se termină la aplicație, tunelul este transport, iar certificatul rămâne controlul.

Scrieți cele patru răspunsuri înainte de revizuirea proiectului, câte o linie fiecare. Când două dintre ele nu sunt de acord — să zicem, un proiect de client autentificat pe utilizator cu o cerință de rutare de dimensiunea unei filiale — acea nepotrivire este constatarea, și este mai ieftin să o vedeți acum decât în timpul tranziției.