LAN malantaŭ unu AWS Client VPN-sesio: kio estas plusendata

La tekkomputilo konektiĝas al la AWS Client VPN-finpunkto, atingas la privatan subreton, kaj ĉio aspektas sana. La surtabla komputilo en la sama LAN ne atingas ion ajn, kvankam la Linux-gastiganto ankaŭ havas pontan interfacon kaj ambaŭ maŝinoj estas sur la sama kablo. Nenio misagordiĝis en la tunelo; la mankanta peco estas enkursigo, kaj la ponto estas falsa spuro.

Etendi Client VPN-sesion al LAN estas enireja rolo. Ĝi ne estas Ethernet-segmento streĉita en administritan servon.

La gastiganto funkcias kaj la LAN ne

La tunela interfaco sur la Linux-maŝino havas adreson ene de la CIDR de la Client VPN-kliento, kaj la finpunkto puŝis vojojn por la VPC-gamoj. Peto farita sur tiu maŝino estas loke generita trafiko: ĝi elektas vojon, eliras tra la tunelo kaj ricevas respondon. Tiu vojo neniam tuŝas la plusendan kodon, la LAN-interfacon aŭ ajnan fajroŝrman regulon, kiu regas transiton.

Trafiko de alia LAN-aparato estas alia fluo. Ĝi alvenas sur la LAN-interfacon, bezonas vojon montrantan en la tunelon, bezonas ŝaltitan plusendadon, bezonas fajroŝrman, kiu permesas ĝin, kaj bezonas, ke la respondo revenu tra la sama gastiganto. Kvar postuloj, kaj la funkcianta tekkomputila testo pruvas neniun. De la surtabla komputilo la fiasko aspektas stranga: la tunelo estas aktiva, la akreditaĵoj validas, kaj la celo simple neniam respondas. La difekto estas loka al la plusenda vojo de la enirejo, ne al la servo.

Ne ĉiu kliento povas esti enirejo

AWS deklaras, ke ĝia surtabla aplikaĵo Client VPN ne subtenas IP-plusendadon, kaj ke aliaj klientoj eble subtenas. Tiu limigo decidas la arkitekturon antaŭ ol iu komando estas tajpita. Se la sola disponebla kliento estas la oficiala surtabla aplikaĵo, Linux-enirejo plusendanta por la LAN ne estas agordo, kiun vi povas fini, kaj nenia kvanto da masquerading ŝanĝos tion.

La anstataŭa kliento ankaŭ devas kongrui kun la aŭtentiga metodo de la finpunkto kaj la politiko, kiun vi intencas plenumi. Finpunktoj bazitaj sur atestiloj, dosierujo kaj SAML ne akceptas la samajn klientajn agordojn, kaj triaparta kliento, kiu aŭtentigas sed ignoras la puŝitajn vojojn, ne estas plibonigo.

Traktu la klientan elekton kiel parton de la dezajna revizio. Ĝi decidas, ĉu la LAN-plusenda ŝablono entute disponeblas, kaj decidas, kian identecon la finpunkto vidas por ĉiu aparato malantaŭ la enirejo. Notu la klienton kaj la finpunktan agordon, kontraŭ kiu ĝi estis testita. Klienta anstataŭigo ses monatojn poste povas silente forigi la kapablon, kiun la dezajno supozis.

Direktu la LAN-on al la tunelo kaj traduku ĝin

Kun subtenata kliento en loko, la resto estas ordinara enireja laboro. La LAN-aparatoj bezonas vojon por la VPC-gamo montrantan al la Linux-gastiganto, kaj la gastiganto bezonas ŝaltitan plusendadon. Se vi volas, ke la VPC vidu la trafikon kiel la konektita kliento anstataŭ kiel arbitran LAN-adreson, traduku la fonton ĉe la eliro.

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

Limigu la regulon al la tunela interfaco kaj la VPC-gamo, kiel supre, anstataŭ masquerading ĉion, kion la gastiganto plusendas. La pli mallarĝa regulo estas pli facile pripensebla, kaj ĝi ne silente ŝanĝas trafikon, kiu devis konservi sian originan fontadreson.

Igu la LAN-vojon alveni aŭtomate se vi povas: DHCP-opcio, enkursiga anonco aŭ statika vojo puŝita de tio, kio administras la LAN-on. Vojo, kiu ekzistas nur sur unu testa maŝino, igos la dezajnon aspekti rompita en la momento, kiam iu alia provos ĝin.

Ankaŭ la respondo bezonas vojon

Post kiam la peto atingas la VPC-on, la respondo devas reveni tra la samaj tradukaj statoj kaj trovi la LAN-vojon sur la enirejo. Tiu parto kutime funkcias, kiam la masquerade-regulo estas en loko, ĉar la mapado vivas sur la gastiganto, kiu ĝin faris. Ĝi rompiĝas, kiam la VPC-flanko havas vojon, kiu sendas la respondon aliloken; tial kaj la klienta CIDR-vojo kaj la subreta aliĝo sur la finpunkto gravas.

Observu la nombrilojn, ne nur la ping. Masquerade-regulo kun nul pakaĵoj diras al vi, ke la peto neniam atingis la tunelan interfacon, kio montras reen al la LAN-vojo aŭ al la propra enkursiga tabelo de la kliento. Regulo kun pakaĵoj sed sen respondoj montras al la VPC-flanko, la rajtigaj reguloj aŭ sekureca grupo, kiu ne akceptas la tradukitan fonton. Legu ambaŭ direktojn antaŭ ol ŝanĝi ion, ĉar nombro, kiu kreskas nur unuflanke, estas unudirekta vojo, ne malrapida.

Memoru, ke la finpunkto estas administrita servo. Ne ekzistas servila agorda dosiero por redakti kaj neniu client-config-direktivo por aldoni, do instrukcioj skribitaj por mem-administrata OpenVPN-servilo kun propraj klientaj subretaj vojoj ne transiĝas. En AWS la leviloj estas subreta aliĝo, rajtigaj reguloj kaj la enkursigaj tabeloj de la VPC.

Komuna identeco estas la parto, kiun politiko devas respondi

Ĉiu aparato malantaŭ la enirejo uzas la VPN-sesion de la enirejo. La rajtigaj reguloj de la finpunkto donas aliron al uzanto aŭ grupo, kaj el la vidpunkto de la servo estas ekzakte unu uzanto en tiu sesio. Loka plusendado ne multobligas tiun identecon en po-aparatan aŭtentigon, kaj ĝi ne etendas aparatajn poŝturajn kontrolojn al la printilo en la angulo.

Tio povas esti akceptebla, aŭ ĝi povas esti la kialo, ke la dezajno estas malakceptita. Ĝi dependas de tio, kion la VPC-rimedoj supozas pri tio, kiu vokas. Komuna identeco, kiu konvenas al la rajtiga modelo, estas en ordo; unu, kiu silente transformas unu aŭtentigitan sesion en tut-LAN-an aliron, estas trovo atendantanta esti skribita.

Se la postulo vere estas konekti tutan ejon al VPC, komparu subtenatan ej-al-ejan dezajnon antaŭ ol etendi fora-aliran klienton. La semantiko malsamas, kaj NAT-ita klienta sesio estas malbona anstataŭaĵo por eja ligilo, kiam la VPC devas iniciati konektojn en la LAN-on.

Decidu la klienton, la vojon, la tradukadon kaj la identecan rakonton en tiu ordo. Ĉiu limigas la sekvan, kaj la ordo klarigas, kial la gastiganto funkcias dum la LAN ne.