AWS Client VPN sa podeljenim tunelom: koje rute objaviti

Konzola nudi prekidač za podeljeni tunel, pa odluka deluje kao potvrdni okvir. Nije. Do klijenta zapravo stiže objavljeni skup ruta krajnje tačke, a ta lista odlučuje koje privatne prefikse koriste tunel, da li opšti internet saobraćaj ostaje lokalno ili izlazi kroz AWS i sa kojim resolverom klijent još može da razgovara. Tri pitanja rešavaju dizajn, a na svako se može loše odgovoriti dok veza i dalje uspeva.

Zastavica podeljenog tunela nije lista odredišta

AWS opisuje podeljeni tunel kao dodavanje ruta krajnje tačke u klijentovu tabelu ruta pri uspostavljanju veze. Ruta za privatni VPC ograničava tunel na to odredište; sve ostalo sledi uobičajeni put klijenta. Podrazumevana ruta je drugačije uputstvo sa drugačijim efektom, zato dokumentacija o podeljenom tunelu upozorava na objavljivanje 0.0.0.0/0 na krajnjoj tački konfigurisanoj za ovaj režim: to obično prekida povezanost umesto da je proširi. Tabela ruta krajnje tačke je politika, a klijentova tabela ruta je rezultat koji možete pregledati.

Čitajte tabelu ruta krajnje tačke i instalirane rute klijenta zajedno. Oznaka opisuje nameru; rute opisuju šta se dešava.

Prva odluka: treba li opšti internet saobraćaj da ostane lokalno?

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

Ako internet saobraćaj treba da izlazi kroz AWS, izgradite dokumentovanu arhitekturu internet pristupa: rutu krajnje tačke, pravila autorizacije, put povezane podmreže, bezbednosnu politiku i funkcionalan izlaz prema gore. Podrazumevana 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 proverite može li svaka povezana podmreža da usmerava prema njima. Cilj rute krajnje tačke i VPC usmeravanje podmreže su različiti 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 klijentska grupa nema pravilo koje ga dozvoljava.

Testiranje jedne uspešne sesije dokazuje jedan put. Proverite svaku povezanu podmrežu, jer je povezivanje podmreže dodato kasnije upravo mesto gde obično živi ruta koja nedostaje.

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

Treća odluka: koji resolver sledi tunel?

Klijent može da dobije DNS server dostupan samo kroz VPN, a taj resolver radi samo ako je njegova adresa unutar autorizovane rute. Proverite obe polovine: adresa resolvera sledi objavljenu rutu i server odgovara na imena koja aplikacija traži. Zahtev koji uspeva po adresi dok ime hosta ne uspeva upućuje na imenovanje, a ne na usmeravanje, i otklanjanje grešaka tunela u tom slučaju troši popodne.

Javna imena treba da se razreše kao pre veze, što je još jedan razlog da budete precizni u vezi sa onim što objavljujete.

Promenite skup ruta, zatim proverite oba sveta

AWS dokumentuje da promena ruta na krajnjoj tački sa podeljenim tunelom resetuje klijentske veze. Planirajte promenu imajući to na umu: primenite je, ponovo se povežite kroz podržani klijent i ponovo pročitajte instalirane rute umesto da verujete stanju primenjenom pre izmene. Zastarelo primenjeno stanje je najčešći razlog zašto ispravna promena 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 porodicama adresa koje stvarno podržavate. Tunel koji se autentifikuje nije isto što i tunel koji ispravno deli saobraćaj.

Zapišite listu ruta u runbook uz obrazloženje, kako bi sledeća osoba mogla da razlikuje namerni izuzetak od zaboravljenog.