Nešiojamasis kompiuteris prisijungia prie AWS Client VPN galinio taško, pasiekia privatų potinklį, ir viskas atrodo sveika. Darbalaukis tame pačiame LAN nepasiekia nieko, nors Linux hostas taip pat turi tilto sąsają ir abi mašinos yra tame pačiame kabelyje. Tunele niekas nesukonfigūruota neteisingai; trūkstama dalis yra maršrutizavimas, o tiltas yra klaidingas pėdsakas.

Client VPN sesijos išplėtimas į LAN yra tinklų sietuvos vaidmuo. Tai ne Ethernet segmentas, ištemptas į valdomą paslaugą.

Hostas veikia, o LAN – ne

Linux mašinos tunelio sąsaja turi adresą Client VPN kliento CIDR viduje, o galinis taškas nusiuntė maršrutus VPC diapazonams. Užklausa toje mašinoje yra vietoje sugeneruotas srautas: ji pasirenka maršrutą, išeina per tunelį ir gauna atsakymą. Tas kelias niekada neliečia persiuntimo kodo, LAN sąsajos ar bet kokios ugniasienės taisyklės, valdančios tranzitą.

Srautas iš kito LAN įrenginio yra kitas srautas. Jis atvyksta į LAN sąsają, jam reikia maršruto, nukreipto į tunelį, reikia įjungto persiuntimo, reikia ugniasienės, kuri jį leidžia, ir reikia, kad atsakymas grįžtų per tą patį hostą. Keturi reikalavimai, o veikiantis nešiojamojo kompiuterio testas neįrodo nė vieno. Iš darbalaukio gedimas atrodo keistai: tunelis veikia, kredencialai galioja, o paskirties vieta tiesiog niekada neatsako. Defektas yra vietinis tinklų sietuvos persiuntimo kelyje, ne paslaugoje.

Ne kiekvienas klientas gali būti tinklų sietuva

AWS nurodo, kad jos Client VPN darbalaukio programa nepalaiko IP persiuntimo, o kiti klientai gali palaikyti. Šis apribojimas nulemia architektūrą prieš įvedant bet kokią komandą. Jei vienintelis pasiekiamas klientas yra oficiali darbalaukio programa, Linux tinklų sietuva, persiunčianti LAN, nėra konfigūracija, kurią galite užbaigti, ir joks masquerading to nepakeis.

Pakaitinis klientas taip pat turi atitikti galinio taško autentifikavimo metodą ir politiką, kurią ketinate taikyti. Galiniai taškai, pagrįsti sertifikatais, katalogu ir SAML, nepriima tų pačių kliento konfigūracijų, o trečiosios šalies klientas, kuris autentifikuojasi, bet ignoruoja nusiųstus maršrutus, nėra patobulinimas.

Kliento pasirinkimą traktuokite kaip dizaino peržiūros dalį. Jis nulemia, ar LAN persiuntimo modelis apskritai prieinamas, ir nulemia, kokį tapatumą galinis taškas mato kiekvienam įrenginiui už tinklų sietuvos. Užrašykite klientą ir galinio taško konfigūraciją, pagal kurią jis buvo testuotas. Kliento pakeitimas po pusmečio gali tyliai pašalinti galimybę, kurią dizainas numatė.

Nukreipkite LAN į tunelį ir išverskite jį

Turint palaikomą klientą, likusi dalis yra įprastas tinklų sietuvos darbas. LAN įrenginiams reikia maršruto VPC diapazonui, nukreipto į Linux hostą, o hostui reikia įjungto persiuntimo. Jei norite, kad VPC matytų srautą kaip prisijungusį klientą, o ne kaip savavališką LAN adresą, išverskite šaltinį išeinant.

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

Apribokite taisyklę tunelio sąsaja ir VPC diapazonu, kaip nurodyta aukščiau, o ne maskuokite viską, ką hostas persiunčia. Siauresnė taisyklė yra lengviau apmąstoma, ir ji tyliai nekeičia srauto, kuris turėjo išlaikyti savo pradinį šaltinio adresą.

Leiskite LAN maršrutui atsirasti automatiškai, jei galite: DHCP parinktis, maršrutizatoriaus skelbimas arba statinis maršrutas, kurį siunčia tai, kas valdo LAN. Maršrutas, egzistuojantis tik vienoje testavimo mašinoje, privers dizainą atrodyti sugedusiu tą akimirką, kai kas nors kitas jį išbandys.

Atsakymui taip pat reikia kelio

Kai užklausa pasiekia VPC, atsakymas turi grįžti per tas pačias vertimo būsenas ir rasti LAN maršrutą tinklų sietuvoje. Ši dalis paprastai veikia, kai masquerade taisyklė yra vietoje, nes susiejimas gyvena hoste, kuris jį atliko. Ji lūžta, kai VPC pusėje yra maršrutas, siunčiantis atsakymą kitur, todėl svarbūs ir kliento CIDR maršrutas, ir potinklio priskyrimas galiniame taške.

Stebėkite skaitiklius, ne tik ping. Masquerade taisyklė su nuliu paketų pasako, kad užklausa niekada nepasiekė tunelio sąsajos, o tai nurodo LAN maršrutą arba paties kliento maršrutizavimo lentelę. Taisyklė su paketais, bet be atsakymų, nurodo VPC pusę, autorizacijos taisykles arba saugos grupę, kuri nepriima išversto šaltinio. Prieš ką nors keisdami skaitykite abi kryptis, nes skaičius, augantis tik vienoje pusėje, yra vienkryptis kelias, o ne lėtas.

Atminkite, kad galinis taškas yra valdoma paslauga. Nėra serverio konfigūracijos failo, kurį būtų galima redaguoti, ir nėra client-config direktyvos, kurią būtų galima pridėti, todėl instrukcijos, parašytos savarankiškai valdomam OpenVPN serveriui su pasirinktiniais kliento potinklio maršrutais, neperkeliamos. AWS svirtys yra potinklio priskyrimas, autorizacijos taisyklės ir VPC maršrutizavimo lentelės.

Bendras tapatumas yra dalis, į kurią politika turi atsakyti

Kiekvienas įrenginys už tinklų sietuvos naudoja tinklų sietuvos VPN sesiją. Galinio taško autorizacijos taisyklės suteikia prieigą naudotojui arba grupei, ir paslaugos požiūriu toje sesijoje yra lygiai vienas naudotojas. Vietinis persiuntimas nepadaugina šio tapatumo į autentifikavimą pagal įrenginį ir neišplečia įrenginio būsenos patikrų į kampelyje esantį spausdintuvą.

Tai gali būti priimtina, arba tai gali būti priežastis, kodėl dizainas atmetamas. Tai priklauso nuo to, ką VPC ištekliai daro prielaidą apie tai, kas skambina. Bendras tapatumas, kuris dera su autorizacijos modeliu, yra gerai; tas, kuris tyliai paverčia vieną autentifikuotą sesiją prieiga prie viso LAN, yra radinys, laukiantis parašymo.

Jei reikalavimas iš tikrųjų yra prijungti visą vietą prie VPC, palyginkite palaikomą vietos į vietą dizainą prieš išplėsdami nuotolinės prieigos klientą. Semantika skiriasi, o NAT-uota kliento sesija yra prastas vietos ryšio pakaitalas, kai VPC turi inicijuoti ryšius į LAN.

Nuspręskite klientą, maršrutą, vertimą ir tapatumo istoriją šia tvarka. Kiekvienas apriboja kitą, o tvarka paaiškina, kodėl hostas veikia, o LAN – ne.

Susiję straipsniai