LAN pas një sesioni AWS Client VPN: çfarë përcillet

Laptopi lidhet me pikën fundore të AWS Client VPN, arrin në nënrrjetin privat dhe gjithçka duket e shëndetshme. Desktopi në të njëjtin LAN nuk arrin asgjë, ndonëse host-i Linux ka gjithashtu një ndërfaqe ure dhe të dyja makinat janë në të njëjtin kabllo. Asgjë nuk është konfiguruar gabimisht në tunel; pjesa që mungon është rrugëtimi, dhe ura është një gjurmë e rreme.

Zgjerimi i një sesioni Client VPN në një LAN është rol porte. Nuk është një segment Ethernet i shtrirë në një shërbim të menaxhuar.

Host-i funksionon dhe LAN-i jo

Ndërfaqja e tunelit në makinën Linux ka një adresë brenda CIDR-it të klientit Client VPN, dhe pika fundore ka shtyrë rrugë për intervalet e VPC. Një kërkesë e bërë në atë makinë është trafik i gjeneruar lokalisht: zgjedh një rrugë, del përmes tunelit dhe merr një përgjigje. Ajo rrugë nuk prek kurrë kodin e përcjelljes, ndërfaqen LAN ose ndonjë rregull muri zjarri që drejton transitin.

Trafiku nga një pajisje tjetër LAN është një rrjedhë tjetër. Ai arrin në ndërfaqen LAN, ka nevojë për një rrugë që tregon në tunel, ka nevojë për përcjellje të aktivizuar, ka nevojë për një mur zjarri që e lejon dhe ka nevojë që përgjigja të kthehet përmes të njëjtit host. Katër kushte, dhe testi që funksionon në laptop nuk provon asnjë. Nga desktopi dështimi duket i çuditshëm: tuneli është lart, kredencialet janë të vlefshme dhe destinacioni thjesht nuk përgjigjet kurrë. Defekti është lokal në rrugën e përcjelljes së portës, jo në shërbim.

Nuk mund çdo klient të jetë portë

AWS deklaron se aplikacioni i saj desktop Client VPN nuk mbështet përcjelljen IP, dhe se klientët e tjerë mund ta mbështesin. Ai kufizim vendos arkitekturën përpara se të shtypet ndonjë komandë. Nëse i vetmi klient i disponueshëm është aplikacioni zyrtar desktop, një portë Linux që përcjell për LAN nuk është një konfigurim që mund ta përfundoni, dhe asnjë sasi masquerading nuk e ndryshon atë.

Klienti zëvendësues duhet gjithashtu të përputhet me metodën e vërtetimit të pikës fundore dhe me politikën që synoni të zbatoni. Pikat fundore të bazuara në certifikata, në drejtori dhe në SAML nuk pranojnë të njëjtat konfigurime klienti, dhe një klient i palës së tretë që vërtetohet por injoron rrugët e shtyra nuk është përmirësim.

Trajtoni zgjedhjen e klientit si pjesë të rishikimit të dizajnit. Ajo përcakton nëse modeli i përcjelljes LAN është fare i disponueshëm, dhe përcakton çfarë identiteti sheh pika fundore për çdo pajisje pas portës. Regjistroni klientin dhe konfigurimin e pikës fundore kundrejt të cilit u testua. Një ndërrim klienti gjashtë muaj më vonë mund të heqë në heshtje aftësinë që dizajni supozonte.

Drejtojeni LAN-in drejt tunelit dhe përktheni

Me një klient të mbështetur në vend, pjesa tjetër është punë e zakonshme porte. Pajisjet LAN kanë nevojë për një rrugë për intervalin e VPC që tregon te host-i Linux, dhe host-i ka nevojë për përcjellje të aktivizuar. Nëse dëshironi që VPC-ja ta shohë trafikun si klientin e lidhur dhe jo si një adresë LAN arbitrare, përktheni burimin në dalje.

LAN: 10.24.11.0/24
Linux LAN gateway: 10.24.11.15
VPN interface: tun0
Target VPC range: 10.2.0.0/16

