AWS Client VPN: inloggningen lyckas men undernätet går inte att nå

Din klient säger Connected, certifikatet är giltigt och intranetsidan tar fortfarande slut i en timeout. Den luckan är nästan aldrig autentisering. AWS Client VPN auktoriserar destinationer separat från inloggningen, och de två vanliga orsakerna är ett gruppvärde som inte matchar det identitetsleverantören skickade och en mer specifik destinationsregel som slår den breda regeln. Båda syns i endpoint-konfigurationen när du vet var du ska titta.

Inloggningen lyckades; regeln matchade inte

Autentisering svarar på vem användaren är. Auktorisationsreglerna svarar på vilka nätverksprefix den identiteten får nå. En användare kan klara det första och misslyckas med det andra, och klienten ger dig inte mycket mer än en anslutning som hålls uppe medan varje begäran tar slut i en timeout.

Börja med att bekräfta att endpointen har en auktorisationsregel vars destination innehåller adressen som misslyckas. Om det inte finns någon matchande regel beter sig anslutningen korrekt; det är policyn som saknas.

Var gruppvärdet egentligen kommer ifrån

Med Active Directory innehåller fältet access-group gruppens SID, inte dess visningsnamn. Med SAML-federation innehåller det grupp-ID eller namn som det konfigurerade SAML-gruppattributet faktiskt bär. Kopiera värdet från assertion eller katalogslaget, inte från en wikisida.

En IAM-grupp är ett annat kontrollplan. Behörighet att administrera en Client VPN-endpoint gör inte en IAM-grupp till användarens VPN-grupp, och att klistra in ett IAM-gruppnamn i fältet access-group översätter det inte till ett AD-SID eller ett SAML-attributvärde.

En grupp med liknande namn i en annan katalog bevisar ingenting. Kontrollera endpointens autentiseringsmetod och användarens medlemskap eller assertion i samma system.

Längsta prefixet vinner, även 0.0.0.0/0

Auktorisation utvärderas efter längsta prefixmatchning, och regeln för alla destinationer utvärderas sist, inte först. Lägg till en regel 10.46.0.0/16 för Engineering och en regel 0.0.0.0/0 för alla, och en användare utanför Engineering kan fortfarande inte nå 10.46.20.10 genom den breda regeln.

Här kan en rättelse gå fel. Att ta bort den smala regeln återställer användarens åtkomst och ger också det undernätet till varje identitet som den breda regeln omfattar. Bygg grupp-till-nätverk-matrisen innan du tar bort något och skriv ned vilka grupper som ska nå vilket intervall. Dessa regler tillåter bara; det finns ingen nekningspost att skära ut ett undantag ur en bred tillåtelse med.

Ändringar behöver också en färsk anslutning för att bedömas rättvist. Anslut klienten igen efter att du redigerat regler och testa sedan igen.

Separera auktorisation från datavägen

En regel som matchar är inte en route. Endpointen behöver ett associerat undernät och en post i routningstabellen för destinationen, och målresursens säkerhetsgrupp måste acceptera trafiken. Returtrafik och DNS måste också fungera.

Testa en användare som borde lyckas och en användare som borde hållas utanför. Båda kan logga in medan bara en når undernätet, och den skillnaden är beviset du vill ha.

Om en IP-adress fungerar men ett värdnamn inte, titta på resolvern innan du rör auktorisationen. Om ingen route täcker adressen, rätta associationen eller routningstabellen. Om paketet kommer fram och tjänsten avvisar det är den tjänstens policy nästa stopp. Att bredda auktorisationsmatrisen till alla användare döljer vilket av dessa lager som faktiskt var trasigt.

Innan du stänger ärendet, registrera identitetskällan, det exakta gruppvärdet, destinationsprefixen och routen som bär trafiken. Den anteckningen gör nästa rapport om ansluten men utan åtkomst till en jämförelse på två minuter i stället för ännu en runda gissningar.