LAN za eno sejo AWS Client VPN: kaj se posreduje

Prenosnik se poveže s končno točko AWS Client VPN, doseže zasebno podomrežje in vse je videti zdravo. Namizje v istem LAN ne doseže ničesar, čeprav ima gostitelj Linux tudi vmesnik mostu in sta oba stroja na istem kablu. V tunelu ni nič napačno nastavljeno; manjkajoči del je usmerjanje, most pa je lažna sled.

Razširitev seje Client VPN na LAN je vloga prehoda. To ni segment Ethernet, raztegnjen v upravljano storitev.

Gostitelj deluje, LAN pa ne

Vmesnik tunela na stroju Linux ima naslov znotraj CIDR odjemalca Client VPN, končna točka pa je potisnila poti za obsege VPC. Zahteva na tem stroju je lokalno ustvarjen promet: izbere pot, odide skozi tunel in prejme odgovor. Ta pot se nikoli ne dotakne kode za posredovanje, vmesnika LAN ali katerega koli pravila požarnega zidu, ki ureja tranzit.

Promet z druge naprave v LAN je drug tok. Prispe na vmesnik LAN, potrebuje pot, ki kaže v tunel, potrebuje omogočeno posredovanje, potrebuje požarni zid, ki ga dovoli, in potrebuje, da se odgovor vrne skozi isti gostitelj. Štiri zahteve, in delujoč test na prenosniku ne dokaže nobene. Z namizja je napaka videti čudna: tunel je pokonci, poverilnice so veljavne, cilj pa preprosto nikoli ne odgovori. Napaka je lokalna na poti posredovanja prehoda, ne v storitvi.

Ni vsak odjemalec lahko prehod

AWS navaja, da njegova namizna aplikacija Client VPN ne podpira posredovanja IP, drugi odjemalci pa ga morda. Ta omejitev odloči arhitekturo, preden je vpisan kateri koli ukaz. Če je edini razpoložljivi odjemalec uradna namizna aplikacija, prehod Linux, ki posreduje za LAN, ni konfiguracija, ki bi jo lahko dokončali, in nobena količina masquerading tega ne spremeni.

Nadomestni odjemalec se mora ujemati tudi z metodo preverjanja končne točke in politiko, ki jo nameravate uveljaviti. Končne točke, ki temeljijo na potrdilih, imeniku in SAML, ne sprejmejo enakih konfiguracij odjemalca, odjemalec tretje strani, ki se preveri, a ignorira potisnjene poti, pa ni izboljšava.

Izbira odjemalca naj bo del pregleda zasnove. Določa, ali je vzorec posredovanja LAN sploh na voljo, in določa, kakšno identiteto končna točka vidi za vsako napravo za prehodom. Zabeležite odjemalca in konfiguracijo končne točke, proti kateri je bil testiran. Zamenjava odjemalca pol leta kasneje lahko tiho odstrani zmožnost, ki jo je zasnova predpostavljala.

Usmerite LAN v tunel in ga prevedite

S podprtim odjemalcem na mestu je preostanek običajno delo prehoda. Naprave LAN potrebujejo pot za obseg VPC, ki kaže na gostitelja Linux, gostitelj pa potrebuje omogočeno posredovanje. Če želite, da VPC vidi promet kot povezanega odjemalca in ne kot poljuben naslov LAN, prevedite vir na izhodu.

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

Omejite pravilo na vmesnik tunela in obseg VPC, kot zgoraj, namesto da maskirate vse, kar gostitelj posreduje. Ožje pravilo je lažje premisliti in tiho ne spremeni prometa, ki bi moral obdržati prvotni naslov vira.

Pustite, da pot LAN pride samodejno, če lahko: možnost DHCP, objava usmerjevalnika ali statična pot, ki jo potisne tisto, kar upravlja LAN. Pot, ki obstaja le na enem testnem stroju, bo zasnovo naredila videti pokvarjeno v trenutku, ko jo bo poskusil nekdo drug.

Tudi odgovor potrebuje pot

Ko zahteva doseže VPC, se mora odgovor vrniti skozi ista stanja prevajanja in najti pot LAN na prehodu. Ta del običajno deluje, ko je pravilo masquerade na mestu, ker preslikava živi na gostitelju, ki jo je izvedel. Zlomi se, ko ima stran VPC pot, ki pošlje odgovor drugam, zato sta pomembna tako pot CIDR odjemalca kot povezava podomrežja na končni točki.

Opazujte števce, ne le ping. Pravilo masquerade z nič paketi vam pove, da zahteva nikoli ni dosegla vmesnika tunela, kar kaže nazaj na pot LAN ali na lastno usmerjevalno tabelo odjemalca. Pravilo s paketi, a brez odgovorov, kaže na stran VPC, pravila dovoljenj ali varnostno skupino, ki ne sprejme prevedenega vira. Berite obe smeri, preden karkoli spremenite, ker je število, ki raste le na eni strani, enosmerna pot in ne počasna.

Ne pozabite, da je končna točka upravljana storitev. Ni konfiguracijske datoteke strežnika za urejanje niti direktive client-config za dodajanje, zato se navodila, napisana za samostojno upravljan strežnik OpenVPN s prilagojenimi potmi odjemalskega podomrežja, ne prenesejo. V AWS so vzvodi povezava podomrežja, pravila dovoljenj in usmerjevalne tabele VPC.

Skupna identiteta je del, na katerega mora politika odgovoriti

Vsaka naprava za prehodom uporablja sejo VPN prehoda. Pravila dovoljenj končne točke dajejo dostop uporabniku ali skupini, in z vidika storitve je v tej seji natanko en uporabnik. Lokalno posredovanje te identitete ne pomnoži v preverjanje na napravo in ne razširi preverjanja stanja naprav na tiskalnik v kotu.

To je lahko sprejemljivo ali pa je razlog, da je zasnova zavrnjena. Odvisno je od tega, kaj viri VPC predpostavljajo o tem, kdo kliče. Skupna identiteta, ki se prilega modelu dovoljenj, je v redu; tista, ki tiho spremeni eno preverjeno sejo v dostop do celotnega LAN, je ugotovitev, ki čaka, da bo zapisana.

Če je zahteva res povezati celotno lokacijo z VPC, primerjajte podprto zasnovo lokacija-lokacija, preden razširite odjemalca za oddaljeni dostop. Semantika se razlikuje, seja odjemalca z NAT pa je slaba zamenjava za povezavo lokacije, ko mora VPC začeti povezave v LAN.

Odločite o odjemalcu, poti, prevajanju in zgodbi o identiteti v tem vrstnem redu. Vsak omejuje naslednjega, vrstni red pa pojasnjuje, zakaj gostitelj deluje, LAN pa ne.