iptables -t nat -A POSTROUTING -s 10.24.11.0/24 -d 10.2.0.0/16 -o tun0 -j MASQUERADE

Kufizojeni rregullin në ndërfaqen e tunelit dhe intervalin e VPC, si më sipër, në vend që të bëni masquerading për gjithçka që përcjell host-i. Rregulli më i ngushtë është më i lehtë për t’u arsyetuar, dhe nuk e ndryshon në heshtje trafikun që duhej të ruante adresën e tij origjinale të burimit.

Lëreni rrugën LAN të vijë automatikisht nëse mundeni: një opsion DHCP, një shpallje ruteri ose një rrugë statike e shtyrë nga ajo që menaxhon LAN-in. Një rrugë që ekziston vetëm në një makinë testimi do ta bëjë dizajnin të duket i prishur në momentin që dikush tjetër e provon.

Edhe përgjigja ka nevojë për një rrugë

Pasi kërkesa arrin në VPC, përgjigja duhet të kthehet përmes të njëjtave gjendje përkthimi dhe të gjejë rrugën LAN në portë. Ajo pjesë zakonisht funksionon kur rregulli masquerade është në vend, sepse hartëzimi jeton në host-in që e kreu. Prishet kur ana e VPC ka një rrugë që e dërgon përgjigjen diku tjetër, dhe kjo është arsyeja pse rruga CIDR e klientit dhe lidhja e nënrrjetit në pikën fundore kanë të dyja rëndësi.

Shikoni numëratorët, jo vetëm ping-un. Një rregull masquerade me zero paketa ju thotë se kërkesa nuk arriti kurrë në ndërfaqen e tunelit, gjë që tregon përsëri në rrugën LAN ose në tabelën e rrugëtimit të vetë klientit. Një rregull me paketa por pa përgjigje tregon anën e VPC, rregullat e autorizimit ose një grup sigurie që nuk e pranon burimin e përkthyer. Lexoni të dy drejtimet përpara se të ndryshoni diçka, sepse një numër që rritet vetëm nga njëra anë është rrugë njëkahëshe, jo e ngadaltë.

Mbani mend se pika fundore është një shërbim i menaxhuar. Nuk ka skedar konfigurimi serveri për të redaktuar dhe as direktivë client-config për të shtuar, kështu që udhëzimet e shkruara për një server OpenVPN të vetëmenaxhuar me rrugë të personalizuara të nënrrjetit të klientit nuk transferohen. Në AWS levat janë lidhja e nënrrjetit, rregullat e autorizimit dhe tabelat e rrugëtimit të VPC-së.

Identiteti i përbashkët është pjesa së cilës politika duhet t’i përgjigjet

Çdo pajisje pas portës përdor sesionin VPN të portës. Rregullat e autorizimit të pikës fundore i japin akses një përdoruesi ose një grupi, dhe nga këndvështrimi i shërbimit ka saktësisht një përdorues në atë sesion. Përcjellja lokale nuk e shumëfishon atë identitet në vërtetim për pajisje, dhe nuk i zgjeron kontrollet e qëndrimit të pajisjes deri te printeri në cep.

Kjo mund të jetë e pranueshme, ose mund të jetë arsyeja pse dizajni refuzohet. Varet nga ajo që burimet e VPC supozojnë për atë që telefonon. Një identitet i përbashkët që përshtatet me modelin e autorizimit është në rregull; një që e kthen në heshtje një sesion të vetëm të vërtetuar në akses për të gjithë LAN-in është një gjetje që pret të shkruhet.

Nëse kërkesa është vërtet lidhja e një siti të tërë me një VPC, krahasoni një dizajn të mbështetur sit-në-sit përpara se të zgjeroni një klient aksesi në distancë. Semantika është e ndryshme, dhe një sesion klienti me NAT është një zëvendësues i dobët për një lidhje siti kur VPC-ja duhet të nisë lidhje në LAN.

Vendosni klientin, rrugën, përkthimin dhe historinë e identitetit në atë rend. Secili kufizon tjetrin, dhe rendi shpjegon pse host-i funksionon ndërsa LAN-i jo.