NPS-gruppepolicy er ikke håndheving av VPN-ressurser

To grupper, to tilgangsprofiler, én VPN-gateway, og til slutt når begge gruppene de samme serverne. Den vanlige årsaken er ikke en ødelagt policy, men en manglende andre halvdel av designet: NPS avgjør hvem som kan etablere en sesjon, og noe annet må avgjøre hva den sesjonen kan nå. Når bare den første halvdelen finnes, lykkes autorisasjonen for alle som autentiserer seg. Policyen gjør jobben sin, og designet er fortsatt ufullstendig.

En nettverkspolicy som samsvarer med en gruppe, er bevis om innslipp. Det er ikke bevis om pakker, og gapet mellom disse to utsagnene er der mesteparten av dette arbeidet skjer.

Finn policyen som faktisk slapp sesjonen inn

NPS vurderer ordnede nettverkspolicyer, og den første aktiverte regelen hvis betingelser samsvarer, vinner. Betingelser kan omfatte gruppemedlemskap for bruker eller datamaskin, tilkoblingstype, tid og enhetstilstand. Derfor slipper en bred policy som står tidligere på listen en tilkobling inn før en snevrere regel lenger ned i det hele tatt vurderes. Rekkefølgen er ikke en detalj i grensesnittet; rekkefølgen er policyen.

Les listen i rekkefølge og identifiser den som samsvarte, og noter deretter hvilke innstillinger den returnerte. Gruppens navn i editoren er ikke resultatet; resultatet er autorisasjonen serveren mottok. Hold brukerautorisasjon og enhetsautorisasjon atskilt der utrullingen bruker begge, fordi en konto som kan åpne en tunnel, ikke automatisk er en konto som bør nå hver intern tjeneste.

RADIUS-svaret er en instruksjon, ikke et filter

En Filter-Id-attributt bærer navnet på en filterliste. Den leverer ikke et bærbart sett med pakkefilterregler som alle mottakere forstår, og å sende et navn gatewayen aldri har definert, håndhever ingenting i det hele tatt. Den samme forsiktigheten gjelder VLAN-attributter: å tildele en tunnelessesjon til et VLAN er ikke i seg selv en rutet tilgangsregel for den brukeren.

Det er her et design som ser komplett ut på NPS-siden, stille ikke gjør noe. Bekreft med gatewayleverandørens dokumentasjon hvilke autorisasjonsattributter som støttes, og hva mottakeren gjør med hver av dem, i stedet for å anta at et standardattributtnavn betyr standardatferd.

Plasser håndhevingen der trafikken passerer

En gateway som behandler brukerens pakker, kan bruke et filter per sesjon, knytte en gruppe til en gatewaypolicy eller gi sesjonen en adresse fra en adskilt pool som en brannmur behandler annerledes. Hver av disse kan fungere, og de feiler på ulike måter. Finn ut hvilken mekanisme gatewayen din støtter, før du skriver policyen som navngir den. Skriv deretter ned hva som skjer med en sesjon når mekanismen mangler, fordi stillhet er standarden.

Beskriv den tiltenkte tillatelsen i fire deler: kildeidentitet eller gruppe, destinasjon, protokoll og port. Legg til avhengighetene brukeren faktisk trenger, som DNS eller en autentiseringstjeneste, ellers bryter begrensningen innloggingsflyter ingen tenkte å teste. Skriv regelen mot grensesnittet som faktisk filtrerer, ikke mot grensesnittet som tilfeldigvis er åpent i editoren.

Ta også høyde for oversettelse. Hvis en brannmur lenger ned ser én oversatt kildeadresse for hver tunnelbruker, kan den ikke skille enkeltpersoner bare fra den adressen, og en regel skrevet som om den kunne, vil enten være ubrukelig eller for bred.

Klientprofiler lever på den ikke-klarerte siden

En administrert VPN-profil kan skyve ut ruter, regler for delt tunnel eller applikasjonsfiltre, og de former hvordan en veloppdragen enhet oppfører seg. De er ikke beskyttelse for tjenesten, fordi klienten er parten du prøver å begrense. Å fjerne en rute i en profil er heller ikke autorisasjon, siden en klient kan ha en annen vei til samme destinasjon.

Behandle klientinnstillinger som bekvemmelighet og gatewayinnstillinger som kontroll. Når de to er uenige, har gatewayen rett, fordi det er den som ser pakkene.

Godta med to kontoer, og spor deretter i rekkefølge

Opprett to vanlige testkontoer med ulike tiltenkte tillatelser, etabler nye sesjoner og kontroller den effektive gatewaypolicyen for hver. Test deretter én ufarlig tillatt operasjon og én spesifikt nektet ressurs. En mislykket ping beviser svært lite i seg selv, siden ICMP kan være filtrert mens TCP-tjenesten bak svarer fornøyd.

Når begge kontoene fortsatt får bred tilgang, spor i fast rekkefølge: hvilken policy som samsvarte, hvilken autorisasjon svaret bar, og hva gatewayen gjorde med den. Å legge til flere NPS-attributter før du bekrefter at mottakeren implementerer dem, er måten et lite autorisasjonsproblem blir et endringsvindu uten resultat.