AWS Client VPN: login lykkes, men undernettet kan ikke nås
Et vellykket AWS Client VPN-login autoriserer ikke alle undernet. Kontrollér gruppeværdien og den mest specifikke destinationsregel, før du udvider adgangen.
Din klient siger Connected, certifikatet er gyldigt, og intranetsiden løber stadig tør for tid. Det hul er næsten aldrig autentificering. AWS Client VPN autoriserer destinationer adskilt fra login, og de to sædvanlige årsager er en gruppeværdi, der ikke matcher det, identitetsudbyderen sendte, og en mere specifik destinationsregel, der slår den brede regel. Begge kan ses i endpoint-konfigurationen, når du ved, hvor du skal kigge.
Loginet lykkedes; reglen matchede ikke
Autentificering svarer på, hvem brugeren er. Autorisationsregler svarer på, hvilke netværkspræfikser den identitet må nå. En bruger kan bestå det første og fejle på det andet, og klienten giver dig ikke meget mere end en forbindelse, der bliver oppe, mens hver anmodning løber tør for tid.
Begynd med at bekræfte, at endpointet har en autorisationsregel, hvis destination indeholder den adresse, der fejler. Hvis der ikke er nogen matchende regel, opfører forbindelsen sig korrekt; det er politikken, der mangler.
Hvor gruppeværdien egentlig kommer fra
Med Active Directory indeholder access-group-feltet gruppens SID, ikke dens visningsnavn. Med SAML-føderation indeholder det det gruppe-ID eller navn, som det konfigurerede SAML-gruppeattribut faktisk bærer. Kopiér værdien fra assertion eller fra katalogopslaget, ikke fra en wikiside.
En IAM-gruppe er et andet kontrolplan. Tilladelse til at administrere et Client VPN-endpoint gør ikke en IAM-gruppe til brugerens VPN-gruppe, og det oversætter ikke et IAM-gruppenavn, der indsættes i access-group-feltet, til et AD-SID eller en SAML-attributværdi.
En gruppe med et lignende navn i en anden mappe beviser intet. Kontrollér endpointets autentificeringsmetode og brugerens medlemskab eller assertion i samme system.
Længste præfiks vinder, også 0.0.0.0/0
Autorisation vurderes efter længste præfiksmatch, og reglen for alle destinationer vurderes sidst, ikke først. Tilføj en 10.46.0.0/16-regel for Engineering og en 0.0.0.0/0-regel for alle, og en bruger uden for Engineering kan stadig ikke nå 10.46.20.10 gennem den brede regel.
Det er her, en rettelse kan gå galt. Sletning af den snævre regel gendanner brugerens adgang og giver også det undernet til enhver identitet, som den brede regel dækker. Byg gruppe-til-netværk-matricen, før du sletter noget, og skriv ned, hvilke grupper der skal nå hvilket interval. Disse regler tillader kun; der er ingen nægtelse, hvormed du kan skære en undtagelse ud af en bred tilladelse.
Ændringer kræver også en frisk forbindelse for at blive vurderet fair. Genopret klienten efter redigering af regler, og test igen.
Adskil autorisation fra datastien
En regel, der matcher, er ikke en rute. Endpointet har brug for et tilknyttet undernet og en rute-tabelpost for destinationen, og målressourcens sikkerhedsgruppe skal acceptere trafikken. Returtrafik og DNS skal også virke.
Test en bruger, der burde lykkes, og en bruger, der burde holdes ude. Begge kan logge ind, mens kun én når undernettet, og den forskel er det bevis, du vil have.
Hvis en IP-adresse virker, men et værtsnavn ikke, så kig på resolveren, før du rører autorisationen. Hvis ingen rute dækker adressen, så ret tilknytningen eller rute-tabellen. Hvis pakken ankommer, og tjenesten afviser den, er den tjenestes politik næste stop. At udvide autorisationsmatricen til alle brugere skjuler, hvilket af de lag der faktisk var brudt.
Før du lukker sagen, skal du notere identitetskilden, den præcise gruppeværdi, destinationspræfikserne og den rute, der bærer trafikken. Den note gør den næste melding om forbundet uden adgang til en sammenligning på to minutter i stedet for endnu en runde gætteri.