Periodisk åtkomst med AWS Client VPN: granska varje kopplat undernät

En användare ansluter, öppnar den interna appen och får svar; en kollega på samma slutpunkt får timeout från en identisk bärbar dator i samma Wi-Fi. Det mönstret är signaturen för en client VPN-slutpunkt med mer än ett kopplat undernät, där vägarna inte är likvärdiga. Jag går igenom detta från konsolen och utåt, eftersom två flikar avgör om resten av undersökningen är värd besväret. Inget i klientkonfigurationen förklarar det.

Börja vid slutpunkten och lista kopplingarna

I VPC-konsolen öppnar du Client VPN endpoints, väljer slutpunkten och läser fliken Associations. Varje koppling är ett undernät i en tillgänglighetszon, och en klient landar på det som tjänsten väljer när anslutningen byggs. Notera undernätens ID och den rutttabell som var och en faktiskt använder, eftersom de två listorna är den jämförelse du är på väg att göra.

Om slutpunkten visar en enda koppling är teorin fel och klienten den bättre misstänkta.

Jämför slutpunktens rutttabell med varje koppling

Öppna fliken Route table på samma slutpunkt. Varje destinations-CIDR där har ett mål, och för en client VPN är målet en koppling och inte en gateway. AWS kräver en destinationspost för varje kopplat undernät, så en rutt som bara pekar på ett av dem gör åtkomsten beroende av var sessionen landade. Kontrollera destinationen du faktiskt bryr dig om och sedan dess auktoriseringsregel, eftersom en rutt levererar vägen och en regel avgör vem som får använda den.

När du tabellerar båda lagren är felet svårt att missa.

Andra raden är hela felet i de flesta ärenden. Slutpunktens rutt finns, så ingen tittar vidare, och paketet dör ett hopp senare inne i VPC:n.

Följ varje undernät in i dess effektiva rutttabell

Ett undernät utan uttrycklig rutttabellkoppling ärver VPC:ns huvudtabell. Läs tabellen som faktiskt gäller, inte den vars namn ser rätt ut, och jämför destination och mål i stället för etiketten på raden.

AWS vägledning för periodisk åtkomst beskriver detta som ruttäckning över kopplingar, vilket är rätt modell. Slutpunkten får paketet till ett undernät, och det undernätets tabell måste fortfarande veta var applikationsnätet bor.

Rätta den saknade raden i tabellen som äger den. Att kopiera en hel rutttabell från ett fungerande undernät kopierar också internet-, apparat- och isoleringsval som aldrig var avsedda för detta, och den byteshandeln är oftast värre än det avbrott du började med.

Kontrollera auktoriseringsregler, sedan vägen tillbaka

Auktoriseringsregler gäller per destination och per grupp och utvärderas separat från rutter. En destination med rutter överallt men utan regel för användarens grupp beter sig som ett svart hål med en rutttabell som ser frisk ut.

Returvägen förtjänar samma uppmärksamhet. En peering-anslutning behöver en rutt i appens VPC tillbaka till klientens CIDR, säkerhetsgruppsregler som tillåter trafiken i båda ändar och nätverks-ACL:er som inte släpper den. Enkelriktad nåbarhet, där ping fungerar och TCP-handskakningen inte, pekar oftast på en ACL eller en säkerhetsgrupp och inte på VPN:en.

Slutpunktens egna säkerhetsgrupper sitter på kopplingens elastiska nätverksgränssnitt, så en regel som tillåter applikationsporten från klientens CIDR måste kopplas till kopplingen, inte bara till instansen.

Verifiera med en återanslutning, inte med en enda lycklig begäran

Med split tunnel skickas slutpunktens rutter när anslutningen upprättas, så en ändrad ruttuppsättning når aldrig en klient som stannar kvar ansluten. Koppla från och anslut igen via den klient som stöds, och bekräfta sedan att de nya ruttnerna finns på maskinen.

Korrelera till sist anslutningsloggen med adressen klienten fick, och upprepa testet tillräckligt många gånger för att träffa mer än en koppling. En enda lyckad begäran efter en rättelse bevisar att en väg fungerar, och ärendet handlade om den andra.