LAN yhden AWS Client VPN -istunnon takana: mitä välitetään

Kannettava tietokone yhdistää AWS Client VPN -päätepisteeseen, saavuttaa yksityisen aliverkon ja kaikki näyttää terveeltä. Saman LANin pöytätietokone ei tavoita mitään, vaikka Linux-isännällä on myös siltaliitäntä ja molemmat koneet ovat samassa kaapelissa. Tunnelissa ei ole mitään väärin konfiguroitu; puuttuva pala on reititys, ja silta on harhaanjohtava jälki.

Client VPN -istunnon laajentaminen LANiin on yhdyskäytävän rooli. Se ei ole hallittuun palveluun venytetty Ethernet-segmentti.

Isäntä toimii, LAN ei

Linux-koneen tunneliliitännällä on osoite Client VPN -asiakkaan CIDR:n sisällä, ja päätepiste on työntänyt reitit VPC-alueille. Koneella tehty pyyntö on paikallisesti luotua liikennettä: se valitsee reitin, lähtee tunnelin kautta ja saa vastauksen. Tämä polku ei koskaan kosketa välityskoodia, LAN-liitäntää eikä mitään transitoa ohjaavaa palomuurisääntöä.

Toisesta LAN-laitteesta tuleva liikenne on eri virtaus. Se saapuu LAN-liitäntään, tarvitsee tunneliin osoittavan reitin, tarvitsee käytössä olevan välityksen, tarvitsee palomuurin, joka sallii sen, ja tarvitsee vastauksen takaisin saman isännän kautta. Neljä vaatimusta, eikä toimiva kannettavatesti todista yhtäkään niistä. Pöytätietokoneelta vika näyttää kummalliselta: tunneli on ylhäällä, tunnistetiedot ovat voimassa, eikä kohde yksinkertaisesti koskaan vastaa. Vika on paikallinen yhdyskäytävän välityspolussa, ei palvelussa.

Jokainen asiakas ei voi olla yhdyskäytävä

AWS ilmoittaa, että sen Client VPN -työpöytäsovellus ei tue IP-välitystä ja että muut asiakkaat voivat tukea. Tämä rajoitus ratkaisee arkkitehtuurin ennen kuin yhtään komentoa kirjoitetaan. Jos ainoa käytettävissä oleva asiakas on virallinen työpöytäsovellus, LANille välittävä Linux-yhdyskäytävä ei ole kokoonpano, jonka voi saattaa valmiiksi, eikä mikään määrä masqueradingia muuta sitä.

Korvaavan asiakkaan on myös vastattava päätepisteen todennusmenetelmää ja käytäntöä, jonka aiot panna täytäntöön. Varmenteisiin, hakemistoon ja SAMLiin perustuvat päätepisteet eivät hyväksy samoja asiakasasetuksia, eikä kolmannen osapuolen asiakas, joka todentaa mutta jättää työnnetyt reitit huomiotta, ole parannus.

Käsittele asiakasvalintaa osana suunnittelukatsausta. Se ratkaisee, onko LAN-välitysmalli ylipäätään käytettävissä, ja sen, minkä identiteetin päätepiste näkee jokaiselle yhdyskäytävän takana olevalle laitteelle. Kirjaa asiakas ja päätepisteen kokoonpano, jota vasten sitä testattiin. Asiakkaan vaihto puolen vuoden päästä voi hiljaa poistaa kyvyn, jonka suunnittelu oletti.

Ohjaa LAN tunneliin ja käännä se

Kun tuettu asiakas on paikallaan, loput on tavallista yhdyskäytävätyötä. LAN-laitteet tarvitsevat VPC-aluetta koskevan reitin, joka osoittaa Linux-isäntään, ja isäntä tarvitsee käytössä olevan välityksen. Jos haluat VPC:n näkevän liikenteen yhdistettynä asiakkaana eikä mielivaltaisena LAN-osoitteena, käännä lähde ulospäin mentäessä.

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

