AWS Client VPN: innlogginga lukkast, men subnettet er ikkje tilgjengeleg

Klienten seier Connected, sertifikatet er gyldig, og intranettsida går framleis ut i ein timeout. Det gapet er nesten aldri autentisering. AWS Client VPN autoriserer destinasjonar separat frå innlogging, og dei to vanlege årsakene er ein gruppeverdi som ikkje samsvarar med det identitetsleverandøren sende, og ein meir spesifikk destinasjonsregel som slår den breie regelen. Begge er synlege i endpoint-konfigurasjonen når du veit kvar du skal sjå.

Innlogginga lukkast; regelen samsvara ikkje

Autentisering svarar på kven brukaren er. Autorisasjonsreglar svarar på kva nettverksprefiks den identiteten kan nå. Ein brukar kan bestå den første og feile på den andre, og klienten gir deg lite meir enn ei tilkopling som blir ståande medan kvar førespurnad går ut i ein timeout.

Byrja med å stadfeste at endepunktet har ein autorisasjonsregel der destinasjonen inneheld adressa som feilar. Viss det ikkje finst nokon samsvarande regel, oppfører tilkoplinga seg rett; det er policyen som manglar.

Kvar gruppeverdien faktisk kjem frå

Med Active Directory inneheld feltet access-group SID-en til gruppa, ikkje visingsnamnet. Med SAML-føderasjon inneheld det gruppe-ID-en eller namnet som det konfigurerte SAML-gruppeattributtet faktisk ber. Kopier verdien frå assertion eller katalogoppslaget, ikkje frå ei wikiside.

Ei IAM-gruppe er eit anna kontrollplan. Løyve til å administrere eit Client VPN-endepunkt gjer ikkje ei IAM-gruppe til VPN-gruppa til brukaren, og det å lime inn eit IAM-gruppenamn i feltet access-group omset det ikkje til ein AD-SID eller ein SAML-attributtverdi.

Ei gruppe med liknande namn i ein annan katalog beviser ingenting. Kontroller autentiseringsmetoden til endepunktet og medlemsskapet eller assertion til brukaren i det same systemet.

Lengste prefiks vinn, òg 0.0.0.0/0

Autorisasjon blir vurdert etter lengste prefikssamsvar, og regelen for alle destinasjonar blir vurdert sist, ikkje først. Legg til ein regel 10.46.0.0/16 for Engineering og ein regel 0.0.0.0/0 for alle, og ein brukar utanfor Engineering kan framleis ikkje nå 10.46.20.10 gjennom den breie regelen.

Det er her ei retting kan gå gale. Sletting av den smale regelen gjenopprettar tilgangen til brukaren og gir òg det subnettet til kvar identitet som blir dekt av den breie regelen. Bygg gruppe-til-nettverk-matrisa før du slettar noko, og skriv ned kva grupper som skal nå kva område. Desse reglane tillèt berre; det finst inga nekting å skjere eit unntak ut av ei brei løyve med.

Endringar treng òg ei fersk tilkopling for å bli vurderte rettferdig. Kople klienten til på nytt etter at du har redigert reglar, og test deretter igjen.

Skil autorisasjon frå datastien

Ein regel som samsvarar er ikkje ei rute. Endepunktet treng eit tilknytt subnett og ei oppføring i rutetabellen for destinasjonen, og sikkerhetsgruppa til målressursen må godta trafikken. Returtrafikk og DNS må òg fungere.

Test ein brukar som skal lukkast og ein brukar som skal haldast utanfor. Begge kan logge inn medan berre éin når subnettet, og den skilnaden er beviset du vil ha.

Viss ei IP-adresse verkar men eit vertsnamn ikkje, sjå på resolveren før du rører autorisasjonen. Viss inga rute dekkjer adressa, rett opp tilknytinga eller rutetabellen. Viss pakken kjem fram og tenesta avviser han, er policyen til tenesta neste stopp. Å utvide autorisasjonsmatrisa til alle brukarar gøymer kva av desse laga som faktisk var øydelagt.

Før du lukkar saka, noter identitetskjelda, den nøyaktige gruppeverdien, destinasjonsprefiksa og ruta som ber trafikken. Den notata gjer den neste meldinga om tilkopla utan tilgang til ein samanliknad på to minutt i staden for nok ein runde med gissing.