AWS Client VPN s podijeljenim tunelom: koje rute objaviti

Konzola nudi prekidač za podijeljeni tunel pa se odluka doima kao potvrdni okvir. Nije. Do klijenta zapravo dolazi objavljeni skup ruta završne točke, a taj popis odlučuje koji privatni prefiksi koriste tunel, ostaje li opći internetski promet lokalno ili izlazi kroz AWS i s kojim resolverom klijent još može razgovarati. Tri pitanja rješavaju dizajn, a na svako se može loše odgovoriti dok veza i dalje uspijeva.

Zastavica podijeljenog tunela nije popis odredišta

AWS opisuje podijeljeni tunel kao dodavanje ruta završne točke u klijentovu tablicu ruta pri uspostavi veze. Ruta za privatni VPC ograničava tunel na to odredište; sve ostalo slijedi uobičajeni put klijenta. Zadana ruta drugačija je uputa s drugačijim učinkom, zato dokumentacija o podijeljenom tunelu upozorava na objavljivanje 0.0.0.0/0 na završnoj točki konfiguriranoj za ovaj način rada: to obično prekida povezanost umjesto da je proširuje. Tablica ruta završne točke je politika, a klijentova tablica ruta rezultat je koji možete pregledati.

Čitajte tablicu ruta završne točke i instalirane rute klijenta zajedno. Oznaka opisuje namjeru; rute opisuju što se događa.

Prva odluka: treba li opći internetski promet ostati lokalno?

Ako pretraživanje treba koristiti korisnikovu vlastitu vezu, objavite samo privatna odredišta koja posao treba i tu stanite. Ne dodajte internetsku rutu zato što je vodič za puni tunel uključivao jednu i ne pretpostavljajte da dodatna ruta poboljšava sigurnost. Mijenja put, ne dodaje politiku i obično košta latenciju koju niste planirali.

Ako internetski promet treba izlaziti kroz AWS, izgradite dokumentiranu arhitekturu internetskog pristupa: rutu završne točke, pravila autorizacije, put povezane podmreže, sigurnosnu politiku i funkcionalan izlaz prema gore. Zadana ruta sama po sebi ne pruža ništa od toga.

Druga odluka: koji privatni prefiksi i čijom autorizacijom?

Objavite najmanji skup odredišta koji služi stvarnom poslu i provjerite može li svaka povezana podmreža usmjeravati prema njima. Cilj rute završne točke i VPC usmjeravanje podmreže različiti su slojevi, a ruta koja postoji u jednom nije dokaz o drugom. Autorizacija je opet odvojena: odredište može biti dostupno i ipak odbijeno jer klijentova grupa nema pravilo koje ga dopušta.

Testiranje jedne uspješne sesije dokazuje jedan put. Provjerite svaku povezanu podmrežu jer je povezivanje podmreže dodano kasnije upravo mjesto gdje obično boravi ruta koja nedostaje.

Kada odredište mora biti dostupno po imenu, imajte na umu da je sljedeće pitanje razrješavanje imena, a ne ruta.

Treća odluka: koji resolver slijedi tunel?

Klijent može dobiti DNS poslužitelj dostupan samo kroz VPN, a taj resolver radi samo ako je njegova adresa unutar autorizirane rute. Provjerite obje polovice: adresa resolvera slijedi objavljenu rutu i poslužitelj odgovara na imena koja aplikacija traži. Zahtjev koji uspijeva po adresi dok ime hosta ne uspijeva upućuje na imenovanje, a ne na usmjeravanje, i otklanjanje pogrešaka tunela u tom slučaju troši poslijepodne.

Javna imena trebaju se razriješiti kao prije veze, što je još jedan razlog da budete precizni u vezi s onim što objavljujete.

Promijenite skup ruta pa provjerite oba svijeta

AWS dokumentira da promjena ruta na završnoj točki s podijeljenim tunelom resetira klijentske veze. Planirajte promjenu imajući to na umu: primijenite je, ponovno se povežite kroz podržani klijent i ponovno pročitajte instalirane rute umjesto da vjerujete stanju primijenjenom prije izmjene. Zastarjelo primijenjeno stanje najčešći je razlog zašto ispravna promjena izgleda pokvareno.

Prihvatite dizajn samo kada se jedan privatni resurs i jedno javno odredište ponašaju kako je predviđeno, po imenu i po adresi, na obiteljima adresa koje stvarno podržavate. Tunel koji se autentificira nije isto što i tunel koji ispravno dijeli promet.

Zapišite popis ruta u runbook uz obrazloženje kako bi sljedeća osoba mogla razlikovati namjeran izuzetak od zaboravljenog.