AWS Client VPN aŭ bastiono por atingi peeran VPC

Unu Client VPN-endpoint povas atingi VPC-on kiu estas peera kun sia asociita VPC, kaj vi ne bezonas bastionon por igi tion legitima. La elekto inda estas kie la trafiko ŝanĝas manojn: endpoint-itinero kiu surteriĝas en la asocia subreto kaj transiras la peeran ligon, aŭ gastiganto en la peera VPC kiu finas la sesion. Ambaŭ vojoj funkcias kaj ili malsukcesas en malsamaj lokoj, do la decido temas pri posedo kaj revizio, ne pri tio kion AWS permesas. Jen kiel mi elektas inter ili, kaj la kvar enskriboj kiuj igas la enkursigitan vojon funkcii.

Du vojoj, unu endpoint, malsamaj posedantoj

Sur la enkursigita vojo la klienta trafiko atingas la endpoint-on, estas tradukata al la adreso de la Client VPN-retsurfaco en la asocia subreto, kaj forlasas tiun subreton trans la peera ligo de A al B. VPC B finas neniun VPN-sesion; ĝi vidas ordinaran trafikon el VPC A, do ĝia revena itinero montras al VPC A, ne al la klienta baseno.

Sur la bastiona vojo la kliento unue atingas gastiganton. Bastiono en A ankoraŭ lasas la lastan salton transiri la peeran ligon, do vi konservas la peeran laboron kaj aldonas sesion. Bastiono en B ankaŭ bezonas vojon de la kliento, kaj kiam tiu vojo estas la sama endpoint-itinero, vi havas la enkursigitan dezajnon plus unu salton. La bastiono forigas laboron nur kiam ĝi jam ekzistas, jam havas aprobon, kaj la afero malantaŭ ĝi bezonas sesian limon anstataŭ retan limon.

Kvar enskriboj igas la enkursigitan vojon funkcii

AWS dokumentas ĉi tiun scenaron sur la Client VPN how-it-works-paĝo, kaj praktike ĝi reduktiĝas al kvar enskriboj posedataj de du aŭ tri teamoj. La gamoj estas ilustraj; la peera gamo devas esti unika kaj la revena gamo devas kongrui kun via plano.

Itinero kaj permeso estas apartaj kontroloj. Ĝusta endpoint-itinero sen kongrua rajtiga regulo donas nenion al la kliento; rajtiga regulo por celo kiun la endpoint ne povas enkursigi donas al ĝi nigran truon. Ambaŭ devas nomi la saman gamon.

La endpoint-itinero montras al subreto en la propra VPC de la endpoint, neniam al la peera ligo. La VPC-itinertabeloj montras al la peera ligo, neniam al instanco aŭ surfaco. Kopii valoron inter la du konserviĝas sen plendo kaj enkursigas nenion.

Ĉar la asocia subreto tradukas la klientan fonton, B devas enkursigi reen al VPC A, ne al la klienta baseno. Sendi la klientan gamon trans la peeran ligon aspektas simetria, pasas revizion kaj malsukcesas silente, ĉar B neniam vidas paketon kun klienta fonto.

Sekurecaj grupoj kaj la lasta metro de permeso

Enkursigado enigas paketojn en B; B ankoraŭ decidas. Por aktiva peera ligo en la sama regiono, sekureca grupo en B povas referenci la grupon aplikitan al la Client VPN-asocio, kio tenas la regulon mallarĝa kaj postvivas adresajn ŝanĝojn. Kie grupa referenco ne estas farebla, permesu la gamon de la asocia subreto eksplicite anstataŭ vastigi al 0.0.0.0/0, kio transformas enkursigan eraron en neklarigitan tempolimon.

Poste kontrolu kion enkursigado neniam tuŝas: retajn ACL-ojn sur ambaŭ subretoj, la permesliston de la aplikaĵo aŭ la publikon de la ĵetono, kaj DNS. Peering ne kopias privatajn gastigitajn zonojn, do la tekkomputilo povas teni funkcian itinero al adreso kiun ĝi ne povas solvi, kaj peera ligo aldonas neniun fidon al atestilo. Direktu la endpoint-on al solvilo kiu respondas por B, poste konfirmu ke la privata nomo kaj la atestilo kongruas.

