AWS Client VPN: inloggen lukt, maar het subnet blijft onbereikbaar

Je client zegt Connected, het certificaat is geldig, en de intranetpagina loopt nog steeds in een time-out. Dat gat is bijna nooit authenticatie. AWS Client VPN autoriseert bestemmingen apart van de login, en de twee gebruikelijke oorzaken zijn een groepswaarde die niet overeenkomt met wat de identiteitsprovider stuurde en een specifiekere bestemmingsregel die de brede regel verslaat. Beide zijn zichtbaar in de endpointconfiguratie zodra je weet waar je moet kijken.

De login slaagde; de regel kwam niet overeen

Authenticatie beantwoordt wie de gebruiker is. Autorisatieregels beantwoorden welke netwerkprefixen die identiteit mag bereiken. Een gebruiker kan de eerste halen en op de tweede falen, en de client geeft je weinig meer dan een verbinding die blijft staan terwijl elk verzoek in een time-out loopt.

Begin met te bevestigen dat de endpoint een autorisatieregel heeft waarvan de bestemming het falende adres bevat. Als er geen passende regel is, gedraagt de verbinding zich correct; het beleid ontbreekt.

Waar de groepswaarde werkelijk vandaan komt

Bij Active Directory bevat het veld access-group de SID van de groep, niet de weergavenaam. Bij SAML-federatie bevat het de groeps-ID of -naam die het geconfigureerde SAML-groepsattribuut werkelijk draagt. Kopieer de waarde uit de assertion of uit de directory-opzoeking, niet van een wikipagina.

Een IAM-groep is een ander controlevlak. Toestemming om een Client VPN-endpoint te beheren maakt van een IAM-groep nog geen VPN-groep van een gebruiker, en een IAM-groepsnaam in het veld access-group plakken vertaalt die niet naar een AD-SID of een SAML-attribuutwaarde.

Een groep met een vergelijkbare naam in een andere directory bewijst niets. Controleer de authenticatiemethode van de endpoint en het lidmaatschap of de assertion van de gebruiker in datzelfde systeem.

Langste prefix wint, ook 0.0.0.0/0

Autorisatie wordt beoordeeld op de langste prefixovereenkomst, en de regel voor alle bestemmingen wordt als laatste beoordeeld, niet als eerste. Voeg een regel 10.46.0.0/16 voor Engineering toe en een regel 0.0.0.0/0 voor iedereen, en een gebruiker buiten Engineering bereikt 10.46.20.10 via de brede regel nog steeds niet.

Hier kan een oplossing misgaan. De smalle regel verwijderen herstelt de toegang van de gebruiker en geeft dat subnet ook aan elke identiteit die door de brede regel wordt gedekt. Bouw de matrix groep naar netwerk voordat je iets verwijdert, en noteer welke groepen welk bereik horen te bereiken. Deze regels staan alleen toe; er is geen weigeringsitem om een uitzondering uit een brede toestemming te snijden.

Wijzigingen hebben ook een verse verbinding nodig om eerlijk te worden beoordeeld. Verbind de client opnieuw na het bewerken van regels en test daarna opnieuw.

Scheid autorisatie van het datapad

Een regel die overeenkomt is geen route. De endpoint heeft een gekoppeld subnet en een route-tabelinvoer voor de bestemming nodig, en de beveiligingsgroep van de doelresource moet het verkeer accepteren. Retourverkeer en DNS moeten ook werken.

Test een gebruiker die zou moeten slagen en een gebruiker die uitgesloten hoort te blijven. Beiden kunnen inloggen terwijl slechts één het subnet bereikt, en dat verschil is het bewijs dat je wilt.

Als een IP-adres werkt maar een hostnaam niet, kijk dan naar de resolver voordat je de autorisatie aanraakt. Als geen enkele route het adres dekt, herstel dan de koppeling of de routetabel. Als het pakket aankomt en de dienst weigert het, is het beleid van die dienst de volgende stop. De autorisatiematrix naar alle gebruikers verbreden verbergt welke van die lagen werkelijk stuk was.

Voordat je het ticket sluit, leg je de identiteitsbron, de exacte groepswaarde, de bestemmingsprefixen en de route die het verkeer draagt vast. Die notitie maakt het volgende bericht over verbonden maar geen toegang tot een vergelijking van twee minuten in plaats van weer een ronde gissen.