LAN agter een AWS Client VPN-sessie: wat deurgestuur word

Die skootrekenaar koppel aan die AWS Client VPN-eindpunt, bereik die privaat subnet, en alles lyk gesond. Die rekenaar op dieselfde LAN kan niks bereik nie, al het die Linux-gasheer ook ’n brugkoppelvlak en is albei masjiene op dieselfde draad. Niks is verkeerd opgestel in die tonnel nie; die ontbrekende stuk is roetering, en die brug is ’n misleiding.

Om ’n Client VPN-sessie na ’n LAN uit te brei is ’n deurgangsrol. Dit is nie ’n Ethernet-segment wat in ’n bestuurde diens uitgerek word nie.

Die gasheer werk en die LAN nie

Die tonnelkoppelvlak op die Linux-boks het ’n adres binne die Client VPN-klient-CIDR, en die eindpunt het roetes vir die VPC-reekse gestoot. ’n Versoek wat op daardie boks gemaak word, is plaaslik gegenereerde verkeer: dit kies ’n roete, verlaat deur die tonnel en kry ’n antwoord. Daardie pad raak nooit die deurstuurkode, die LAN-koppelvlak of enige firewallreël wat deurverkeer beheer nie.

Verkeer van ’n ander LAN-toestel is ’n ander vloei. Dit kom op die LAN-koppelvlak aan, het ’n roete nodig wat in die tonnel in wys, het deurstuur geaktiveer nodig, het ’n firewall nodig wat dit toelaat, en het nodig dat die antwoord deur dieselfde gasheer terugkom. Vier vereistes, en die werkende skootrekenaartoets bewys nie een daarvan nie. Vanaf die rekenaar lyk die fout bisar: die tonnel is op, die geloofsbriewe is geldig, en die bestemming antwoord eenvoudig nooit. Die gebrek is plaaslik by die deurgang se deurstuurpad, nie by die diens nie.

Nie elke kliënt kan ’n deurgang wees nie

AWS sê dat sy Client VPN-rekenaartoepassing nie IP-deurstuur ondersteun nie, en dat ander kliënte dit wel kan. Daardie beperking bepaal die argitektuur voordat enige opdrag getik word. As die enigste beskikbare kliënt die amptelike rekenaartoepassing is, is ’n Linux-deurgang wat vir die LAN deurstuur nie ’n opset wat jy kan voltooi nie, en geen hoeveelheid masquerading sal dit verander nie.

Die vervangingskliënt moet ook by die eindpunt se verifikasiemetode en die beleid wat jy wil afdwing, pas. Sertifikaatgebaseerde, gidsgebaseerde en SAML-gedraagde eindpunte aanvaar nie dieselfde kliëntopsette nie, en ’n derdeparty-kliënt wat verifieer maar die gestote roetes ignoreer, is nie ’n verbetering nie.

Behandel die kliëntkeuse as deel van die ontwerphersiening. Dit bepaal of die LAN-deurstuurpatroon hoegenaamd beskikbaar is, en dit bepaal watter identiteit die eindpunt vir elke toestel agter die deurgang sien. Teken die kliënt en die eindpuntopset aan waarteen dit getoets is. ’n Kliëntvervanging ses maande later kan die vermoë wat die ontwerp aanvaar het, stilweg verwyder.

Lei die LAN na die tonnel en vertaal dit

Met ’n ondersteunde kliënt in plek is die res gewone deurgangswerk. Die LAN-toestelle het ’n roete vir die VPC-reeks nodig wat na die Linux-gasheer wys, en die gasheer het deurstuur geaktiveer nodig. As jy wil hê die VPC moet die verkeer as die gekoppelde kliënt sien eerder as as ’n willekeurige LAN-adres, vertaal die bron op pad uit.

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

Beperk die reël tot die tonnelkoppelvlak en die VPC-reeks, soos hierbo, eerder as om alles te masquerade wat die gasheer deurstuur. Die nouer reël is makliker om oor te redeneer, en dit verander nie stilweg verkeer wat veronderstel was om sy oorspronklike bronadres te behou nie.

Laat die LAN-roete outomaties kom as jy kan: ’n DHCP-opsie, ’n routeraankondiging, of ’n statiese roete wat deur wat die LAN bestuur, gestoot word. ’n Roete wat net op een toetsmasjien bestaan, sal die ontwerp laat lyk of dit gebreek is die oomblik wanneer iemand anders dit probeer.

Die antwoord het ook ’n pad nodig

Sodra die versoek die VPC bereik, moet die antwoord deur dieselfde vertaalingstoestande terugkom en die LAN-roete op die deurgang vind. Daardie deel werk gewoonlik wanneer die masquerade-reël in plek is, want die kartering leef op die gasheer wat dit gedoen het. Dit breek wanneer die VPC-kant ’n roete het wat die antwoord elders heen stuur, en daarom is die klient-CIDR-roete en die subnetassosiasie op die eindpunt albei belangrik.

Kyk na die tellers, nie net na die ping nie. ’n Masquerade-reël met nul pakkette sê vir jou die versoek het nooit die tonnelkoppelvlak bereik nie, wat terugwys na die LAN-roete of die kliënt se eie roetertabel. ’n Reël met pakkette maar geen antwoorde wys na die VPC-kant, die magtigingsreëls, of ’n sekuriteitsgroep wat nie die vertaalde bron aanvaar nie. Lees albei rigtings voordat jy iets verander, want ’n telling wat net aan een kant groei, is ’n eenrigtingpad eerder as ’n stadige een.

Onthou die eindpunt is ’n bestuurde diens. Daar is geen bedienerkonfigurasielêer om te wysig nie en geen client-config-opdrag om by te voeg nie, so instruksies wat vir ’n selfbestuurde OpenVPN-bediener met pasgemaakte kliëntsubnetroetes geskryf is, dra nie oor nie. Op AWS is die hefbome subnetassosiasie, magtigingsreëls en die VPC-roetertabelle.

Gedeelde identiteit is die deel wat beleid moet antwoord

Elke toestel agter die deurgang gebruik die deurgang se VPN-sessie. Die eindpunt se magtigingsreëls verleen toegang aan ’n gebruiker of ’n groep, en vanuit die diens se oogpunt is daar presies een gebruiker op daardie sessie. Plaaslike deurstuur vermenigvuldig nie daardie identiteit in per-toestel-verifikasie nie, en dit brei nie toestelpostuurkontroles uit na die drukker in die hoek nie.

Dit mag aanvaarbaar wees, of dit mag die rede wees waarom die ontwerp verwerp word. Dit hang af van wat die VPC-hulpbronne aanneem oor wie bel. ’n Gedeelde identiteit wat by die magtigingsmodel pas, is reg; een wat stilweg ’n enkele geauthentiseerde sessie in LAN-wye toegang verander, is ’n bevinding wat wag om geskryf te word.

As die vereiste werklik is om ’n hele terrein aan ’n VPC te koppel, vergelyk ’n ondersteunde werf-tot-werf-ontwerp voordat jy ’n afstandstoegangskliënt uitbrei. Die semantiek verskil, en ’n NAT-agtige kliëntsessie is ’n swak plaasvervanger vir ’n werfskakel wanneer die VPC verbindings in die LAN moet inisieer.

Besluit die kliënt, die roete, die vertaling en die identiteitsverhaal in daardie volgorde. Elkeen beperk die volgende, en die volgorde verduidelik waarom die gasheer werk terwyl die LAN nie.