Kiam la bastiono estas la honesta respondo

Mi tenas tri ekigilojn por intence elekti bastionon. La peera VPC apartenas al teamo kiu ne aldonos revenan itinero por via gamo aŭ ne akceptos grupan referencon. Aliro devas esti aprobita aŭ registrita por ĉiu sesio kaj la aplikaĵo ne povas porti tion mem. Aŭ la lasta salto devas resti ene de B ĉar la servo solviĝas nur tie kaj ĝia TLS-identeco estas fiksita al interna nomo.

Nenio el tio evitas la fakton ke peering ne estas transitiva. Netransitiveco limigas kion rimedoj en B rajtas fari: ili ne povas uzi A kiel transiton al tria VPC kun kiu A estas peera. Ĝi neniam signifis ke VPN-uzanto ne povas atingi rekte peeran VPC-on, kaj bastiono konstruita por eviti tiun malĝustan legadon estas gastiganto por fliki sen kialo.

La inversa eraro kostas pli longtempe: pelu ĉiun teamon tra la ununura bastiono kiu jam ekzistas, poste malkovru ke ĝia sekureca grupo, itinertabelo kaj flika fenestro estas la produkta dependeco. Skribu kiun ekigilon la gastiganto servas, kaj retiru ĝin kiam la ekigilo malaperos.

Transit Gateway kaj pluraj asocioj ŝanĝas la aritmetikon

Se la endpoint estas ligita rekte al Transit Gateway anstataŭ al subreto, la modelo ŝanĝiĝas: klientoj ne plu tradukiĝas al surfaca adreso en asocia subreto, kaj la pordegaj itinertabeloj devas porti la klientan gamon plus la alligon kiu kondukas al la peera VPC. Tio estas pli pura laŭ skalo, sed la laboro moviĝas de kvar enskriboj al pordegaj itinertabeloj.

Pluraj asocioj multiplikas la kontrolojn. La endpoint-itinero apartenas al la endpoint, tamen ĉiu asocia subreto bezonas itinertabelon kun reala peera sekva salto. Sesio povas sukcesi tra unu asocio dum alia havas neniun revenan vojon, do testu ĉiun.

Kontrola ordo kiu trovas la rompon rapide

Rulu ĉi tiujn laŭ ordo; ĉiu paŝo povas sukcesi dum la sekva malsukcesas, kaj klienta tempolimo preskaŭ neniam diras kiu rompiĝis.

1. Solvu la aplikaĵan nomon el la kliento kaj kontrolu ke la adreso estas ene de la peera gamo.
2. Konektiĝu, poste legu la endpoint-konektan protokolon por la asocio kiu finis la sesion.
3. Sur tiu asocia subreto, konfirmu ke la itinertabelo direktas la peeran gamon al aktiva peera ligo.
4. Sur la rimeda subreto en B, konfirmu revenan enskribon por la surfaca gamo kaj kongruajn grupajn regulojn.
5. Testu unu permesitan operacion kaj unu rimedon kiu devas resti neatingebla; la dua kaptas restaĵojn de sencimigado.
6. Rekonektiĝu post ĉiu split-tunnel itinera ŝanĝo, ĉar kuranta tunelo ne prenos novan itinaran aron.

Du simptomoj indas memori. SYN kiu atingas B sen respondo preskaŭ ĉiam estas la mankanta revena itinero. Konekto kiu kompletiĝas kaj poste restarigas estas kutime la grupo, la ACL aŭ la aplikaĵo. Neniu aperas en la endpoint-protokolo kiel kaŭzo, do tenu la kvar enskribojn kun posedanto apud ĉiu.

Se neniu el la tri ekigiloj validas, finu la enkursigitan vojon kaj registru tiujn kvar enskribojn. Se unu validas, tenu la bastionon nur por tiu limo kaj lasu la endpoint-itinero por servoj kiuj ne bezonas sesion antaŭ si.