Ósamfelldur aðgangur með AWS Client VPN: skoðaðu hvert tengt undirnet

Notandi tengist, opnar innra forritið og fær svar; kollega á sama endapunkti fær tímanum útrunnið frá sams konar fartölvu á sama Wi-Fi. Þetta mynstur er einkenni client VPN endapunkts með fleiri en eitt tengt undirnet, þar sem leiðirnar eru ekki jafngildar. Ég fer í gegnum þetta frá stjórnborðinu og út, því tveir flipar ráða því hvort restin af rannsókninni er þess virði. Ekkert í stillingum biðlarans útskýrir það.

Byrjaðu á endapunktinum og skráðu tengingarnar

Í VPC-stjórnborðinu skaltu opna Client VPN endpoints, velja endapunktinn og lesa flipann Associations. Hver tenging er undirnet í tiltækileiksvæði, og biðlarinn lendir á því sem þjónustan velur þegar tengingin er byggð. Skráðu auðkenni undirnetanna og leiðatöfluna sem hvert þeirra notar í raun, því þessir tveir listar eru samanburðurinn sem þú ert að fara að gera.

Ef endapunkturinn sýnir aðeins eina tengingu er þessi kenning röng og biðlarinn betri grunaður.

Berðu saman leiðatöflu endapunktsins við hverja tengingu

Opnaðu flipann Route table á sama endapunkti. Hvert áfangastaðar-CIDR þar hefur skotmark, og hjá client VPN er skotmarkið tenging en ekki gátt. AWS krefst áfangastaðarfærslu fyrir hvert tengt undirnet, svo leið sem beinist aðeins að einu þeirra gerir aðganginn háðan því hvar lotan lenti. Athugaðu áfangastaðinn sem þér er raunverulega annt um og síðan heimildarreglu hans, því leiðin veitir slóðina og regla ræður því hver má nota hana.

Þegar þú hefur sett bæði lögin í töflu er erfitt að missa bilunina úr sýn.

Önnur röðin er allt villan í flestum miðum. Leið endapunktsins er til staðar, svo enginn lítur lengra, og pakkinn deyr einu hoppi síðar inni í VPC.

Fylgdu hverju undirneti í raunverulega leiðatöflu þess

Undirnet án skýrrar tengingar við leiðatöflu erfir aðaltöflu VPC. Lestu töfluna sem er raunverulega í gildi, ekki þá sem nafnið lítur rétt út, og berðu saman áfangastað og skotmark frekar en merkið á röðinni.

Leiðarvísir AWS um ósamfelldan aðgang lýsir þessu sem leiðaþekju yfir tengingar, sem er rétta líkanið. Endapunkturinn kemur pakkanum til undirnets, og tafla þess undirnets verður samt að vita hvar forritanetið er.

Lagaðu vantar röðina í töflunni sem á hana. Að afrita alla leiðatöflu frá vinnandi undirneti afritar líka val um internet, tæki og einangrun sem var aldrei ætlað þessu, og þessi skipti eru venjulega verri en truflunin sem þú byrjaðir með.

Athugaðu heimildarreglur, svo leiðina til baka

Heimildarreglur eru fyrir hvern áfangastað og hvern hóp og eru metnar aðskilið frá leiðum. Áfangastaður með leiðir hvar sem er en enga reglu fyrir hóp notandans hagar sér eins og svarthol með leiðatöflu sem lítur heilbrigð út.

Leiðin til baka á skilið sömu athygli. Peering-tenging þarf leið í VPC forritsins sem vísar aftur á CIDR biðlarans, reglur öryggishópa sem leyfa umferðina á báðum endum og net-ACL sem sleppa henni ekki. Einátta aðgengi, þar sem ping virkar og TCP-handabandið ekki, bendir venjulega á ACL eða öryggishóp frekar en VPN.

Öryggishópar endapunktsins sjálfs sitja á teygjanlegum netviðmótum tengingarinnar, svo regla sem leyfir gátt forritsins frá CIDR biðlarans verður að vera fest við tenginguna, ekki bara við tilvikið.

Staðfestu með endurtengingu, ekki einni heppinni beiðni

Með split tunnel eru leiðir endapunktsins ýttar þegar tengingin er komin á, svo breytt leiðasett nær aldrei til biðlara sem helst tengdur. Aftengdu og tengdu aftur í gegnum studda biðlarann og staðfestu síðan að nýju leiðirnar séu á vélinni.

Að lokum skaltu tengja tengingarskránna við heimilisfangið sem biðlarinn fékk og endurtaka prófið nógu oft til að hitta fleiri en eina tengingu. Ein farsæl beiðni eftir lagfæringu sannar að ein leið virkar, og miðinn snerist um hina.