Katkendlik juurdepääs AWS Client VPN-iga: kontrollige iga seotud alavõrku

Kasutaja loob ühenduse, avab sisemise rakenduse ja saab vastuse; kolleeg samas lõpp-punktis saab ajutõrke identse sülearvutiga samas Wi-Fi võrgus. See muster on client VPN-i lõpp-punkti tunnus, millel on rohkem kui üks seotud alavõrk ja kus teed ei ole samaväärsed. Käin selle konsoolist väljapoole läbi, sest kaks vahekaarti otsustavad, kas ülejäänud uurimine on seda väärt. Kliendi konfiguratsioonis ei selgita seda miski.

Alustage lõpp-punktist ja loetlege seosed

VPC konsoolis avage Client VPN endpoints, valige lõpp-punkt ja lugege vahekaarti Associations. Iga seos on alavõrk kättesaadavuse tsoonis ja klient maandub sellele, mille teenus ühenduse loomisel valib. Pange kirja alavõrkude ID-d ja marsruuditabel, mida igaüks tegelikult kasutab, sest need kaks loendit on võrdlus, mille te kohe teete.

Kui lõpp-punkt näitab ainult ühte seost, on see teooria vale ja klient on parem kahtlusalune.

Võrrelge lõpp-punkti marsruuditabelit iga seosega

Avage samas lõpp-punktis vahekaart Route table. Igal siht-CIDR-il on seal sihtmärk ja client VPN-i puhul on sihtmärgiks seos, mitte lüüs. AWS nõuab sihtkirjet iga seotud alavõrgu kohta, seega ainult ühte neist sihtiv marsruut teeb juurdepääsu sõltuvaks sellest, kuhu seanss maandus. Kontrollige sihti, mis teile tegelikult oluline on, seejärel selle autoriseerimisreeglit, sest marsruut annab tee ja reegel otsustab, kes seda kasutada tohib.

Kui olete mõlemad kihid tabelisse pannud, on riket raske mitte märgata.

Teine rida on enamikus piletites kogu viga. Lõpp-punkti marsruut on olemas, nii et keegi ei vaata kaugemale, ja pakett sureb ühe hüppe hiljem VPC sees.

Jälgige iga alavõrku selle kehtiva marsruuditabelini

Alavõrk, millel pole otsest marsruuditabeli seost, pärib VPC põhitabeli. Lugege tabelit, mis tegelikult kehtib, mitte seda, mille nimi tundub õige, ja võrrelge sihti ja sihtmärki, mitte rea silti.

AWS-i katkendliku juurdepääsu juhend kirjeldab seda marsruutide katvusena üle seoste, mis on õige mudel. Lõpp-punkt viib paketi alavõrku ja selle alavõrgu tabel peab ikka teadma, kus rakenduse võrk asub.

Parandage puuduv rida tabelis, millele see kuulub. Terve marsruuditabeli kopeerimine töötavast alavõrgust kopeerib ka interneti, seadme ja isolatsiooni valikud, mida selle jaoks kunagi ette ei nähtud, ja see vahetus on tavaliselt hullem kui tõrge, millega alustasite.

Kontrollige autoriseerimisreegleid, seejärel tagasiteed

Autoriseerimisreeglid on sihi ja grupi kohta ning neid hinnatakse marsruutidest eraldi. Siht, millel on marsruudid igal pool, aga kasutaja grupile reeglit pole, käitub nagu must auk terve välimusega marsruuditabeliga.

Tagasitee väärib sama tähelepanu. Peering-ühendus vajab rakenduse VPC-s marsruuti tagasi kliendi CIDR-i poole, turvagrupi reegleid, mis lubavad liiklust mõlemas otsas, ja võrgu-ACL-e, mis seda ei viska. Ühesuunaline kättesaadavus, kus ping töötab ja TCP käepigistus mitte, viitab tavaliselt ACL-ile või turvagrupile, mitte VPN-ile.

Lõpp-punkti enda turvagrupid asuvad seose elastsetel võrguliidestel, seega reegel, mis lubab rakenduse porti kliendi CIDR-ist, tuleb kinnitada seose, mitte ainult eksemplari külge.

Kontrollige uuesti ühendudes, mitte ühe õnneliku päringuga

Split tunneliga lükatakse lõpp-punkti marsruudid ühenduse loomisel, seega muutunud marsruudikomplekt ei jõua kunagi kliendini, mis jääb ühendatuks. Katkestage ja looge ühendus uuesti toetatud kliendi kaudu, seejärel kinnitage, et uued marsruudid on masinas olemas.

Lõpuks seostage ühenduste logi aadressiga, mille klient sai, ja korrake testi piisavalt kordi, et tabada rohkem kui ühte seost. Üks õnnestunud päring pärast parandust tõestab, et üks tee töötab, ja pilet oli teise kohta.