AWS Client VPN met onderbroke toegang: ondersoek elke gekoppelde subnet

’n Gebruiker maak verbinding, open die interne app en kry ’n antwoord; ’n kollega op dieselfde eindpunt kry ’n timeout van ’n identiese skootrekenaar op dieselfde Wi-Fi. Daardie patroon is die kenmerk van ’n client VPN-eindpunt met meer as een gekoppelde subnet, waar die paaie nie gelykwaardig is nie. Ek werk dit van die console af na buite, want twee oortjies bepaal of die res van die ondersoek die moeite werd is. Niks in die client-konfigurasie verduidelik dit nie.

Begin by die eindpunt en lys die koppelings

In die VPC-konsole, open Client VPN endpoints, kies die eindpunt en lees die Associations-oortjie. Elke koppeling is ’n subnet in ’n Availability Zone, en ’n client beland op die een wat die diens kies wanneer die verbinding gebou word. Let op die subnet-ID’s en die roetetabel wat elkeen werklik gebruik, want daardie twee lyste is die vergelyking wat jy op die punt staan om te maak.

As die eindpunt net een koppeling wys, is hierdie teorie verkeerd en is die client die beter verdagte.

Vergelyk die eindpunt se roetetabel met elke koppeling

Open die Route table-oortjie op dieselfde eindpunt. Elke bestemming-CIDR daar het ’n teiken, en vir ’n client VPN is die teiken ’n koppeling eerder as ’n gateway. AWS vereis ’n bestemmingsinskrywing vir elke gekoppelde subnet, so ’n roete wat net een van hulle teiken, maak toegang afhanklik van waar die sessie beland het. Kontroleer die bestemming wat jy werklik omgee, en kontroleer dan die magtigingsreël daarvan, want ’n roete verskaf die pad en ’n reël besluit wie dit mag gebruik.

Sodra jy albei lae tabelleer, is die fout moeilik om mis te kyk.

Ry twee is die hele fout in die meeste tickets. Die eindpuntroete is daar, so niemand kyk verder nie, en die pakkie sterf een sprong later binne die VPC.

Volg elke subnet in sy effektiewe roetetabel in

’n Subnet sonder ’n eksplisiete roetetabelkoppeling erf die VPC se hooftabel. Lees die tabel wat werklik van krag is, nie die een wie se naam reg lyk nie, en vergelyk bestemming en teiken eerder as die etiket op die ry.

Die AWS gids vir onderbroke toegang beskryf dit as roetebedekking oor koppelings, wat die regte model is. Die eindpunt kry die pakkie by ’n subnet uit, en daardie subnet se tabel moet steeds weet waar die toepassingsnetwerk woon.

Maak die ontbrekende ry reg in die tabel wat dit besit. Om ’n hele roetetabel van ’n werkende subnet te kopieer, kopieer ook internet-, toestel- en isolasiekeuses wat nooit vir hierdie een bedoel was nie, en daardie ruil is gewoonlik slegter as die onderbreking waarmee jy begin het.

Kontroleer magtigingsreëls, dan die pad terug

Magtigingsreëls is per bestemming en per groep, en word apart van roetes geëvalueer. ’n Bestemming met roetes oral maar geen reël vir die gebruiker se groep nie, gedra hom soos ’n swart gat met ’n roetetabel wat gesond lyk.

Die terugpad verdien dieselfde aandag. ’n Peering-verbinding benodig ’n roete in die toepassing-VPC wat terugwys na die client-CIDR, sekuriteitsgroepreëls wat die verkeer aan albei kante toelaat, en netwerk-ACL’s wat dit nie laat val nie. Eenrigting-bereikbaarheid, waar ping werk en die TCP-handskakeling nie, wys gewoonlik na ’n ACL of ’n sekuriteitsgroep eerder as na die VPN.

Die eindpunt se eie sekuriteitsgroepe sit op die koppeling se elastiese netwerkkoppelvlakke, so ’n reël wat die toepassing se poort vanaf die client-CIDR toelaat, moet aan die koppeling geheg word, nie net aan die instansie nie.

Verifieer met ’n herverbinding, nie een gelukkige versoek nie

Met split tunnel word eindpuntroetes gestoot wanneer die verbinding tot stand gebring word, so ’n veranderde roetestel bereik nooit ’n client wat verbind bly nie. Ontkoppel en verbind weer deur die ondersteunde client, en bevestig dan dat die nuwe roetes op die masjien teenwoordig is.

Laastens, korreleer die verbindingslog met die adres wat die client ontvang het, en herhaal die toets genoeg keer om meer as een koppeling te tref. ’n Enkele suksesvolle versoek ná ’n regstelling bewys dat een pad werk, en die ticket het oor die ander een gegaan.