AWS Client VPN ose një VPN në EC2: një manual operativ

Të dyja opsionet i japin ekipit tuaj një VPN për akses në distancë, prandaj pyetja interesante nuk është cila ekziston, por cila mund të operohet. Diferenca është kush zotëron pikën përfundimtare në orën 3 të mëngjesit dhe cilat kontrolle arrini kur diçka prishet. Ndjekni pesë hapat më poshtë me radhë, sepse secili mund ta përfundojë krahasimin herët. Anashkalimi i hapit të inventarit është pikërisht mënyra se si ekipet përfundojnë duke migruar dy herë.

Hapi 1: shkruani kërkesën para faturës

Ju nevojiten pesë fakte në një faqe: kush vërtetohet dhe kundrejt çfarë, cilat platforma klienti duhet të funksionojnë, cilat destinacione private janë të arritshme, çfarë disponueshmërie keni premtuar dhe si duket në të vërtetë trafiku. Pa këto, çdo krahasim i mëvonshëm kthehet në një debat për një listë funksionesh.

Jini konkret për destinacionet. «Akses në VPC» zakonisht nënkupton tri gjëra të ndryshme: CIDR-in e VPC-së, një rrjet të lidhur me peering dhe një interval lokal pas një Transit Gateway. Një pikë përfundimtare e menaxhuar arrin të tria, por secila kërkon një rrugë dhe një rregull autorizimi, dhe secila është një rresht më vete në kërkesën tuaj.

Hapi 2: renditni çfarë tashmë funksionon

Përpara se të projektoni çdo gjë, renditni pikat përfundimtare ekzistuese dhe çdo server të strehuar në EC2 bashkë me grupet e tij të sigurisë. Këto thirrje janë vetëm lexim dhe të sigurta për t’u ekzekutuar nga një llogari me leje describe.

aws ec2 describe-client-vpn-endpoints
aws ec2 describe-client-vpn-authorization-rules --client-vpn-endpoint-id cvpn-endpoint-xxxx
aws ec2 describe-client-vpn-routes --client-vpn-endpoint-id cvpn-endpoint-xxxx
aws ec2 describe-client-vpn-connections --client-vpn-endpoint-id cvpn-endpoint-xxxx
aws ec2 describe-instances --filters Name=tag:role,Values=vpn

Lexojeni daljen si një hartë të asaj që klientët arrijnë tashmë. Një rregull autorizimi që mungon shpjegon një dështim që duket si problem rrugëtimi, dhe një pikë përfundimtare e lidhur me një nënrrjet të vetëm shpjegon pse një dështim zone rrëzoi të gjithë shërbimin.

Shënoni edhe grupet e sigurisë të bashkangjitura në çdo instancë të vetëstrehuar. Këto rregulla janë pjesë e modelit të aksesit, dhe janë gjëja e parë që thyhet në heshtje kur dikush rindërton një instancë nga një shabllon.

Hapi 3: ndani përgjegjësitë

Shërbimi i menaxhuar zotëron flotën e pikave përfundimtare, patch-imin e saj dhe disponueshmërinë brenda rajonit. Ju zotëroni regjistrimin e identiteteve, rregullat e autorizimit, shtigjet e rrjetit pas pikës përfundimtare, konfigurimin e regjistrave dhe vendimin se sa nënrrjeta të lidhen.

Vetëstrehimi e përmbys këtë. Ju zotëroni sistemin operativ të mysafirit, demonin VPN dhe konfigurimin e tij, certifikatat dhe çelësat, kopjet rezervë, monitorimin dhe rikuperimin. Modeli i sigurisë i EC2 e vendos sigurinë e mysafirit dhe të aplikacionit mbi klientin, dhe një server VPN është mysafir si çdo tjetër.

Shkruani ndarjen si një tabelë me emra në kolonën e djathtë. Nëse pranë rinovimit të certifikatave nuk shfaqet asnjë emër, ky është gjetja, dhe peshon më shumë se diferenca e çmimit për orë.

Hapi 4: krahasoni me një ngarkesë pune që dini ta përshkruani

Kostoja ndjek formën, jo madhësinë. Për opsionin e menaxhuar, numëroni orët e lidhjes së pikave përfundimtare, orët e lidhjeve të klientëve, transferimin dhe shërbimet e identitetit e të regjistrave që aktivizoni. Për vetëstrehimin, numëroni llogaritjen, ruajtjen, rrjetin, licencat dhe kohën inxhinierike që e mban serverin të patch-uar. Vendosni të dyja grupet e numrave në një fletë me të njëjtin horizont kohor. Një krahasim trevjeçar që injoron orët e patch-imit do të favorizojë gjithmonë serverin që ju tashmë zotëroni.

Krahasimet e performancës kërkojnë të njëjtën disiplinë. Një sesion interaktiv desktopi, një transferim i madh dhe pesëdhjetë kërkesa të vogla të njëkohshme ushtrojnë presion mbi pjesë të ndryshme të shtegut: CPU-në për kriptimin, aftësinë e rrjetit të instancës, stivën e vetë klientit dhe destinacionin. Testoni me klientë përfaqësues dhe të njëjtën detyrë në të dyja modelet.

Një instancë më e madhe nuk është provë që transferimi do të jetë më i shpejtë, dhe një sesion i suksesshëm nuk është plan kapaciteti. Çdo tregim i trashëguar për familjet e instancave trajtojeni si hipotezë për t’u testuar, jo si rregull blerjeje.

Hapi 5: kaloni me një rikthim që e keni ekzekutuar tashmë

Nisni të dyja pikat përfundimtare paralelisht për një periudhë të caktuar, shpërndani profilin e ri të klientit fillimisht në një grup të vogël dhe mos i prekni rregullat e autorizimit të pikës së vjetër përfundimtare derisa grupi ta ketë përdorur të renë në punë reale. Rikthimi është ndryshim profili, jo rindërtim, prandaj vendosni tani ku jeton profili i vjetër.

Verifikoni në këtë rend: vërtetimi kalon, klienti merr rrugët e pritura, një destinacion i autorizuar përgjigjet dhe një destinacion i paautorizuar dështon, dhe regjistrat tregojnë të dyja ngjarjet. Nëse ndonjë hap dështon, ndaloni dhe rregulloni atë hap në vend që të kaloni në grupin tjetër të klientëve. Shënoni rezultatin e çdo kontrolli, sepse një kalim që mbahet mend vetëm si «funksionoi» nuk mund të debug-ohet një muaj më vonë.

Pas kalimit, planifikoni kontrollet e mërzitshme: skadimi i certifikatave, numri i lidhjeve, rregullat e autorizimit që nuk përputhen më me një grup dhe numri i lidhjeve kundrejt pritshmërisë tuaj. Udhëzuesi i administrimit të Client VPN është referenca për pjesët e pikës përfundimtare, vërtetimit dhe rrugëtimit që keni konfiguruar.