Občasen dostop prek AWS Client VPN: preverite vsako povezano podomrežje

Uporabnik se poveže, odpre notranjo aplikacijo in dobi odgovor; sodelavec na isti končni točki dobi časovno prekoračitev z identičnega prenosnika v istem omrežju Wi-Fi. Ta vzorec je podpis končne točke client VPN z več kot enim povezanim podomrežjem, kjer poti niso enakovredne. To pregledujem od konzole navzven, ker dva zavihka odločata, ali je preostala preiskava vredna truda. Nič v konfiguraciji odjemalca tega ne pojasni.

Začnite pri končni točki in naštejte povezave

V konzoli VPC odprite Client VPN endpoints, izberite končno točko in preberite zavihek Associations. Vsaka povezava je podomrežje v območju razpoložljivosti, odjemalec pa pristane na tistem, ki ga storitev izbere ob vzpostavitvi povezave. Zapišite ID podomrežij in tabelo poti, ki jo vsako dejansko uporablja, ker sta ta dva seznama primerjava, ki jo boste pravkar naredili.

Če končna točka prikazuje samo eno povezavo, je ta teorija napačna in odjemalec je boljši osumljenec.

Primerjajte tabelo poti končne točke z vsako povezavo

Odprite zavihek Route table na isti končni točki. Vsak ciljni CIDR ima tam cilj, pri client VPN pa je cilj povezava in ne prehod. AWS zahteva vnos cilja za vsako povezano podomrežje, zato pot, ki cilja le eno od njih, naredi dostop odvisen od tega, kje je seja pristala. Preverite cilj, ki vam je res pomemben, nato njegovo pravilo avtorizacije, ker pot zagotavlja pot, pravilo pa odloča, kdo jo sme uporabljati.

Ko oba sloja vnesete v tabelo, je napako težko spregledati.

Druga vrstica je v večini zahtevkov celotna napaka. Pot končne točke obstaja, zato nihče ne pogleda dlje, paket pa umre en skok kasneje znotraj VPC.

Sledite vsakemu podomrežju do njegove dejanske tabele poti

Podomrežje brez izrecne povezave s tabelo poti podeduje glavno tabelo VPC. Berite tabelo, ki dejansko velja, ne tiste, katere ime se zdi pravilno, in primerjajte cilj in namembni cilj namesto oznake v vrstici.

Vodnik AWS za občasen dostop to opisuje kot pokritost s potmi po vseh povezavah, kar je pravi model. Končna točka pripelje paket do podomrežja, tabela tega podomrežja pa mora še vedno vedeti, kje je omrežje aplikacije.

Popravite manjkajočo vrstico v tabeli, ki ji pripada. Kopiranje celotne tabele poti z delujočega podomrežja kopira tudi izbire glede interneta, naprave in izolacije, ki nikoli niso bile mišljene za to, in ta izmenjava je običajno slabša od izpada, s katerim ste začeli.

Preverite pravila avtorizacije, nato pot nazaj

Pravila avtorizacije veljajo za posamezni cilj in skupino ter se ocenjujejo ločeno od poti. Cilj s potmi povsod, a brez pravila za uporabnikovo skupino, se obnaša kot črna luknja z na videz zdravo tabelo poti.

Povratna pot si zasluži enako pozornost. Povezava peering potrebuje pot v VPC aplikacije nazaj na CIDR odjemalca, pravila varnostnih skupin, ki dovolijo promet na obeh koncih, in omrežne ACL, ki ga ne zavržejo. Enosmerna dosegljivost, ko ping deluje, rokovanje TCP pa ne, običajno kaže na ACL ali varnostno skupino in ne na VPN.

Lastne varnostne skupine končne točke so na elastičnih omrežnih vmesnikih povezave, zato mora biti pravilo, ki dovoli vrata aplikacije iz CIDR odjemalca, pritrjeno na povezavo, ne le na primerek.

Preverite s ponovno povezavo, ne z eno srečno zahtevo

Pri split tunelu se poti končne točke potisnejo ob vzpostavitvi povezave, zato spremenjen nabor poti nikoli ne doseže odjemalca, ki ostane povezan. Prekinite in znova vzpostavite povezavo prek podprtega odjemalca, nato potrdite, da so nove poti na napravi.

Nazadnje povežite dnevnik povezav z naslovom, ki ga je prejel odjemalec, in test ponovite dovoljkrat, da zadene več kot eno povezavo. Ena uspešna zahteva po popravku dokazuje, da ena pot deluje, zahtevek pa je bil o drugi.