Povremeni pristup preko AWS Client VPN: provjerite svaku pridruženu podmrežu

Korisnik se poveže, otvori internu aplikaciju i dobije odgovor; kolega na istoj krajnjoj točki dobije istek vremena s identičnog prijenosnika na istoj Wi-Fi mreži. Taj obrazac je potpis krajnje točke client VPN-a s više od jedne pridružene podmreže, gdje putanje nisu jednakovrijedne. Prolazim kroz ovo od konzole prema van, jer dvije kartice odlučuju isplati li se ostatak istrage. Ništa u konfiguraciji klijenta to ne objašnjava.

Počnite od krajnje točke i popišite pridruživanja

U konzoli VPC otvorite Client VPN endpoints, odaberite krajnju točku i pročitajte karticu Associations. Svako pridruživanje je podmreža u zoni dostupnosti, a klijent slijeće na onu koju servis odabere kad se veza uspostavi. Zabilježite ID-ove podmreža i tablicu ruta koju svaka zapravo koristi, jer su ta dva popisa usporedba koju ćete upravo napraviti.

Ako krajnja točka pokazuje samo jedno pridruživanje, ova je teorija pogrešna i klijent je bolji osumnjičenik.

Uporedite tablicu ruta krajnje točke sa svakim pridruživanjem

Otvorite karticu Route table na istoj krajnjoj točki. Svaki odredišni CIDR tamo ima cilj, a kod client VPN-a cilj je pridruživanje, a ne pristupnik. AWS zahtijeva unos odredišta za svaku pridruženu podmrežu, pa ruta koja cilja samo jednu od njih čini pristup ovisnim o tome gdje je sesija sletjela. Provjerite odredište koje vam je doista važno, zatim njegovo pravilo autorizacije, jer ruta daje putanju, a pravilo odlučuje kome je dopušteno koristiti je.

Kad oba sloja unesete u tablicu, kvar je teško previdjeti.

Drugi red je cijeli bug u većini tiketa. Ruta krajnje točke postoji, pa nitko ne gleda dalje, a paket umire jedan skok kasnije unutar VPC-a.

Slijedite svaku podmrežu u njezinu efektivnu tablicu ruta

Podmreža bez izričitog pridruživanja tablici ruta nasljeđuje glavnu tablicu VPC-a. Čitajte tablicu koja je zapravo na snazi, a ne onu čije ime izgleda ispravno, i uporedite odredište i cilj umjesto oznake u retku.

AWS-ov vodič za povremeni pristup opisuje to kao pokrivenost rutama kroz pridruživanja, što je ispravan model. Krajnja točka dovodi paket do podmreže, a tablica te podmreže još uvijek mora znati gdje se nalazi mreža aplikacije.

Ispravite redak koji nedostaje u tablici koja ga posjeduje. Kopiranje cijele tablice ruta s radne podmreže kopira i odluke o internetu, uređajima i izolaciji koje nikada nisu bile namijenjene ovoj, a ta je razmjena obično gora od prekida s kojim ste počeli.

Provjerite pravila autorizacije, zatim putanju natrag

Pravila autorizacije vrijede po odredištu i po grupi te se ocjenjuju odvojeno od ruta. Odredište s rutama posvuda ali bez pravila za korisnikovu grupu ponaša se kao crna rupa s tablicom ruta koja izgleda zdravo.

Povratna putanja zaslužuje jednaku pozornost. Peering veza treba rutu u VPC-u aplikacije koja pokazuje natrag na CIDR klijenta, pravila sigurnosnih grupa koja dopuštaju promet na oba kraja i mrežne ACL-ove koji ga ne odbacuju. Jednosmjerna dostupnost, gdje ping radi a TCP rukovanje ne, obično upućuje na ACL ili sigurnosnu grupu, a ne na VPN.

Vlastite sigurnosne grupe krajnje točke nalaze se na elastičnim mrežnim sučeljima pridruživanja, pa pravilo koje dopušta port aplikacije s CIDR-a klijenta mora biti pridruženo pridruživanju, a ne samo instanci.

Provjerite ponovnim povezivanjem, a ne jednim sretnim zahtjevom

Uz split tunnel, rute krajnje točke šalju se kad se veza uspostavi, pa promijenjeni skup ruta nikada ne stigne do klijenta koji ostane povezan. Prekinite vezu i ponovno se povežite kroz podržani klijent, zatim potvrdite da su nove rute prisutne na stroju.

Naposljetku, povežite zapisnik veza s adresom koju je klijent dobio i ponovite test dovoljno puta da pogodite više od jednog pridruživanja. Jedan uspješan zahtjev nakon popravka dokazuje da jedna putanja radi, a tiket je bio o drugoj.