AWS Client VPN z razdeljenim tunelom: katere poti objaviti

Konzola ponuja stikalo za razdeljeni tunel, zato se odločitev zdi kot potrditveno polje. Ni. Do odjemalca dejansko pride objavljena množica poti končne točke, in ta seznam odloča, katere zasebne predpone uporabljajo tunel, ali splošni internetni promet ostane lokalen ali gre ven skozi AWS, in s katerim resolverjem se odjemalec še lahko pogovarja. Tri vprašanja odločijo zasnovo, in na vsako je mogoče odgovoriti slabo, medtem ko povezava še vedno uspe.

Zastavica razdeljenega tunela ni seznam ciljev

AWS opisuje razdeljeni tunel kot dodajanje poti končne točke v usmerjevalno tabelo odjemalca ob vzpostavitvi povezave. Pot do zasebnega VPC omeji tunel na ta cilj; vse ostalo sledi običajni poti odjemalca. Privzeta pot je drugačno navodilo z drugačnim učinkom, zato dokumentacija razdeljenega tunela svari pred objavo 0.0.0.0/0 na končni točki, nastavljeni za ta način: to običajno prekine povezljivost, namesto da bi jo razširilo. Usmerjevalna tabela končne točke je politika, usmerjevalna tabela odjemalca pa rezultat, ki ga lahko pregledate.

Berite usmerjevalno tabelo končne točke in nameščene poti odjemalca skupaj. Oznaka opisuje namero; poti opisujejo, kaj se zgodi.

Prva odločitev: mora splošni internetni promet ostati lokalen?

Če naj brskanje uporablja uporabnikovo lastno povezavo, objavite samo zasebne cilje, ki jih delo potrebuje, in se tam ustavite. Ne dodajajte internetne poti zato, ker jo je vključeval priročnik za polni tunel, in ne domnevajte, da dodatna pot izboljšuje varnost. Spremeni pot, ne doda politike in običajno stane zakasnitev, ki je niste načrtovali.

Če naj internetni promet izhaja skozi AWS, zgradite dokumentirano arhitekturo dostopa do interneta: pot končne točke, pravila avtorizacije, pot povezane podomrežje, varnostno politiko in delujoč izhod navzgor. Samo privzeta pot ne zagotavlja nič od tega.

Druga odločitev: katere zasebne predpone in s čigavo avtorizacijo?

Objavite najmanjšo množico ciljev, ki služi dejanski obremenitvi, in preverite, ali lahko vsaka povezana podomrežje usmerja do njih. Cilj poti končne točke in usmerjanje VPC v podomrežju sta različni plasti, in pot, ki obstaja v eni, ni dokaz o drugi. Avtorizacija je spet ločena: cilj je lahko dosegljiv in vseeno zavrnjen, ker skupina odjemalca nima pravila, ki bi ga dovolilo.

Preizkus ene uspešne seje dokaže eno pot. Preverite vsako povezano podomrežje, ker je povezava podomrežja, dodana pozneje, natanko tisto mesto, kjer običajno stoji manjkajoča pot.

Ko mora biti cilj dosegljiv po imenu, upoštevajte, da je naslednje vprašanje razreševanje imen, ne pot.

Tretja odločitev: kateri resolver sledi tunelu?

Odjemalec lahko prejme strežnik DNS, dosegljiv samo prek VPN, in ta resolver deluje le, če je njegov naslov sam znotraj avtorizirane poti. Preverite obe polovici: naslov resolverja sledi objavljeni poti, strežnik pa odgovarja na imena, ki jih zahteva aplikacija. Zahteva, ki uspe po naslovu, a ne uspe po imenu gostitelja, kaže na poimenovanje, ne na usmerjanje, in odpravljanje napak tunela v tem primeru zapravi popoldne.

Javna imena bi se morala razreševati tako kot pred povezavo, kar je še en razlog, da bodite natančni glede tega, kar objavljate.

Spremenite množico poti in nato preverite oba svetova

AWS dokumentira, da sprememba poti na končni točki razdeljenega tunela ponastavi povezave odjemalcev. Načrtujte spremembo s tem v mislih: uporabite jo, znova se povežite prek podprtega odjemalca in znova preberite nameščene poti, namesto da bi zaupali stanju, uporabljenemu pred urejanjem. Zastarelo uporabljeno stanje je najpogostejši razlog, da je pravilna sprememba videti pokvarjena.

Zasnovo sprejmite le, ko se en zasebni vir in en javni cilj obnašata po načrtu, po imenu in po naslovu, v naslovnih družinah, ki jih resnično podpirate. Tunel, ki preverja identiteto, ni isto kot tunel, ki pravilno deli promet.

Seznam poti zapišite v runbook ob razloge, da bo naslednja oseba ločila namerno izločitev od pozabljene.