LAN bak én AWS Client VPN-økt: hva som videresendes

Bærbaren kobler til AWS Client VPN-endepunktet, når det private subnettet, og alt ser friskt ut. Skrivebordet på samme LAN når ingenting, selv om Linux-verten også har et bru-grensesnitt og begge maskinene er på samme kabel. Ingenting er feilkonfigurert i tunnelen; den manglende biten er ruting, og brua er et villspor.

Å utvide en Client VPN-økt til et LAN er en gateway-rolle. Det er ikke et Ethernet-segment strukket inn i en administrert tjeneste.

Verten virker, og LAN gjør det ikke

Tunnelgrensesnittet på Linux-boksen har en adresse innenfor Client VPN-klientens CIDR, og endepunktet har dyttet ruter for VPC-områdene. En forespørsel gjort på den boksen er lokalt generert trafikk: den velger en rute, går ut gjennom tunnelen og får et svar. Den veien berører aldri videresendingskoden, LAN-grensesnittet eller noen brannmurregel som styrer transitt.

Trafikk fra en annen LAN-enhet er en annen flyt. Den ankommer LAN-grensesnittet, trenger en rute som peker inn i tunnelen, trenger videresending aktivert, trenger en brannmur som tillater den, og trenger at svaret kommer tilbake gjennom samme vert. Fire krav, og den fungerende bærbartesten beviser ingen av dem. Fra skrivebordet ser feilen bisarr ut: tunnelen er oppe, legitimasjonen er gyldig, og målet svarer bare aldri. Defekten er lokal i gatewayens videresendingsvei, ikke i tjenesten.

Ikke alle klienter kan være en gateway

AWS opplyser at skrivebordsapplikasjonen for Client VPN ikke støtter IP-videresending, og at andre klienter kan gjøre det. Den begrensningen avgjør arkitekturen før noen kommando skrives. Hvis den eneste tilgjengelige klienten er den offisielle skrivebordsappen, er en Linux-gateway som videresender for LAN ikke en konfigurasjon du kan fullføre, og ingen mengde masquerading endrer det.

Erstatningsklienten må også passe til endepunktets autentiseringsmetode og politikken du har tenkt å håndheve. Endepunkter basert på sertifikater, katalog og SAML godtar ikke de samme klientkonfigurasjonene, og en tredjepartsklient som autentiserer men ignorerer de dyttede rutene er ikke en forbedring.

Behandle klientvalget som en del av designgjennomgangen. Det avgjør om LAN-videresendingsmønsteret er tilgjengelig i det hele tatt, og det avgjør hvilken identitet endepunktet ser for hver enhet bak gatewayen. Registrer klienten og endepunktkonfigurasjonen den ble testet mot. En klientutskifting seks måneder senere kan stille fjerne evnen designet forutsatte.

Rut LAN til tunnelen og oversett det

Med en støttet klient på plass er resten vanlig gateway-arbeid. LAN-enhetene trenger en rute for VPC-området som peker på Linux-verten, og verten trenger videresending aktivert. Hvis du vil at VPC-en skal se trafikken som den tilkoblede klienten og ikke som en vilkårlig LAN-adresse, oversett kilden på vei 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

Begrens regelen til tunnelgrensesnittet og VPC-området, som ovenfor, i stedet for å masquerade alt verten videresender. Den smalere regelen er lettere å resonnere om, og den endrer ikke stille trafikk som skulle beholde sin opprinnelige kildeadresse.

La LAN-ruten komme automatisk hvis du kan: et DHCP-alternativ, en ruterkunngjøring eller en statisk rute dyttet av det som administrerer LAN-et. En rute som bare finnes på én testmaskin, vil få designet til å se ødelagt ut i det øyeblikket noen andre prøver det.

Svaret trenger også en vei

Når forespørselen når VPC-en, må svaret komme tilbake gjennom de samme oversettelsestilstandene og finne LAN-ruten på gatewayen. Den delen virker vanligvis når masquerade-regelen er på plass, fordi mappingen lever på verten som utførte den. Den bryter når VPC-siden har en rute som sender svaret et annet sted, og derfor betyr både klient-CIDR-ruten og subnettilordningen på endepunktet noe.

Følg med på tellerne, ikke bare ping. En masquerade-regel med null pakker forteller deg at forespørselen aldri nådde tunnelgrensesnittet, noe som peker tilbake på LAN-ruten eller klientens egen rutetabell. En regel med pakker men uten svar peker på VPC-siden, autorisasjonsreglene eller en sikkerhetsgruppe som ikke godtar den oversatte kilden. Les begge retninger før du endrer noe, fordi et tall som bare vokser på én side er en enveisvei, ikke en langsom.

Husk at endepunktet er en administrert tjeneste. Det finnes ingen serverkonfigurasjonsfil å redigere og ingen client-config-direktiv å legge til, så instruksjoner skrevet for en selvadministrert OpenVPN-server med egendefinerte klient-subnett-ruter overføres ikke. På AWS er spakene subnettilordning, autorisasjonsregler og VPC-ens rutetabeller.

Delt identitet er den delen politikken må svare på

Hver enhet bak gatewayen bruker gatewayens VPN-økt. Autorisasjonsreglene til endepunktet gir tilgang til en bruker eller en gruppe, og fra tjenestens synspunkt er det nøyaktig én bruker på den økten. Lokal videresending multipliserer ikke den identiteten til autentisering per enhet, og den utvider ikke enhetsposturkontroller til skriveren i hjørnet.

Det kan være akseptabelt, eller det kan være grunnen til at designet avvises. Det avhenger av hva VPC-ressursene forutsetter om hvem som ringer. En delt identitet som passer til autorisasjonsmodellen er greit; en som stille gjør en enkelt autentisert økt om til tilgang for hele LAN-et, er et funn som venter på å bli skrevet.

Hvis kravet egentlig er å koble et helt anlegg til en VPC, sammenlign et støttet anlegg-til-anlegg-design før du utvider en fjernaksessklient. Semantikken er forskjellig, og en NAT-et klientøkt er en dårlig erstatning for en anleggsforbindelse når VPC-en må starte forbindelser inn i LAN-et.

Bestem klienten, ruten, oversettelsen og identitetshistorien i den rekkefølgen. Hver begrenser den neste, og rekkefølgen forklarer hvorfor verten virker mens LAN-et ikke gjør det.