Intermita aliro per AWS Client VPN: kontrolu ĉiun ligitan subreton

Uzanto konektiĝas, malfermas la internan aplikaĵon kaj ricevas respondon; kolego ĉe la sama finpunkto ricevas tempolimon de identa tekkomputilo en la sama Wi-Fi. Tiu ŝablono estas la subskribo de client VPN-finpunkto kun pli ol unu ligita subreto, kie la vojoj ne estas egalvaloraj. Mi iras tra tio de la konzolo eksteren, ĉar du langetoj decidas ĉu la resto de la enketo indas. Nenio en la klienta agordo tion klarigas.

Komencu ĉe la finpunkto kaj listigu la ligojn

En la VPC-konzolo, malfermu Client VPN endpoints, elektu la finpunkton kaj legu la langeton Associations. Ĉiu ligo estas subreto en havebleca zono, kaj kliento surteriĝas sur tiu, kiun la servo elektas kiam la konekto estas konstruata. Notu la ID-ojn de la subretoj kaj la itineran tabelon, kiun ĉiu efektive uzas, ĉar tiuj du listoj estas la komparo, kiun vi baldaŭ faros.

Se la finpunkto montras nur unu ligon, tiu teorio estas malĝusta kaj la kliento estas la pli bona suspektato.

Komparu la itineran tabelon de la finpunkto kun ĉiu ligo

Malfermu la langeton Route table ĉe la sama finpunkto. Ĉiu cela CIDR tie havas celon, kaj ĉe client VPN la celo estas ligo, ne enirejo. AWS postulas celan enskribon por ĉiu ligita subreto, do itinero, kiu celas nur unu el ili, igas la aliron dependa de tio, kie la seanco surteriĝis. Kontrolu la celon, pri kiu vi vere zorgas, poste kontrolu ĝian rajtigan regulon, ĉar itinero liveras la vojon kaj regulo decidas, kiu rajtas uzi ĝin.

Post kiam vi tabuligos ambaŭ tavolojn, la paneo estas malfacile pretervidebla.

La dua vico estas la tuta cimo en la plej multaj biletoj. La itinero de la finpunkto ĉeestas, do neniu rigardas plu, kaj la paketo mortas unu salton poste ene de la VPC.

Sekvu ĉiun subreton en ĝian efektivan itineran tabelon

Subreto sen eksplicita ligo al itinera tabelo heredas la ĉefan tabelon de la VPC. Legu la tabelon, kiu efektive validas, ne tiun, kies nomo aspektas ĝusta, kaj komparu celon kaj celobjekton anstataŭ la etikedon sur la vico.

La gvidilo de AWS pri intermita aliro priskribas tion kiel itineran kovradon trans ligoj, kio estas la ĝusta modelo. La finpunkto portas la paketon al subreto, kaj la tabelo de tiu subreto ankoraŭ devas scii, kie loĝas la aplikaĵa reto.

Riparu la mankan vicon en la tabelo, kiu posedas ĝin. Kopii tutan itineran tabelon de funkcianta subreto ankaŭ kopias elektojn pri interreto, aparatoj kaj izolado, kiuj neniam estis destinitaj por ĉi tiu, kaj tiu interŝanĝo kutime pli malbonas ol la paneo, kun kiu vi komencis.

Kontrolu la rajtigajn regulojn, poste la reiran vojon

Rajtigaj reguloj estas laŭ celo kaj laŭ grupo kaj estas taksataj aparte de itineroj. Celo kun itineroj ĉie sed sen regulo por la grupo de la uzanto kondutas kiel nigra truo kun itinera tabelo, kiu aspektas sana.

La reira vojo meritas la saman atenton. Peering-konekto bezonas itineron en la aplikaĵa VPC montrantan reen al la CIDR de la kliento, regulojn de sekurecaj grupoj, kiuj permesas la trafikon ĉe ambaŭ finoj, kaj retajn ACL-ojn, kiuj ne forĵetas ĝin. Unudirekta atingeblo, kie ping funkcias kaj la TCP-manpremo ne, kutime montras al ACL aŭ sekureca grupo, ne al la VPN.

La propraj sekurecaj grupoj de la finpunkto sidas sur la elastaj retaj interfacoj de la ligo, do regulo, kiu permesas la aplikaĵan pordon el la CIDR de la kliento, devas esti ligita al la ligo, ne nur al la instanco.

Kontrolu per rekonekto, ne per unu bonŝanca peto

Ĉe split tunnel, la itineroj de la finpunkto estas puŝataj kiam la konekto establiĝas, do ŝanĝita aro de itineroj neniam atingas klienton, kiu restas konektita. Malkonektu kaj rekonektu per la subtenata kliento, poste konfirmu, ke la novaj itineroj ĉeestas sur la maŝino.

Fine, kunigu la konektan protokolon kun la adreso, kiun la kliento ricevis, kaj ripetu la teston sufiĉe da fojoj por trafi pli ol unu ligon. Unu sukcesa peto post riparo pruvas, ke unu vojo funkcias, kaj la bileto temis pri la alia.