Rajaa sääntö tunneliliitäntään ja VPC-alueeseen, kuten yllä, sen sijaan että masqueradeisit kaiken, mitä isäntä välittää. Kapeampi sääntö on helpompi perustella, eikä se hiljaa muuta liikennettä, jonka piti säilyttää alkuperäinen lähdeosoitteensa.

Anna LAN-reitin tulla automaattisesti, jos voit: DHCP-asetus, reitittimen ilmoitus tai staattinen reitti, jonka työntää se, mikä LANia hallitsee. Reitti, joka on olemassa vain yhdellä testikoneella, saa suunnittelun näyttämään rikkinäiseltä sinä hetkenä, kun joku muu kokeilee sitä.

Myös vastaus tarvitsee polun

Kun pyyntö saavuttaa VPC:n, vastauksen on palattava samojen käännöstilojen kautta ja löydettävä LAN-reitti yhdyskäytävältä. Tämä osa toimii yleensä, kun masquerade-sääntö on paikallaan, koska kartoitus elää isännällä, joka sen teki. Se hajoaa, kun VPC:n puolella on reitti, joka lähettää vastauksen muualle; siksi sekä asiakkaan CIDR-reitti että aliverkkoliitos päätepisteessä ovat tärkeitä.

Seuraa laskureita, älä vain pingiä. Masquerade-sääntö, jossa on nolla pakettia, kertoo, että pyyntö ei koskaan saavuttanut tunneliliitäntää, mikä viittaa takaisin LAN-reittiin tai asiakkaan omaan reititystauluun. Sääntö, jossa on paketteja mutta ei vastauksia, viittaa VPC:n puoleen, valtuutussääntöihin tai tietoturvaryhmään, joka ei hyväksy käännettyä lähdettä. Lue molemmat suunnat ennen kuin muutat mitään, koska vain toisella puolella kasvava luku on yksisuuntainen polku eikä hidas.

Muista, että päätepiste on hallittu palvelu. Palvelinkokoonpanotiedostoa ei ole muokattavaksi eikä client-config-direktiiviä lisättäväksi, joten itse hallitulle OpenVPN-palvelimelle, jossa on mukautetut asiakkaan aliverkkoreitit, kirjoitetut ohjeet eivät siirry. AWS:ssä vivut ovat aliverkkoliitos, valtuutussäännöt ja VPC:n reititystaulut.

Jaettu identiteetti on se osa, johon käytännön on vastattava

Jokainen yhdyskäytävän takana oleva laite käyttää yhdyskäytävän VPN-istuntoa. Päätepisteen valtuutussäännöt myöntävät pääsyn käyttäjälle tai ryhmälle, ja palvelun näkökulmasta istunnossa on täsmälleen yksi käyttäjä. Paikallinen välitys ei monista tätä identiteettiä laitekohtaiseksi todennukseksi eikä laajenna laitteen postuuritarkistuksia kulman tulostimeen.

Se voi olla hyväksyttävää, tai se voi olla syy suunnittelun hylkäämiseen. Se riippuu siitä, mitä VPC-resurssit olettavat soittajasta. Valtuutusmalliin sopiva jaettu identiteetti on kunnossa; se, joka hiljaa muuttaa yhden todennetun istunnon koko LANin pääsyksi, on havainto, joka odottaa kirjoittamista.

Jos vaatimus on todella kytkeä koko toimipaikka VPC:hen, vertaa tuettua toimipaikka-toimipaikka-suunnittelua ennen etäkäyttöasiakkaan laajentamista. Semantiikka eroaa, ja NATattu asiakasistunto on huono korvike toimipaikkalinkille, kun VPC:n on aloitettava yhteydet LANiin.

Päätä asiakas, reitti, käännös ja identiteettitarina tässä järjestyksessä. Jokainen rajoittaa seuraavaa, ja järjestys selittää, miksi isäntä toimii, kun taas LAN ei.