AWS Client VPN of Site-to-Site: kyk wie die verbinding oopmaak

Vier toetse besluit dit, en nie een daarvan is die protokolnaam nie. Wie maak die verbinding oop, wat AWS verifieer, hoe die verbinding by jou netwerk aansluit, en watter roetebepaling en beleid daarmee saamkom. Antwoord dit in volgorde en die produkkeuse maak gewoonlik homself; antwoord dit nadat jy reeds 'n ontwerp gekoop het en jy sal 'n tonnel verdedig wat die verkeerde helfte van die probleem oplos. Nie een van die vier vra jou om 'n cipher te kies nie, en daarom is 'n protokol-eerste ontwerp gewoonlik 'n teken dat die vereistes nooit neergeskryf is nie.

Toets elkeen teen die werklike eindpunt, kliënt en adresfamilie wat jy beplan om te gebruik, nie teen die kategorie nie. Bestuurde VPN-produkte verskil van die OpenVPN- en IPsec-boustene waarop hulle lyk.

Eerste, wie maak die verbinding oop

As die ding wat toegang nodig het 'n skootrekenaar, 'n selfoon of 'n enkele administrateur se werkstasie is, begin die verbinding by 'n afgeleë toestel en is die ontwerp afgeleë-kliënttoegang. As die ding wat toegang nodig het 'n tak vol masjiene agter een roeteerder is, begin die verbinding by daardie roeteerder en is die ontwerp gateway-tot-gateway. Dit is die toets wat die meeste gevalle beslis, en dit is die een wat mense oorslaan wanneer 'n verskaffer se aanbieding die gesprek al rondom ciphers ingeraam het.

Stop hier as jy nie die komponent kan noem wat begin nie. 'n Ontwerp wat probeer om beide gevalle met een tonnel te dien, eindig gewoonlik met 'n kliëntsessie wat voorgee om 'n gateway te wees.

Tweedens, wat AWS verifieer

Met Client VPN verifieer AWS die gekonfigureerde kliënt- of gebruikersidentiteit: sertifikate, 'n gids of 'n gefedereerde identiteit, afhangende van die opstelling. Met Site-to-Site VPN verifieer AWS die gateway se portuuridentiteit. Daardie verskil is nie kosmeties nie. Een model skaleer deur gebruikers by te voeg en hul geloofsbriewe te herroep; die ander skaleer deur te vertrou wat ook al agter 'n enkele gateway sit.

Gateway-verifikasie verifieer nie elke werknemer of toepassing daaragter nie, so hou toepassingsidentiteite en toegang op hulpbronvlak in plek selfs wanneer die tonnel self vertrou word. 'n Tak waarvan die roeteerder 'n geldige portuuridentiteit het, moet nie outomaties gelees word asof elke lessenaar in daardie gebou gemagtig is nie.

Derdens, hoe die verbinding aansluit

Client VPN sluit aan deur VPC-subnetassosiasies of 'n ondersteunde direkte Transit Gateway-koppeling. Site-to-Site VPN sluit aan by 'n AWS VPN-teiken, gewoonlik 'n virtuele private gateway of 'n Transit Gateway. Die Client VPN-argitektuurgids dokumenteer die Transit Gateway-opsie, en sy bestaan verander nie 'n skootrekenaarsessie in 'n takgateway nie en verwyder nie die kliëntverifikasie en magtiging hierbo beskryf nie.

Kontroleer die koppeling wat jou rekening en streek werklik ondersteun voordat jy roetes daarom ontwerp, en kontroleer dan wie daardie koppeling besit. 'n Opsie wat in die dokumentasie bestaan maar op 'n netwerk sit wat jy nie kan konfigureer nie, is nie 'n opsie nie.

Vierdens, watter roetebepaling en beleid daarmee saamkom

Client VPN bring kliëntverbindingbestuur en magtigingsreëls vir die bestemmingsnetwerke wat jy toelaat. 'n Gekoppelde gebruiker het steeds die beoogde eindpuntroete nodig, 'n magtigingsreël wat dit toelaat, en watter toegang die hulpbron self ook al vereis. Site-to-Site VPN roeteer tussen netwerke wat deur 'n kliëntgateway verteenwoordig word, met behulp van ondersteunde statiese roetes of BGP, afhangende van die ontwerp, so individuele masjiene agter die takroeteerder het nie elkeen 'n kliëntaanmelding nodig nie.

Moenie ongesteunde gedrag uit die kategorie in enige rigting aflei nie. Afgeleë-toegang-VPN's is nie universeel onvermoënd om terugkeerverkeer te dra of gateway-reëlings te ondersteun nie, en IPsec word nie outomaties deur NAT geblokkeer nie — AWS dokumenteer NAT-traversal en kliëntgateway-vereistes, en die ondersteunde gateway-konfigurasie is die werklike beperking. Kontroleer die beperkings vir jou eindpunt voordat jy verbindings vereis wat na kliënte begin word of 'n LAN agter een sessie deurstuur. Dieselfde versigtigheid geld vir adresfamilies: 'n eindpunt wat oor IPv4 werk, impliseer nie 'n IPv6-pad nie, so bevestig die familie wat jou kliënt of gateway werklik sal onderhandel.

Site-to-Site VPN gee jou twee tonnels per verbinding, en daardie oortolligheid is 'n ontwerptaak eerder as 'n funksie wat jy kan aanvaar. Kliëntgateway-werking, roete-oorskakeling en toetsdekking moet alles beplan word; om een skootrekenaarsessie met 'n abstrakte VPN-bediener te vergelyk, bewys niks oor enige van die twee nie.

Waar die twee ontwerpe ontmoet

Die dienste is nie eksklusief nie, en die algemene produksievorm gebruik albei: werknemers op Client VPN, taknetwerke op Site-to-Site, met eksplisiete roetes en toegangsbeleid tussen die bestemmings wat moet praat. Die tabel is 'n samevatting van die vier toetse, nie 'n plaasvervanger daarvoor nie.

Een ding wat nie een van die twee produkte vervang nie: TLS na 'n toepassing wie se enkripsievereiste verby die VPN-eindpunt strek. As jou nakomingsomvang by die toepassing eindig, is die tonnel vervoer en die sertifikaat steeds die beheer.

Skryf die vier antwoorde neer voor die ontwerphersiening, een reël elk. Wanneer twee daarvan nie ooreenstem nie — sê, 'n gebruiker-geverifieerde kliëntontwerp met 'n tak-grootte roetebepalingsvereiste — is daardie meningsverskil die bevinding, en dit is goedkoper om dit nou te sien as tydens die oorskakeling.