Katkonainen pääsy AWS Client VPN:llä: tarkista jokainen liitetty aliverkko

Käyttäjä yhdistää, avaa sisäisen sovelluksen ja saa vastauksen; kollega samassa päätepisteessä saa aikakatkaisun identtiseltä kannettavalta samassa Wi-Fi-verkossa. Tämä kuvio on client VPN -päätepisteen tunnus, jolla on useampi kuin yksi liitetty aliverkko ja jossa polut eivät ole samanarvoisia. Käyn tämän läpi konsolista ulospäin, koska kaksi välilehteä ratkaisevat, kannattaako muu tutkinta. Mikään asiakkaan kokoonpanossa ei selitä sitä.

Aloita päätepisteestä ja luettele liitokset

Avaa VPC-konsolissa Client VPN endpoints, valitse päätepiste ja lue Associations-välilehti. Jokainen liitos on aliverkko saatavuusalueella, ja asiakas laskeutuu sille, jonka palvelu valitsee yhteyttä rakennettaessa. Merkitse muistiin aliverkkojen ID:t ja reititystaulu, jota kukin todella käyttää, sillä nämä kaksi listaa ovat vertailu, jonka aiot tehdä.

Jos päätepiste näyttää vain yhden liitoksen, tämä teoria on väärä ja asiakas on parempi epäilty.

Vertaa päätepisteen reititystaulua jokaiseen liitokseen

Avaa Route table -välilehti samassa päätepisteessä. Jokaisella kohde-CIDR:llä on siellä kohde, ja client VPN:ssä kohde on liitos eikä yhdyskäytävä. AWS vaatii kohdemerkinnän jokaiselle liitetylle aliverkolle, joten reitti, joka osoittaa vain yhteen niistä, tekee pääsystä riippuvan siitä, mihin istunto laskeutui. Tarkista kohde, josta todella välität, ja sitten sen valtuutussääntö, sillä reitti antaa polun ja sääntö päättää, kuka saa käyttää sitä.

Kun taulukoit molemmat kerrokset, vikaa on vaikea olla huomaamatta.

Toinen rivi on useimmissa tiketeissä koko bugi. Päätepisteen reitti on olemassa, joten kukaan ei katso pidemmälle, ja paketti kuolee yhden hypyn myöhemmin VPC:n sisällä.

Seuraa jokainen aliverkko sen voimassa olevaan reititystauluun

Aliverkko, jolla ei ole nimenomaista reititystaululiitosta, perii VPC:n päätaulun. Lue taulu, joka todella on voimassa, älä sitä, jonka nimi näyttää oikealta, ja vertaa kohdetta ja kohdetta eikä rivin merkintää.

AWS:n katkonaisen pääsyn opas kuvaa tämän reittien kattavuutena liitosten yli, mikä on oikea malli. Päätepiste vie paketin aliverkkoon, ja sen aliverkon taulun on vielä tiedettävä, missä sovellusverkko sijaitsee.

Korjaa puuttuva rivi taulussa, joka sen omistaa. Koko reititystaulun kopioiminen toimivasta aliverkosta kopioi myös internet-, laite- ja eristysvalinnat, joita ei koskaan tarkoitettu tälle, ja se vaihtokauppa on yleensä pahempi kuin katkos, jolla aloitit.

Tarkista valtuutussäännöt ja sitten paluupolku

Valtuutussäännöt ovat kohde- ja ryhmäkohtaisia ja ne arvioidaan erillään reiteistä. Kohde, jolla on reitit kaikkialle mutta ei sääntöä käyttäjän ryhmälle, käyttäytyy kuin musta aukko, jonka reititystaulu näyttää terveeltä.

Paluupolku ansaitsee saman huomion. Peering-yhteys tarvitsee reitin sovelluksen VPC:ssä takaisin asiakkaan CIDR:iin, molemmissa päissä liikenteen sallivat tietoturvaryhmien säännöt ja verkon ACL:t, jotka eivät pudota sitä. Yksisuuntainen tavoitettavuus, jossa ping toimii mutta TCP-kättely ei, osoittaa yleensä ACL:ään tai tietoturvaryhmään eikä VPN:ään.

Päätepisteen omat tietoturvaryhmät sijaitsevat liitoksen elastisissa verkkoliitännöissä, joten säännön, joka sallii sovelluksen portin asiakkaan CIDR:stä, täytyy olla kiinnitetty liitokseen, ei vain instanssiin.

Varmista uudelleenyhdistämisellä, ei yhdellä onnekkaalla pyynnöllä

Split tunnelissa päätepisteen reitit työnnetään, kun yhteys muodostetaan, joten muuttunut reittijoukko ei koskaan saavuta asiakasta, joka pysyy yhdistettynä. Katkaise ja yhdistä uudelleen tuetulla asiakkaalla ja varmista sitten, että uudet reitit ovat koneella.

Lopuksi korreloi yhteysloki asiakkaan saaman osoitteen kanssa ja toista testi tarpeeksi monta kertaa osuaksesi useampaan kuin yhteen liitokseen. Yksi onnistunut pyyntö korjauksen jälkeen todistaa, että yksi polku toimii, ja tiketti koski toista.