Pabalik-balik na pag-access sa AWS Client VPN: siyasatin ang bawat nakaugnay na subnet

Kumokonekta ang isang user, binubuksan ang internal na app at nakakakuha ng sagot; ang isang katrabaho sa parehong endpoint ay nakakakuha ng timeout mula sa kaparehong laptop sa parehong Wi-Fi. Ang pattern na iyon ay ang pirma ng isang endpoint ng client VPN na may higit sa isang nakaugnay na subnet, kung saan hindi pantay ang mga landas. Sinusuri ko ito mula sa console palabas, dahil dalawang tab ang nagpapasya kung sulit pa ang natitirang imbestigasyon. Wala sa configuration ng kliyente ang nagpapaliwanag nito.

Magsimula sa endpoint at ilista ang mga asosasyon

Sa console ng VPC, buksan ang Client VPN endpoints, piliin ang endpoint at basahin ang tab na Associations. Ang bawat asosasyon ay isang subnet sa isang availability zone, at ang kliyente ay lumalapag sa kung alin ang pipiliin ng serbisyo kapag binubuo ang koneksyon. Itala ang mga ID ng subnet at ang route table na aktuwal na ginagamit ng bawat isa, dahil ang dalawang listahang iyon ang paghahambing na gagawin mo.

Kung isang asosasyon lang ang ipinapakita ng endpoint, mali ang teoryang ito at ang kliyente ang mas mahusay na pinaghihinalaan.

Ihambing ang route table ng endpoint sa bawat asosasyon

Buksan ang tab na Route table sa parehong endpoint. Bawat destination CIDR doon ay may target, at sa isang client VPN ang target ay asosasyon at hindi gateway. Kailangan ng AWS ng destination entry para sa bawat nakaugnay na subnet, kaya ang rutang tumuturo lamang sa isa sa kanila ay ginagawang nakadepende ang access sa kung saan lumapag ang sesyon. Suriin ang destination na talagang mahalaga sa iyo, pagkatapos ang authorization rule nito, dahil ang ruta ay nagbibigay ng landas at ang rule ang nagpapasya kung sino ang puwedeng gumamit nito.

Kapag naitabi mo ang dalawang layer, mahirap nang hindi mapansin ang pagkabigo.

Ang ikalawang hilera ang buong bug sa karamihan ng ticket. Nandiyan ang ruta ng endpoint, kaya walang tumitingin pa sa malayo, at namamatay ang packet isang hop lang pagkatapos sa loob ng VPC.

Sundan ang bawat subnet hanggang sa epektibong route table nito

Ang subnet na walang malinaw na asosasyon sa route table ay nagmamana ng pangunahing table ng VPC. Basahin ang table na aktuwal na umiiral, hindi ang mukhang tama ang pangalan, at ihambing ang destination at target sa halip na ang label sa hilera.

Ang gabay ng AWS tungkol sa pabalik-balik na pag-access ay inilalarawan ito bilang saklaw ng ruta sa mga asosasyon, na siyang tamang modelo. Dinadala ng endpoint ang packet sa isang subnet, at kailangan pa ring malaman ng table ng subnet na iyon kung saan naroon ang network ng aplikasyon.

Ayusin ang nawawalang hilera sa table na nagmamay-ari nito. Ang pagkopya ng buong route table mula sa gumaganang subnet ay kinokopya rin ang mga pagpipilian sa internet, appliance at paghihiwalay na hindi kailanman sinadya para dito, at ang palitang iyon ay karaniwang mas malala kaysa sa outage na sinimulan mo.

Suriin ang mga authorization rule, pagkatapos ang pabalik na landas

Ang mga authorization rule ay bawat destination at bawat grupo, at sinusuri nang hiwalay sa mga ruta. Ang destination na may ruta sa lahat ng dako ngunit walang rule para sa grupo ng user ay kumikilos na parang black hole na may route table na mukhang maayos.

Ang pabalik na landas ay karapat-dapat sa parehong atensyon. Ang koneksyong peering ay nangangailangan ng ruta sa VPC ng app pabalik sa CIDR ng kliyente, mga rule ng security group na nagpapahintulot sa trapiko sa dalawang dulo, at mga network ACL na hindi ito tinatapon. Ang one-way reachability, kung saan gumagana ang ping at hindi ang TCP handshake, ay karaniwang tumuturo sa isang ACL o security group at hindi sa VPN.

Ang sariling mga security group ng endpoint ay nasa elastic network interfaces ng asosasyon, kaya ang rule na nagpapahintulot sa port ng app mula sa CIDR ng kliyente ay dapat ikabit sa asosasyon, hindi lamang sa instance.

I-verify sa muling pagkonekta, hindi sa isang mapalad na kahilingan

Sa split tunnel, ipinapadala ang mga ruta ng endpoint kapag nabuo ang koneksyon, kaya ang nabagong set ng ruta ay hindi kailanman nakakaabot sa kliyenteng nananatiling konektado. Putulin at muling kumonekta sa sinusuportahang kliyente, pagkatapos ay kumpirmahin na naroon ang mga bagong ruta sa makina.

Sa huli, iugnay ang log ng koneksyon sa address na natanggap ng kliyente, at ulitin ang pagsubok nang sapat na beses upang maabot ang higit sa isang asosasyon. Ang isang matagumpay na kahilingan pagkatapos ng pagwawasto ay nagpapatunay na gumagana ang isang landas, at ang ticket ay tungkol sa isa pa.