LAN bak ein AWS Client VPN-økt: kva som vert sendt vidare

Berbare datamaskina koplar til AWS Client VPN-endepunktet, når det private subnettet, og alt ser friskt ut. Skrivebordet på same LAN når ingenting, sjølv om Linux-verten òg har eit bru-grensesnitt og begge maskinene er på same kabel. Ingenting er feilkonfigurert i tunnelen; den manglande biten er rutingsarbeid, og brua er eit villspor.

Å utvide ei Client VPN-økt til eit LAN er ei gateway-rolle. Det er ikkje eit Ethernet-segment som erstrekt inn i ein styrt teneste.

Verten verkar, men LAN gjer det ikkje

Tunnelgrensesnittet på Linux-boksa har ei adresse innanfor CIDR-en til Client VPN-klienten, og endepunktet har dytta ruter for VPC-områda. Ei førespurnad gjort på den boksa er lokalt generert trafikk: ho vel ei rute, går ut gjennom tunnelen og får eit svar. Den vegen rører aldri ved videresendingskoden, LAN-grensesnittet eller noka brannmurregel som styrer transitt.

Trafikk frå ein annan LAN-eining er ein annan straum. Han kjem inn på LAN-grensesnittet, treng ei rute som peikar inn i tunnelen, treng videresending slått på, treng ein brannmur som lèt han gjennom, og treng at svaret kjem tilbake gjennom same vert. Fire krav, og den fungerande berbar-testen provar ingen av dei. Frå skrivebordet ser feilen bizar ut: tunnelen er oppe, innlogginga er gyldig, og målet svarar berre aldri. Defekten er lokal i videresendingsvegen til gatewayen, ikkje i tenesta.

Ikkje alle klientar kan vere ein gateway

AWS opplyser at skrivebordsapplikasjonen for Client VPN ikkje støttar IP-videresending, og at andre klientar kan gjere det. Den avgrensinga avgjer arkitekturen før nokon kommando er skriven. Viss den einaste tilgjengelege klienten er den offisielle skrivebordsappen, er ein Linux-gateway som videresender for LANet ikkje ein konfigurasjon du kan fullføre, og inga mengd masquerading endrar det.

Erstatningsklienten må òg passe til autentiseringsmetoden til endepunktet og politikken du har tenkt å handheve. Endepunkt baserte på sertifikat, katalog og SAML godtek ikkje dei same klientkonfigurasjonane, og ein tredjepartsklient som autentiserer men ignorerer dei dytta rutene er ikkje ei betring.

Handter klientvalet som ein del av designgjennomgangen. Det avgjer om LAN-videresendingsmønsteret i det heile er tilgjengeleg, og det avgjer kva identitet endepunktet ser for kvar eining bak gatewayen. Registrer klienten og endepunktkonfigurasjonen han vart testa mot. Ein klientbyte seks månader seinare kan stille fjerne evna designet føresette.

Rut LAN inn i tunnelen og set det om

Med ein støtta klient på plass er resten vanleg gateway-arbeid. LAN-einingane treng ei rute for VPC-området som peikar på Linux-verten, og verten treng videresending slått på. Viss du vil at VPCen skal sjå trafikken som den tilkopla klienten og ikkje som ei vilkårleg LAN-adresse, set om kjelda på vegen ut.

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

Avgrens regelen til tunnelgrensesnittet og VPC-området, som ovanfor, i staden for å masquerade alt verten videresender. Den smalare regelen er lettare å tenkje gjennom, og han endrar ikkje stille trafikk som skulle halde på den opphavlege kjeldeadressa si.

Lat LAN-ruta kome automatisk viss du kan: eit DHCP-val, ei ruterkunngjering eller ei statisk rute dytta av det som styrer LANet. Ei rute som berre finst på éin testmaskin, vil få designet til å sjå øydelagt ut i det augneblinken nokon andre prøver det.

Svaret treng òg ein veg

Når førespurnaden når VPCen, må svaret kome tilbake gjennom dei same omsetjingstilstandane og finne LAN-ruta på gatewayen. Den delen verkar vanlegvis når masquerade-regelen er på plass, fordi kartlegginga lever på verten som gjorde det. Han bryt når VPC-sida har ei rute som sender svaret ein annan stad, og difor spelar både klient-CIDR-ruta og subnettildelinga på endepunktet ei rolle.

Fylg med på teljarane, ikkje berre ping. Ein masquerade-regel med null pakkar fortel deg at førespurnaden aldri nådde tunnelgrensesnittet, noko som peikar tilbake på LAN-ruta eller den eigne rutetabellen til klienten. Ein regel med pakkar men utan svar peikar på VPC-sida, autorisasjonsreglane eller ei tryggleiksgruppe som ikkje godtek den omsette kjelda. Les begge retningane før du endrar noko, fordi eit tal som berre veks på éi side er ein einveg, ikkje ein langsam veg.

Hugs at endepunktet er ein styrt teneste. Det finst inga tenarkonfigurasjonsfil å redigere og ingen client-config-direktiv å leggje til, så instruksjonar skrivne for ein sjølvstyrt OpenVPN-tenar med eigne klient-subnett-ruter flyttar seg ikkje over. På AWS er spakane subnettildeling, autorisasjonsreglar og rutetabellane til VPCen.

Delt identitet er den delen politikken må svare på

Kvar eining bak gatewayen brukar VPN-økta til gatewayen. Autorisasjonsreglane til endepunktet gjev tilgang til ein brukar eller ei gruppe, og frå synsstaden til tenesta er det nøyaktig éin brukar på den økta. Lokal videresending multipliserer ikkje den identiteten til autentisering per eining, og ho utvidar ikkje einingstilstandskontrollar til skrivaren i hjørnet.

Det kan vere akseptabelt, eller det kan vere grunnen til at designet blir avvist. Det kjem an på kva VPC-ressursane føreset om kven som ringjer. Ein delt identitet som passar til autorisasjonsmodellen er grei; ein som stille gjer ei einsleg autentisert økt om til tilgang for heile LANet, er eit funn som ventar på å bli skrive.

Viss kravet eigentleg er å kople eit heilt anlegg til ein VPC, samanlikn eit støtta anlegg-til-anlegg-design før du utvidar ein fjernklient. Semantikken er annleis, og ei NAT-økta klientøkt er ein dårleg erstatning for ein anleggsforbindelse når VPCen må starte samband inn i LANet.

Avgjer klienten, ruta, omsetjinga og identitetshistoria i den rekkjefølgja. Kvar avgrensar den neste, og rekkjefølgja forklarer kvifor verten verkar medan LANet ikkje gjer det.