LAN iza jedne AWS Client VPN sesije: šta se prosljeđuje

Laptop se povezuje na AWS Client VPN endpoint, dolazi do privatne podmreže i sve izgleda zdravo. Desktop na istom LAN-u ne doseže ništa, iako Linux host također ima bridge interfejs i oba su računara na istoj žici. Ništa u tunelu nije pogrešno konfigurisano; dio koji nedostaje je rutiranje, a bridge je lažni trag.

Proširenje Client VPN sesije na LAN je uloga gatewaya. To nije Ethernet segment razvučen u upravljani servis.

Host radi, a LAN ne

Interfejs tunela na Linux mašini ima adresu unutar Client VPN klijentskog CIDR-a, a endpoint je poslao rute za VPC raspone. Zahtjev s te mašine je lokalno generisan saobraćaj: bira rutu, izlazi kroz tunel i dobija odgovor. Taj put nikada ne dira kod za prosljeđivanje, LAN interfejs ni bilo koje firewall pravilo koje upravlja tranzitom.

Saobraćaj s drugog LAN uređaja je drugačiji tok. Dolazi na LAN interfejs, treba rutu koja pokazuje u tunel, treba uključeno prosljeđivanje, treba firewall koji ga dozvoljava i treba da se odgovor vrati kroz isti host. Četiri zahtjeva, a radni test na laptopu ne dokazuje nijedan. S desktopa kvar izgleda čudno: tunel je aktivan, akreditivi važeći, a odredište jednostavno nikada ne odgovara. Defekt je lokalan za put prosljeđivanja gatewaya, ne za servis.

Nije svaki klijent gateway

AWS navodi da njegova Client VPN desktop aplikacija ne podržava IP prosljeđivanje, a da drugi klijenti mogu. To ograničenje odlučuje arhitekturu prije nego što se otkuca ijedna komanda. Ako je jedini dostupni klijent zvanična desktop aplikacija, Linux gateway koji prosljeđuje za LAN nije konfiguracija koju možete završiti, i nikakva količina maskiranja to neće promijeniti.

Zamjenski klijent također mora odgovarati metodi autentifikacije endpointa i politici koju namjeravate provoditi. Endpointi zasnovani na certifikatima, direktoriju i SAML-u ne prihvataju iste klijentske konfiguracije, a klijent treće strane koji se autentifikuje ali ignoriše poslane rute nije poboljšanje.

Tretirajte izbor klijenta kao dio pregleda dizajna. On određuje da li je obrazac LAN prosljeđivanja uopšte dostupan i određuje koji identitet endpoint vidi za svaki uređaj iza gatewaya. Zabilježite klijent i konfiguraciju endpointa prema kojoj je testiran. Zamjena klijenta šest mjeseci kasnije može tiho ukloniti mogućnost koju je dizajn pretpostavljao.

Usmjerite LAN u tunel i prevedite ga

Uz podržani klijent na mjestu, ostalo je običan gateway posao. LAN uređajima treba ruta za VPC raspon koja pokazuje na Linux host, a hostu treba uključeno prosljeđivanje. Ako želite da VPC vidi saobraćaj kao povezani klijent, a ne kao proizvoljnu LAN adresu, prevedite izvor na izlazu.

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

Ograničite pravilo na interfejs tunela i VPC raspon, kao gore, umjesto da maskirate sve što host prosljeđuje. Uže pravilo je lakše promisliti i ne mijenja tiho saobraćaj koji je trebao zadržati izvornu adresu.

Neka LAN ruta dolazi automatski ako možete: DHCP opcija, objava rutera ili statička ruta koju gura ono što upravlja LAN-om. Ruta koja postoji samo na jednoj testnoj mašini učiniće da dizajn izgleda pokvareno onog trenutka kad je neko drugi pokuša.

I odgovor treba put

Kada zahtjev dođe do VPC-a, odgovor se mora vratiti kroz ista stanja prevođenja i naći LAN rutu na gatewayu. Taj dio obično radi kada je pravilo maskiranja na mjestu, jer mapiranje živi na hostu koje ga je izvršilo. Puca kada na strani VPC-a postoji ruta koja šalje odgovor negdje drugdje, zbog čega su i ruta klijentskog CIDR-a i pridruživanje podmreže na endpointu važni.

Gledajte brojače, ne samo ping. Pravilo maskiranja s nula paketa govori vam da zahtjev nikada nije stigao do interfejsa tunela, što upućuje natrag na LAN rutu ili klijentovu vlastitu tabelu rutiranja. Pravilo s paketima ali bez odgovora upućuje na stranu VPC-a, pravila autorizacije ili sigurnosnu grupu koja ne prihvata prevedeni izvor. Čitajte oba smjera prije nego što bilo šta promijenite, jer broj koji raste samo na jednoj strani je jednosmjeran put, a ne spor.

Zapamtite da je endpoint upravljani servis. Nema serverske konfiguracijske datoteke za uređivanje ni client-config direktive za dodavanje, pa se uputstva napisana za samostalno upravljani OpenVPN server s prilagođenim rutama klijentskih podmreža ne prenose. Na AWS-u su poluge pridruživanje podmreže, pravila autorizacije i VPC tabele rutiranja.

Dijeljeni identitet je dio na koji politika mora odgovoriti

Svaki uređaj iza gatewaya koristi VPN sesiju gatewaya. Pravila autorizacije endpointa daju pristup korisniku ili grupi, a sa stanovišta servisa na toj sesiji je tačno jedan korisnik. Lokalno prosljeđivanje ne umnožava taj identitet u autentifikaciju po uređaju i ne proširuje provjere posture uređaja na printer u uglu.

To može biti prihvatljivo ili može biti razlog za odbijanje dizajna. Zavisi od toga šta VPC resursi pretpostavljaju o tome ko poziva. Dijeljeni identitet koji se uklapa u model autorizacije je u redu; onaj koji tiho pretvara jednu autentifikovanu sesiju u pristup cijelom LAN-u je nalaz koji čeka da bude napisan.

Ako je zahtjev zaista povezati cijelo gradilište na VPC, uporedite podržani dizajn lokacija-lokacija prije nego što proširite klijent za daljinski pristup. Semantika se razlikuje, a NAT-ovana klijentska sesija je loša zamjena za link lokacije kada VPC treba inicirati veze u LAN.

Odlučite klijenta, rutu, prevođenje i priču o identitetu tim redom. Svaki ograničava sljedeći, a red objašnjava zašto host radi dok LAN ne.