EC2 Windows: VPN-kliento, VPN-servilo aŭ AWS-enirejo?
Windows EC2-maŝino povas ruli VPN-programaron, sed kliento, memregata servilo kaj AWS-enirejo estas malsamaj roloj kun malsamaj posedantoj.
Teamo bezonas VPN-konekton por aplikaĵo ruliĝanta sur Windows EC2-maŝino, trovas kongruan klientan programaron, instalas ĝin kaj poste demandas, kial la resto de la VPC ne povas uzi ĝin. La instalado funkciis; la rolo neniam estis decidita. Programaro ruliĝanta ene de gasto povas esti kliento, kiu aliĝas al la reto de iu alia, servilo, kiu akceptas aliajn klientojn, aŭ neniu el la de AWS administrataj VPN-produktoj, kaj ĉiu rolo lasas malsaman laboron al vi.
La simptomo kutime estas la malĝusta rolo
La ofta simptomo estas funkcianta tunelo, kiu solvas la malĝustan problemon. Kliento en la virtuala maŝino donas al ĝi eliran vojon; ĝi ne donas al via tekkomputilo, oficejo aŭ alia subreto vojon enen. Servilo en la maŝino donas al aliaj vojon enen, sed nun vi posedas la aŭskultanton, la aŭtentikigon kaj la plusendadon.
Administrataj servoj translokas la servan operacion al AWS kaj lasas la dezajnon al vi. Site-to-Site VPN ligas retojn per klienta enirejo kaj AWS-enirejo, kaj Client VPN donas al malproksimaj aparatoj administrata finpunkto. En ambaŭ kazoj la vojoj, la rajtigaj reguloj kaj la identeca fonto estas via agordo, kaj neniu el la produktoj instalas ĝeneraluzan klienton ene de Windows-gasto.
Kvar formoj eblas, kaj la tabelo apartigas ilin laŭ tio, kio ligiĝas al kio kaj kiu portas la operacian ŝarĝon.
| 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 |
Legu la vicon, ne la produktonomon: la sama Windows-maŝino povas sidi en du malsamaj vicoj depende de tio, kiu programaro ruliĝas en ĝi.
Kliento ene de la maŝino: la maŝino aliĝas al reto
Elirema kliento bezonas, ke la Windows-versio, la arkitekturo kaj la pelilaj postuloj estu kontrolitaj antaŭ ol io ajn estas instalita. La kliento ŝanĝos vojojn kaj DNS sur la maŝino, kio povas influi servojn jam ruliĝantajn tie, inkluzive de la vojo, kiun vi uzas por fora administrado. Notu la nomon de la adaptilo kaj la interferan metrikon, kiun la kliento starigas, ĉar la nova interfaco povas antaŭi la ekzistantan. Se la maŝino estas administrata per sesia administrilo anstataŭ SSH aŭ RDP, konfirmu, ke tiu vojo ankoraŭ funkcias post kiam la kliento konektiĝas.
Decidu, kiun trafikon la kliento portu, antaŭ ol vi ŝaltos ĝin. Plena tunelo povas kapti la administran sesion kaj ŝlosi vin ekstere, kaj dividita tunelo povas lasi la maŝinon atingi la privatan reton dum ĝia alia trafiko prenas alian eliron. Testu kun dua administra vojo disponebla, kaj notu la vojojn, kiujn la kliento instalas, por ke posta ŝanĝo estu klarigebla.
Servilo ene de la maŝino: aliaj klientoj aliĝas al ĝi
Por memregata servilo vi posedas la aŭskultanton, la atestilon aŭ ŝlosilan materialon, la uzulan datumbazon kaj la plusendajn regulojn. Se la servilo plusendas trafikon por aliaj klientoj, la maŝino fariĝas kursigilo, kaj tio postulas plusendadon je gasta nivelo plus ŝanĝojn de vojoj kaj sekurecaj grupoj je AWS-nivelo.
Testu la aŭskultanton el la gasto kaj denove el alia subreto, poste testu gastiganton, por kiu la maŝino plusendas. Sana loka servo pruvas nenion pri la plusendata vojo, do notu ambaŭ rezultojn en la ŝanĝnoto.
Administrataj enirejoj konservas la servon, ne vian alirdesegnaĵon
AWS Site-to-Site VPN dokumentigas la tunelajn rolojn de klienta enirejo kaj AWS-enirejo, kaj aĉeti tiun ligon ne anstataŭigas ĉiun foraliran dezajnon. Client VPN dokumentigas administratajn finpunktojn kun klientaj personoj, dum la rajtigaj reguloj kaj celaj vojoj restas viaj. AWS tenas la finpunkton kaj ĝiajn atestilojn funkciantaj; kiu rajtas atingi kiun aplikaĵon ankoraŭ estas rajtiga regulo, kiun vi skribas kaj prizorgas.
Elektu inter la produktoj laŭ kvin aksoj: kiun rolon ĉiu ludas, kiujn protokolojn ĝi akceptas, kiun identecan fonton ĝi atendas, kiel trafiko plusendiĝas kaj kiel havebleco liveriĝas. Ignoru ajnan unuopan trafikan ciferon cititan en forumfadeno, ĉar la publikigita kapacito moviĝas kun la servo. Kaj ne supozu, ke administrata tunela paro ŝanĝas la konduton de arbitra gastkliento.
Elektu la rolon antaŭ la produkto
Skribu unu frazon, kiu nomas la direkton: ĉi tiu maŝino aliĝas al reto, ĉi tiu maŝino akceptas klientojn, aŭ AWS-enirejo ligas difinitajn retojn.
Tiu frazo decidas la produktoproviĝliston, la posedanton de la programaro kaj la fiaskajn reĝimojn, kiujn vi sencimigos. Se la postulo estas, ke malproksimaj uzantoj atingu aplikaĵon, kliento instalita en la maŝino de la aplikaĵo estas la malĝusta formo. Se la postulo estas, ke unu maŝino atingu partneran reton, administrata site-to-site-enirejo estas pli da maŝinaro ol la tasko bezonas. Ambaŭ respondoj estas legitimaj; nur unu el ili kongruas kun la frazo, kiun vi skribis.