AWS Client VPN kun dividita tunelo: kiujn vojojn publikigi

La konzolo proponas ŝaltilon por dividita tunelo, do la decido ŝajnas markobutono. Ĝi ne estas. Kio efektive atingas la klienton estas la publikigita vojaro de la finpunkto, kaj tiu listo decidas kiuj privataj prefiksoj uzas la tunelon, ĉu ĝenerala interreta trafiko restas loka aŭ eliras tra AWS, kaj kun kiu solvilo la kliento ankoraŭ povas paroli. Tri demandoj solvas la dezajnon, kaj ĉiun eblas respondi malbone dum la konekto tamen sukcesas.

Dividita-tunela flago ne estas listo de celoj

AWS priskribas dividitan tunelon kiel aldonon de finpunktaj vojoj al la vojtablo de la kliento ĉe konekta establo. Vojo por la privata VPC limigas la tunelon al tiu celo; ĉio alia sekvas la ordinaran vojon de la kliento. Defaŭlta vojo estas alia instrukcio kun alia efiko, kaj tial la dokumentaro pri dividita tunelo avertas kontraŭ publikigi 0.0.0.0/0 sur finpunkto agordita por ĉi tiu reĝimo: ĝi emas rompi konektecon anstataŭ etendi ĝin. La vojtablo de la finpunkto estas la politiko, kaj la vojtablo de la kliento estas la rezulto, kiun vi povas inspekti.

Legu la vojtablon de la finpunkto kaj la instalitajn vojojn de la kliento kune. La etikedo priskribas intencon; la vojoj priskribas kio okazas.

Unua decido: ĉu ĝenerala interreta trafiko restu loka?

Se retumi devas uzi la propran konekton de la uzanto, publikigu nur la privatajn celojn, kiujn la tasko bezonas, kaj haltu tie. Ne aldonu interretan vojon ĉar lernilo pri plena tunelo inkluzivis unu, kaj ne supozu ke la plia vojo plibonigas sekurecon. Ĝi ŝanĝas la vojon, ĝi ne aldonas politikon, kaj ĝi kutime kostas latenton, kiun vi ne buĝetis.

Se interreta trafiko devas eliri tra AWS, konstruu la dokumentitan interret-aliran arkitekturon: finpunkta vojo, rajtigaj reguloj, la vojo de la asociita subreto, sekureca politiko kaj funkcianta supra eliro. Defaŭlta vojo sola provizas neniun el tiuj.

Dua decido: kiuj privataj prefiksoj, rajtigitaj de kiu?

Publikigu la plej malgrandan aron da celoj, kiu servas la realan laborŝarĝon, kaj kontrolu ĉu ĉiu asociita subreto povas enkursigi al ili. La voja celo de la finpunkto kaj la VPC-enkursigo de la subreto estas malsamaj tavoloj, kaj vojo ekzistanta en unu ne estas pruvo pri la alia. Rajtigo denove apartas: celo povas esti atingebla kaj tamen malpermesita ĉar la grupo de la kliento havas neniun regulon, kiu permesas ĝin.

Testi unu sukcesan seancon pruvas unu vojon. Kontrolu ĉiun asociitan subreton, ĉar subreta asociigo aldonita poste estas ĝuste la loko, kie kutime loĝas la mankanta vojo.

Kiam celo devas esti atingebla laŭ nomo, notu ke la sekva demando estas nom-solvado, ne la voja demando.

Tria decido: kiu solvilo sekvas la tunelon?

Kliento povas ricevi DNS-servilon atingeblan nur tra la VPN, kaj tiu solvilo funkcias nur se ĝia adreso mem troviĝas ene de rajtigita vojo. Kontrolu ambaŭ duonojn: la adreso de la solvilo sekvas publikigitan vojon, kaj la servilo respondas al la nomoj, kiujn la aplikaĵo petas. Peto sukcesanta laŭ adreso dum la gastigantnomo malsukcesas indikas nomadon, ne enkursigon, kaj sencimigado de la tunelo tiukaze malŝparas la posttagmezon.

Publikaj nomoj devus solviĝi same kiel antaŭ la konekto, kio estas plia kialo esti preciza pri tio, kion vi publikigas.

Ŝanĝu la vojaron, poste kontrolu ambaŭ mondojn

AWS dokumentas, ke ŝanĝi vojojn sur dividita-tunela finpunkto restarigas klientajn konektojn. Planu la ŝanĝon kun tio en menso: apliku ĝin, rekonektu per la subtenata kliento, kaj relegu la instalitajn vojojn anstataŭ fidi staton aplikitan antaŭ la redakto. Malfreŝa aplikita stato estas la plej ofta kialo, kial ĝusta ŝanĝo aspektas rompita.

Akceptu la dezajnon nur kiam unu privata rimedo kaj unu publika celo ambaŭ kondutas kiel intencite, laŭ nomo kaj laŭ adreso, en la adresfamilioj, kiujn vi efektive subtenas. Tunelo, kiu aŭtentikigas, ne samas kiel tunelo, kiu ĝuste dividas.

Skribu la vojliston en la runlibron apud la rezonado, por ke la sekva persono povu distingi intencitan eskludon de forgesita.