AWS Client VPN: innloggingen lykkes, men subnettet er ikke tilgjengelig

Klienten sier Connected, sertifikatet er gyldig, og intranettsiden løper fortsatt ut i en timeout. Det gapet er nesten aldri autentisering. AWS Client VPN autoriserer destinasjoner separat fra innlogging, og de to vanlige årsakene er en gruppeverdi som ikke samsvarer med det identitetsleverandøren sendte, og en mer spesifikk destinasjonsregel som slår den brede regelen. Begge er synlige i endpoint-konfigurasjonen når du vet hvor du skal se.

Innloggingen lyktes; regelen samsvarte ikke

Autentisering svarer på hvem brukeren er. Autorisasjonsregler svarer på hvilke nettverksprefikser den identiteten kan nå. En bruker kan bestå det første og feile på det andre, og klienten gir deg lite mer enn en tilkobling som blir stående mens hver forespørsel løper ut i en timeout.

Begynn med å bekrefte at endepunktet har en autorisasjonsregel der destinasjonen inneholder adressen som feiler. Hvis det ikke finnes noen samsvarende regel, oppfører tilkoblingen seg riktig; det er policyen som mangler.

Hvor gruppeverdien faktisk kommer fra

Med Active Directory inneholder feltet access-group gruppens SID, ikke visningsnavnet. Med SAML-føderasjon inneholder det gruppe-ID-en eller navnet som det konfigurerte SAML-gruppeattributtet faktisk bærer. Kopier verdien fra assertion eller katalogoppslaget, ikke fra en wikiside.

En IAM-gruppe er et annet kontrollplan. Tillatelse til å administrere et Client VPN-endepunkt gjør ikke en IAM-gruppe til brukerens VPN-gruppe, og det å lime inn et IAM-gruppenavn i feltet access-group oversetter det ikke til en AD-SID eller en SAML-attributtverdi.

En gruppe med lignende navn i en annen katalog beviser ingenting. Kontroller endepunktets autentiseringsmetode og brukerens medlemskap eller assertion i det samme systemet.

Lengste prefiks vinner, også 0.0.0.0/0

Autorisasjon vurderes etter lengste prefikssamsvar, og regelen for alle destinasjoner vurderes sist, ikke først. Legg til en regel 10.46.0.0/16 for Engineering og en regel 0.0.0.0/0 for alle, og en bruker utenfor Engineering kan fortsatt ikke nå 10.46.20.10 gjennom den brede regelen.

Det er her en rettelse kan gå galt. Sletting av den smale regelen gjenoppretter brukerens tilgang og gir også det subnettet til hver identitet som dekkes av den brede regelen. Bygg gruppe-til-nettverk-matrisen før du sletter noe, og skriv ned hvilke grupper som skal nå hvilket område. Disse reglene tillater bare; det finnes ingen nektelse å skjære et unntak ut av en bred tillatelse med.

Endringer trenger også en fersk tilkobling for å bli vurdert rettferdig. Koble til klienten på nytt etter at du har redigert regler, og test deretter igjen.

Skill autorisasjon fra datastien

En regel som samsvarer er ikke en rute. Endepunktet trenger et tilknyttet subnett og en oppføring i rutetabellen for destinasjonen, og sikkerhetsgruppen til målressursen må godta trafikken. Returtrafikk og DNS må også fungere.

Test en bruker som skal lykkes og en bruker som skal holdes utenfor. Begge kan logge inn mens bare én når subnettet, og den forskjellen er beviset du vil ha.

Hvis en IP-adresse virker men et vertsnavn ikke, se på resolveren før du rører autorisasjonen. Hvis ingen rute dekker adressen, rett opp tilknytningen eller rutetabellen. Hvis pakken kommer frem og tjenesten avviser den, er tjenestens policy neste stopp. Å utvide autorisasjonsmatrisen til alle brukere skjuler hvilket av disse lagene som faktisk var ødelagt.

Før du lukker saken, noter identitetskilden, den nøyaktige gruppeverdien, destinasjonsprefiksene og ruten som bærer trafikken. Den noten gjør den neste meldingen om tilkoblet uten tilgang til en sammenligning på to minutter i stedet for nok en runde med gjetting.