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

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

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

U konzoli VPC otvorite Client VPN endpoints, odaberite završnu 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 završna točka pokazuje samo jedno pridruživanje, ova je teorija pogrešna i klijent je bolji osumnjičenik.

Usporedite tablicu ruta završne točke sa svakim pridruživanjem

Otvorite karticu Route table na istoj završnoj 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 završne 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 usporedite 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. Završna 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 završne 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 završne 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.