AWS Client VPN s podijeljenim tunelom: koje rute objaviti

Konzola nudi prekidač za podijeljeni tunel, pa se odluka čini kao potvrdni okvir. Nije. Do klijenta zapravo stiže objavljeni skup ruta krajnje točke, a ta lista 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 odgovoriti loše dok veza i dalje uspijeva.

Zastavica podijeljenog tunela nije lista odredišta

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

Čitajte tablicu ruta krajnje 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 pregledavanje 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čio jednu i ne pretpostavljajte da dodatna ruta poboljšava sigurnost. Ona 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 krajnje 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 krajnje 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 živi 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, zatim provjerite oba svijeta

AWS dokumentira da promjena ruta na krajnjoj 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 listu ruta u runbook uz obrazloženje, kako bi sljedeća osoba mogla razlikovati namjeran izuzetak od zaboravljenog.