EC2 Windows: client VPN, server VPN sau gateway AWS?
O instanță EC2 Windows poate rula software VPN, însă un client, un server administrat intern și un gateway AWS sunt roluri diferite, cu proprietari diferiți.
O echipă are nevoie de conectivitate VPN pentru o aplicație care rulează pe o instanță EC2 Windows, găsește software client compatibil, îl instalează și apoi întreabă de ce restul VPC-ului nu îl poate folosi. Instalarea a funcționat; rolul nu a fost niciodată decis. Software-ul care rulează într-un invitat poate fi un client care se alătură rețelei altcuiva, un server care acceptă alți clienți sau niciunul dintre cele două produse VPN administrate de AWS, iar fiecare rol lasă o muncă diferită în seama dumneavoastră.
Simptomul este de obicei rolul greșit
Simptomul obișnuit este un tunel care funcționează, dar rezolvă problema greșită. Un client din VM îi dă acelei VM o cale de ieșire; nu îi dă laptopului, biroului sau altei subrețele o cale de intrare. Un server din VM le dă celorlalți o cale de intrare, dar acum dumneavoastră dețineți ascultătorul, autentificarea și redirecționarea.
Serviciile administrate mută operarea serviciului la AWS și vă lasă proiectarea. Site-to-Site VPN conectează rețele printr-un gateway de client și un gateway AWS, iar Client VPN le dă dispozitivelor la distanță un punct final administrat. În ambele cazuri, rutele, regulile de autorizare și sursa de identitate sunt configurația dumneavoastră, iar niciunul dintre produse nu instalează un client de uz general într-un invitat Windows.
Sunt posibile patru forme, iar tabelul le separă după ce se conectează cu ce și cine duce sarcina operațională.
| Role | What connects | Who owns the VPN software |
|---|---|---|
| Client in the Windows VM | This VM dials out into someone else's network | You, plus the software vendor |
| Server in the Windows VM | Inbound clients and sites attach to this VM | You, end to end |
| AWS Site-to-Site VPN | Two networks meet through a customer gateway and an AWS gateway | AWS operates the tunnels; you own the peer and route design |
| AWS Client VPN | User devices attach to an endpoint AWS operates | AWS operates it; you own the access rules |
Citiți rândul, nu numele produsului: aceeași instanță Windows poate sta în două rânduri diferite în funcție de software-ul care rulează în ea.
Client în VM: VM-ul se alătură unei rețele
Un client de ieșire trebuie să aibă verificată compilarea Windows, arhitectura și cerințele de driver înainte de a instala ceva. Clientul va schimba rutele și DNS-ul pe instanță, ceea ce poate afecta serviciile care rulează deja acolo, inclusiv calea pe care o folosiți pentru administrarea la distanță. Notați numele adaptorului și metrica de interfață pe care o setează clientul, deoarece noua interfață poate avea prioritate față de cea existentă. Dacă instanța este administrată printr-un manager de sesiuni în loc de SSH sau RDP, confirmați că acea cale încă funcționează după ce clientul se conectează.
Decideți ce trafic trebuie să transporte clientul înainte de a-l activa. Un tunel complet poate captura sesiunea de administrare și vă poate bloca afară, iar un tunel divizat poate lăsa instanța să ajungă la rețeaua privată în timp ce restul traficului iese pe altă cale. Testați cu o a doua cale de administrare disponibilă și notați rutele pe care clientul le instalează, pentru ca o modificare ulterioară să fie explicabilă.
Server în VM: alți clienți i se alătură
Pentru un server administrat intern, dumneavoastră dețineți ascultătorul, certificatul sau materialul cheii, baza de date de utilizatori și regulile de redirecționare. Dacă serverul redirecționează trafic pentru alți clienți, instanța devine un router, iar asta cere redirecționare la nivel de invitat plus modificări de rute și grupuri de securitate la nivel de AWS.
Testați ascultătorul din invitat și din nou din altă subrețea, apoi testați un host către care instanța redirecționează. Un serviciu local sănătos nu dovedește nimic despre calea redirecționată, așa că notați ambele rezultate în nota de modificare.
Gateway-urile administrate păstrează serviciul, nu proiectarea accesului
AWS Site-to-Site VPN documentează rolurile de tunel ale gateway-ului de client și ale gateway-ului AWS, iar cumpărarea acelei conexiuni nu înlocuiește fiecare proiectare de acces la distanță. Client VPN documentează un punct final administrat cu persoane de client, în timp ce regulile de autorizare și rutele țintă rămân ale dumneavoastră. AWS ține punctul final și certificatele lui în funcțiune; cine poate ajunge la ce aplicație rămâne o regulă de autorizare pe care o scrieți și o întrețineți.
Alegeți între produse pe cinci axe: ce rol joacă fiecare, ce protocoale acceptă, ce sursă de identitate așteaptă, cum este redirecționat traficul și cum este livrată disponibilitatea. Ignorați orice cifră unică de debit citată într-un fir de forum, deoarece capacitatea publicată se mișcă odată cu serviciul. Și nu presupuneți că o pereche de tuneluri administrate schimbă comportamentul unui client invitat arbitrar.
Alegeți rolul înaintea produsului
Scrieți o propoziție care numește direcția: această mașină se alătură unei rețele, această mașină acceptă clienți sau un gateway AWS conectează rețele definite.
Acea propoziție decide lista scurtă de produse, proprietarul software-ului și modurile de eșec pe care le veți depana. Dacă cerința este ca utilizatorii la distanță să ajungă la o aplicație, un client instalat în VM-ul aplicației este forma greșită. Dacă cerința este ca o mașină să ajungă la rețeaua unui partener, un gateway site-la-site administrat este mai multă mașinărie decât are nevoie sarcina. Ambele răspunsuri sunt legitime; doar unul corespunde propoziției pe care ați scris-o.