LAN ühe AWS Client VPN sessiooni taga: mida edasi suunatakse

Sülearvuti ühendub AWS Client VPN lõpp-punktiga, jõuab privaatsesse alamvõrku ja kõik näeb terve välja. Samas LAN-is olev töölaud ei jõua mitte kuhugi, kuigi Linuxi hostil on ka silla liides ja mõlemad masinad on sama kaabli otsas. Tunnelis pole miski valesti seadistatud; puuduv tükk on marsruutimine ja sild on eksitav jälg.

Client VPN sessiooni laiendamine LAN-ile on lüüsi roll. See ei ole Etherneti segment, mis on venitatud hallatavasse teenusesse.

Host töötab, LAN aga mitte

Linuxi masina tunneli liidesel on aadress Client VPN kliendi CIDR-i sees ja lõpp-punkt on lükanud VPC vahemike jaoks marsruudid. Sellel masinal tehtud päring on kohapeal genereeritud liiklus: see valib marsruudi, väljub tunnelist ja saab vastuse. See tee ei puuduta kunagi edasisuunamise koodi, LAN-i liidest ega ühtegi tulemüüri reeglit, mis transitit reguleerib.

Teisest LAN-seadmest tulev liiklus on erinev voog. See saabub LAN-i liidesele, vajab tunnelisse osutavat marsruuti, vajab lubatud edasisuunamist, vajab tulemüüri, mis seda lubab, ja vajab, et vastus tuleks tagasi sama hosti kaudu. Neli nõuet ja töötav sülearvuti test ei tõesta neist ühtegi. Tööalauast näeb rike kummaline välja: tunnel on üleval, volitused on kehtivad ja sihtkoht lihtsalt ei vasta kunagi. Defekt on lokaalne lüüsi edasisuunamise teel, mitte teenuses.

Iga klient ei saa olla lüüs

AWS märgib, et tema Client VPN töölauarakendus ei toeta IP edasisuunamist ja et teised kliendid võivad seda teha. See piirang otsustab arhitektuuri enne, kui ükski käsk on trükitud. Kui ainus saadaolev klient on ametlik töölauarakendus, ei ole LAN-i jaoks edasi suunav Linuxi lüüs seadistus, mille saate valmis teha, ja ükski masquerading ei muuda seda.

Asendusklient peab vastama ka lõpp-punkti autentimismeetodile ja poliitikale, mida kavatsete rakendada. Sertifikaatidel, kataloogil ja SAML-il põhinevad lõpp-punktid ei võta vastu samu kliendiseadistusi ning kolmanda osapoole klient, mis autendib end, kuid eirab lükatud marsruute, ei ole parendus.

Käsitlege kliendi valikut disaini ülevaatamise osana. See määrab, kas LAN-i edasisuunamise muster on üldse saadaval, ja määrab, millist identiteeti näeb lõpp-punkt iga lüüsi taga oleva seadme puhul. Kirjutage üles klient ja lõpp-punkti seadistus, mille vastu seda testiti. Kliendi vahetamine poole aasta pärast võib vaikselt eemaldada võimekuse, mida disain eeldas.

Suunake LAN tunnelisse ja tõlkige see

Kui toetatud klient on paigas, on ülejäänu tavaline lüüsi töö. LAN-seadmed vajavad VPC vahemiku jaoks marsruuti, mis osutab Linuxi hostile, ja host vajab lubatud edasisuunamist. Kui soovite, et VPC näeks liiklust ühendatud kliendina, mitte suvalise LAN-aadressina, tõlkige allikas väljumisel.

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

Piiritlege reegel tunneli liidese ja VPC vahemikuga, nagu ülal, selle asemel et masquerading kõike, mida host edasi suunab. Kitsam reegel on lihtsam mõista ja see ei muuda vaikselt liiklust, mis pidi säilitama oma algse lähteaadressi.

Laske LAN-i marsruudil tulla automaatselt, kui saate: DHCP valik, ruuteri teadaanne või staatiline marsruut, mille lükkab see, mis LAN-i haldab. Marsruut, mis on olemas ainult ühes testmasinas, paneb disaini katkise välja nägema hetkel, mil keegi teine seda proovib.

Ka vastus vajab teed

Kui päring on jõudnud VPC-sse, peab vastus tulema tagasi samade tõlkeseisundite kaudu ja leidma lüüsilt LAN-i marsruudi. See osa töötab tavaliselt siis, kui masquerade reegel on paigas, sest vastendus elab hostil, mis selle tegi. See katkeb, kui VPC poolel on marsruut, mis saadab vastuse mujale, mistõttu on olulised nii kliendi CIDR-i marsruut kui ka alamvõrgu sidumine lõpp-punktis.

Jälgige loendureid, mitte ainult pingi. Null paketiga masquerade reegel ütleb teile, et päring ei jõudnud kunagi tunneli liidesele, mis osutab tagasi LAN-i marsruudile või kliendi enda marsruutimistabelile. Reegel, millel on paketid, kuid pole vastuseid, osutab VPC poolele, autoriseerimisreeglitele või turbegrupile, mis ei võta tõlgitud allikat vastu. Lugege mõlemat suunda enne millegi muutmist, sest ainult ühel pool kasvav arv tähendab ühesuunalist teed, mitte aeglast.

Pidage meeles, et lõpp-punkt on hallatav teenus. Serveri konfiguratsioonifaili pole redigeerida ja client-config direktiivi pole lisada, seega ise hallatava OpenVPN serveri jaoks kohandatud kliendi alamvõrgu marsruutidega kirjutatud juhised ei kandu üle. AWS-is on hoovad alamvõrgu sidumine, autoriseerimisreeglid ja VPC marsruutimistabelid.

Jagatud identiteet on osa, millele poliitika peab vastama

Iga seade lüüsi taga kasutab lüüsi VPN sessiooni. Lõpp-punkti autoriseerimisreeglid annavad juurdepääsu kasutajale või grupile ja teenuse vaatenurgast on selles sessioonis täpselt üks kasutaja. Kohalik edasisuunamine ei korruta seda identiteeti seadmepõhiseks autentimiseks ega laienda seadme postuuri kontrolle nurgas oleva printerini.

See võib olla vastuvõetav või olla põhjus, miks disain tagasi lükatakse. See sõltub sellest, mida VPC ressursid eeldavad selle kohta, kes helistab. Autoriseerimismudelisse sobiv jagatud identiteet on korras; see, mis muudab vaikselt ühe autenditud sessiooni kogu LAN-i juurdepääsuks, on leid, mis ootab kirjutamist.

Kui nõue on tõesti ühendada terve asukoht VPC-ga, võrrelge toetatud saidi-saidi disaini enne, kui laiendate kaugjuurdepääsu klienti. Semantika erineb ja NAT-itud kliendisessioon on halb asendus saidilingile, kui VPC peab algatama ühendusi LAN-i.

Otsustage klient, marsruut, tõlkimine ja identiteedi lugu selles järjekorras. Igaüks piirab järgmist ja järjekord selgitab, miks host töötab, samal ajal kui LAN ei tööta.