Pārtraukta piekļuve ar AWS Client VPN: pārbaudiet katru piesaistīto apakštīklu

Lietotājs pieslēdzas, atver iekšējo lietotni un saņem atbildi; kolēģis tajā pašā galapunktā saņem taimautu no identiska portatīvā datora tajā pašā Wi-Fi tīklā. Šis modelis ir client VPN galapunkta pazīme, kuram ir vairāk nekā viens piesaistīts apakštīkls un kur ceļi nav līdzvērtīgi. Es to izskatu no konsoles uz āru, jo divas cilnes izlemj, vai pārējā izmeklēšana ir tā vērta. Nekas klienta konfigurācijā to neizskaidro.

Sāciet ar galapunktu un uzskaitiet asociācijas

VPC konsolē atveriet Client VPN endpoints, izvēlieties galapunktu un izlasiet cilni Associations. Katra asociācija ir apakštīkls pieejamības zonā, un klients nonāk tajā, kuru pakalpojums izvēlas, kad tiek veidots savienojums. Pierakstiet apakštīklu ID un maršrutu tabulu, ko katrs faktiski izmanto, jo šie divi saraksti ir salīdzinājums, ko gatavojaties veikt.

Ja galapunkts rāda tikai vienu asociāciju, šī teorija ir nepareiza, un klients ir labākais aizdomās turamais.

Salīdziniet galapunkta maršrutu tabulu ar katru asociāciju

Atveriet cilni Route table tajā pašā galapunktā. Katram galamērķa CIDR tur ir mērķis, un client VPN gadījumā mērķis ir asociācija, nevis vārteja. AWS pieprasa galamērķa ierakstu katram piesaistītajam apakštīklam, tāpēc maršruts, kas vērsts tikai uz vienu no tiem, padara piekļuvi atkarīgu no tā, kur nolaidās sesija. Pārbaudiet galamērķi, kas jums patiešām svarīgs, pēc tam tā autorizācijas noteikumu, jo maršruts nodrošina ceļu, bet noteikums izlemj, kurš to drīkst izmantot.

Kad abus slāņus esat ievietojis tabulā, kļūdu ir grūti nepamanīt.

Otrā rinda ir viss defekts lielākajā daļā biļešu. Galapunkta maršruts ir, tāpēc neviens neskatās tālāk, un pakete mirst vienu lēcienu vēlāk VPC iekšienē.

Sekojiet katram apakštīklam līdz tā faktiskajai maršrutu tabulai

Apakštīkls bez skaidras maršrutu tabulas asociācijas manto VPC galveno tabulu. Lasiet tabulu, kas faktiski ir spēkā, nevis to, kuras nosaukums izskatās pareizs, un salīdziniet galamērķi un mērķi, nevis rindas apzīmējumu.

AWS pārtrauktas piekļuves rokasgrāmata to apraksta kā maršrutu pārklājumu visās asociācijās, un tas ir pareizais modelis. Galapunkts nogādā paketi apakštīklā, un šī apakštīkla tabulai joprojām jāzina, kur atrodas lietotnes tīkls.

Izlabojiet trūkstošo rindu tabulā, kurai tā pieder. Visas maršrutu tabulas kopēšana no strādājoša apakštīkla nokopē arī interneta, ierīces un izolācijas izvēles, kas nekad nebija paredzētas šim, un šis maiņas darījums parasti ir sliktāks par pārtraukumu, ar kuru sākāt.

Pārbaudiet autorizācijas noteikumus, pēc tam atgriešanās ceļu

Autorizācijas noteikumi ir katram galamērķim un katrai grupai, un tie tiek vērtēti atsevišķi no maršrutiem. Galamērķis ar maršrutiem visur, bet bez noteikuma lietotāja grupai, uzvedas kā melnais caurums ar veselīgi izskatāmu maršrutu tabulu.

Atgriešanās ceļš ir pelnījis tādu pašu uzmanību. Peering savienojumam nepieciešams maršruts lietotnes VPC atpakaļ uz klienta CIDR, drošības grupu noteikumi, kas pieļauj trafiku abos galos, un tīkla ACL, kas to neizmet. Vienvirziena sasniedzamība, kad ping strādā, bet TCP rokasspiediens ne, parasti norāda uz ACL vai drošības grupu, nevis uz VPN.

Paša galapunkta drošības grupas atrodas asociācijas elastīgajās tīkla saskarnēs, tāpēc noteikums, kas pieļauj lietotnes portu no klienta CIDR, jāpievieno asociācijai, nevis tikai instancei.

Pārbaudiet ar atkārtotu savienojumu, nevis ar vienu veiksmīgu pieprasījumu

Ar split tunnel galapunkta maršruti tiek nosūtīti, kad savienojums tiek izveidots, tāpēc mainīta maršrutu kopa nekad nesasniedz klientu, kas paliek savienots. Atvienojiet un atkal pievienojiet ar atbalstīto klientu, pēc tam pārliecinieties, ka jaunie maršruti ir iekārtā.

Visbeidzot, sasaistiet savienojumu žurnālu ar adresi, ko klients saņēma, un atkārtojiet testu pietiekami daudz reižu, lai sasniegtu vairāk nekā vienu asociāciju. Viena veiksmīga pieprasījuma pēc labojuma pierāda, ka viens ceļš strādā, un biļete bija par otru.