LAN bag en enkelt AWS Client VPN-session: hvad videresendes

Bærbaren opretter forbindelse til AWS Client VPN-endpointet, når det private undernet, og alt ser sundt ud. Skrivebordet på samme LAN kan ikke nå noget, selvom Linux-værten også har en brogrænseflade, og begge maskiner er på samme kabel. Intet er konfigureret forkert i tunnelen; den manglende brik er routing, og broen er et vildspor.

At udvide en Client VPN-session til et LAN er en gatewayrolle. Det er ikke et Ethernet-segment strakt ind i en administreret tjeneste.

Værten virker, og LAN’et gør ikke

Tunnelgrænsefladen på Linux-boksen har en adresse inden for Client VPN-klientens CIDR, og endpointet har skubbet ruter til VPC-intervallerne. En anmodning fra den boks er lokalt genereret trafik: den vælger en rute, forlader gennem tunnelen og får et svar. Den vej rører aldrig videresendelseskoden, LAN-grænsefladen eller nogen firewallregel, der styrer transit.

Trafik fra en anden LAN-enhed er en anden strøm. Den ankommer på LAN-grænsefladen, har brug for en rute, der peger ind i tunnelen, har brug for aktiveret videresendelse, har brug for en firewall, der tillader den, og har brug for, at svaret kommer tilbage gennem samme vært. Fire krav, og den fungerende bærbartest beviser ikke ét af dem. Fra skrivebordet ser fejlen bizar ud: tunnelen er oppe, legitimationsoplysningerne er gyldige, og destinationen svarer bare aldrig. Defekten er lokal i gatewayens videresendelsesvej, ikke i tjenesten.

Ikke alle klienter kan være gateway

AWS oplyser, at dens Client VPN-skrivebordsapp ikke understøtter IP-videresendelse, og at andre klienter muligvis gør. Den begrænsning afgør arkitekturen, før nogen kommando skrives. Hvis den eneste tilgængelige klient er den officielle skrivebordsapp, er en Linux-gateway, der videresender for LAN’et, ikke en konfiguration, du kan færdiggøre, og ingen mængde masquerading ændrer det.

Erstatningsklienten skal også matche endpointets godkendelsesmetode og den politik, du vil håndhæve. Endpoints baseret på certifikater, katalog og SAML accepterer ikke de samme klientkonfigurationer, og en tredjepartsklient, der godkender men ignorerer de skubbede ruter, er ikke en forbedring.

Behandl klientvalget som en del af designgennemgangen. Det afgør, om LAN-videresendelsesmønstret overhovedet er tilgængeligt, og det afgør, hvilken identitet endpointet ser for hver enhed bag gatewayen. Registrer klienten og den endpointkonfiguration, den blev testet imod. En klientudskiftning seks måneder senere kan stille fjerne den evne, designet forudsatte.

Rut LAN’et til tunnelen, og oversæt det

Med en understøttet klient på plads er resten almindeligt gatewayarbejde. LAN-enhederne har brug for en rute til VPC-intervallet, der peger på Linux-værten, og værten har brug for aktiveret videresendelse. Hvis du vil have VPC’en til at se trafikken som den tilsluttede klient i stedet for som en vilkårlig LAN-adresse, skal du oversætte kilden på vej ud.

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

Afgræns reglen til tunnelgrænsefladen og VPC-intervallet, som ovenfor, i stedet for at masquerade alt, hvad værten videresender. Den smallere regel er lettere at ræsonnere om, og den ændrer ikke stille trafik, der skulle beholde sin oprindelige kildeadresse.

Sørg for, at LAN-ruten kommer automatisk, hvis du kan: en DHCP-indstilling, en routerannoncering eller en statisk rute, der skubbes af det, der styrer LAN’et. En rute, der kun findes på én testmaskine, får designet til at se ødelagt ud i det øjeblik, en anden prøver det.

Svaret har også brug for en vej

Når anmodningen når VPC’en, skal svaret tilbage gennem de samme oversættelsestilstande og finde LAN-ruten på gatewayen. Den del virker normalt, når masquerade-reglen er på plads, fordi mappingen lever på den vært, der udførte den. Det bryder, når VPC-siden har en rute, der sender svaret et andet sted hen, og derfor betyder både klient-CIDR-ruten og undernetstilknytningen på endpointet noget.

Hold øje med tællerne, ikke kun ping. En masquerade-regel med nul pakker fortæller dig, at anmodningen aldrig nåede tunnelgrænsefladen, hvilket peger tilbage på LAN-ruten eller klientens egen routingtabel. En regel med pakker men uden svar peger på VPC-siden, autorisationsreglerne eller en sikkerhedsgruppe, der ikke accepterer den oversatte kilde. Læs begge retninger, før du ændrer noget, fordi et tal, der kun vokser på den ene side, er en envejsvej, ikke en langsom.

Husk, at endpointet er en administreret tjeneste. Der er ingen serverkonfigurationsfil at redigere og ingen client-config-direktiv at tilføje, så instruktioner skrevet til en selvadministreret OpenVPN-server med brugerdefinerede klientundernetsruter overføres ikke. På AWS er håndtagene undernetstilknytning, autorisationsregler og VPC’ens routingtabeller.

Delt identitet er den del, politikken skal svare på

Hver enhed bag gatewayen bruger gatewayens VPN-session. Endpointets autorisationsregler giver adgang til en bruger eller en gruppe, og fra tjenestens synspunkt er der præcis én bruger på den session. Lokal videresendelse ganger ikke den identitet op i godkendelse pr. enhed og udvider ikke enhedsposturundersøgelser til printeren i hjørnet.

Det kan være acceptabelt, eller det kan være grunden til, at designet afvises. Det afhænger af, hvad VPC-ressourcerne antager om, hvem der ringer. En delt identitet, der passer til autorisationsmodellen, er fin; en, der stille gør en enkelt godkendt session til adgang for hele LAN’et, er en iagttagelse, der venter på at blive skrevet.

Hvis kravet reelt er at forbinde et helt sted til en VPC, så sammenlign et understøttet site-til-site-design, før du udvider en fjernadgangsklient. Semantikken er forskellig, og en NAT’et klientsession er en dårlig erstatning for et stedlink, når VPC’en skal starte forbindelser ind i LAN’et.

Beslut klienten, ruten, oversættelsen og identitetshistorien i den rækkefølge. Hver begrænser den næste, og rækkefølgen forklarer, hvorfor værten virker, mens LAN’et ikke gør.