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

Korisnik se poveže, otvori internu aplikaciju i dobije odgovor; kolega na istom endpointu dobije istek vremena sa identičnog laptopa na istoj Wi-Fi mreži. Taj obrazac je potpis client VPN endpointa sa više od jedne pridružene podmreže, gdje putanje nisu ekvivalentne. Prolazim kroz ovo od konzole prema van, jer dva taba odlučuju da li ostatak istrage vrijedi raditi. Ništa u konfiguraciji klijenta to ne objašnjava.

Počnite od endpointa i popišite pridruživanja

U VPC konzoli otvorite Client VPN endpoints, odaberite endpoint i pročitajte tab Associations. Svako pridruživanje je podmreža u zoni dostupnosti, a klijent sleti na onu koju servis odabere kada se veza uspostavi. Zabilježite ID-ove podmreža i tabelu ruta koju svaka zaista koristi, jer su te dvije liste poređenje koje ćete upravo napraviti.

Ako endpoint pokazuje samo jedno pridruživanje, ova teorija je pogrešna i klijent je bolji osumnjičeni.

Uporedite tabelu ruta endpointa sa svakim pridruživanjem

Otvorite tab Route table na istom endpointu. Svaki odredišni CIDR tamo ima cilj, a kod client VPN cilj je pridruživanje, a ne gateway. AWS zahtijeva unos odredišta za svaku pridruženu podmrežu, pa ruta koja cilja samo jednu od njih čini pristup zavisnim od toga gdje je sesija sletjela. Provjerite odredište koje vam je zaista važno, zatim provjerite njegovo pravilo autorizacije, jer ruta daje putanju, a pravilo odlučuje ko je smije koristiti.

Kada oba sloja stavite u tabelu, kvar je teško propustiti.

Drugi red je cijeli bug u većini tiketa. Ruta endpointa postoji, pa niko ne gleda dalje, a paket umire jedan skok kasnije unutar VPC-a.

Pratite svaku podmrežu u njenu efektivnu tabelu ruta

Podmreža bez izričitog pridruživanja tabeli ruta nasljeđuje glavnu tabelu VPC-a. Čitajte tabelu koja je zaista na snazi, a ne onu čije ime izgleda ispravno, i uporedite odredište i cilj, a ne oznaku u redu.

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

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

Provjerite pravila autorizacije, zatim putanju nazad

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

Povratna putanja zaslužuje istu pažnju. Peering veza treba rutu u VPC-u aplikacije koja pokazuje nazad na CIDR klijenta, pravila sigurnosnih grupa koja dozvoljavaju saobraćaj na oba kraja i mrežne ACL-ove koji ga ne odbacuju. Jednosmjerna dostupnost, gdje ping radi a TCP rukovanje ne, obično ukazuje na ACL ili sigurnosnu grupu, a ne na VPN.

Vlastite sigurnosne grupe endpointa stoje na elastičnim mrežnim interfejsima pridruživanja, pa pravilo koje dozvoljava port aplikacije sa CIDR-a klijenta mora biti priključeno pridruživanju, a ne samo instanci.

Provjerite ponovnim povezivanjem, a ne jednim sretnim zahtjevom

Uz split tunnel, rute endpointa se šalju kada se veza uspostavi, pa promijenjeni skup ruta nikada ne stigne do klijenta koji ostane povezan. Prekinite vezu i ponovo se povežite kroz podržani klijent, zatim potvrdite da su nove rute prisutne na mašini.

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