NPS-gruppepolicy er ikkje handheving av VPN-ressursar

To grupper, to tilgangsprofilar, éin VPN-gateway, og til slutt når begge gruppene dei same tenarane. Den vanlege årsaka er ikkje ein øydelagd policy, men ein manglande andre halvdel av designet: NPS avgjer kven som kan etablere ein sesjon, og noko anna må avgjere kva den sesjonen kan nå. Når berre den første halvdelen finst, lukkast autorisasjonen for alle som autentiserer seg. Policyen gjer jobben sin, og designet er framleis ufullstendig.

Ein nettverkspolicy som samsvarar med ei gruppe, er bevis om innslepp. Det er ikkje bevis om pakkar, og gapet mellom desse to utsegnene er der mesteparten av dette arbeidet skjer.

Finn policyen som faktisk sleppte sesjonen inn

NPS vurderer ordna nettverkspolicyar, og den første aktiverte regelen der vilkåra samsvarar, vinn. Vilkår kan omfatte gruppemedlemskap for brukar eller datamaskin, tilkoplingstype, tid og einingstilstand. Derfor slepp ein brei policy som står tidlegare på lista, inn ei tilkopling før ein snevrare regel lenger nede i det heile blir vurdert. Rekkjefølgja er ikkje ein detalj i grensesnittet; rekkjefølgja er policyen.

Les lista i rekkjefølgje og identifiser den som samsvarte, og noter deretter kva innstillingar ho returnerte. Namnet på gruppa i editoren er ikkje resultatet; resultatet er autorisasjonen tenaren fekk. Hald brukarautorisasjon og einingautorisasjon åtskilde der utrullinga brukar begge, fordi ein konto som kan opne ein tunnel, ikkje automatisk er ein konto som bør nå kvar intern teneste.

RADIUS-svaret er ein instruks, ikkje eit filter

Ein Filter-Id-attributt ber namnet på ei filterliste. Han leverer ikkje eit berevenleg sett med pakkefilterreglar som alle mottakarar forstår, og å sende eit namn gatewayen aldri har definert, handhevar ingenting i det heile. Den same varsemda gjeld VLAN-attributtar: å tildele ein tunnelsesjon til eit VLAN er ikkje i seg sjølv ein ruta tilgangsregel for den brukaren.

Det er her eit design som ser komplett ut på NPS-sida, stille ikkje gjer noko. Stadfest med dokumentasjonen til gatewayleverandøren kva autorisasjonsattributtar som blir støtta, og kva mottakaren gjer med kvar av dei, i staden for å anta at eit standardattributtnamn tyder standardåtferd.

Plasser handhevinga der trafikken passerer

Ein gateway som handsamar pakkane til brukaren, kan bruke eit filter per sesjon, kople ei gruppe til ein gatewaypolicy eller gje sesjonen ei adresse frå ein avsondra pool som ein brannmur handsamar annleis. Kvar av desse kan fungere, og dei feilar på ulike måtar. Finn ut kva mekanisme gatewayen din støttar, før du skriv policyen som namngjev han. Skriv deretter ned kva som skjer med ein sesjon når mekanismen manglar, fordi stillheit er standarden.

Beskriv den tiltenkte løyvinga i fire delar: kjeldeidentitet eller gruppe, destinasjon, protokoll og port. Legg til avhengnadene brukaren faktisk treng, som DNS eller ein autentiseringsteneste, elles bryt avgrensinga innloggingsflytar ingen tenkte å teste. Skriv regelen mot grensesnittet som faktisk filtrerer, ikkje mot grensesnittet som tilfeldigvis er ope i editoren.

Ta også omsyn til omsetjing. Viss ein brannmur lenger nede ser éi omsett kjeldeadresse for kvar tunnelbrukar, kan han ikkje skilje enkeltpersonar berre frå den adressa, og ein regel skriven som om han kunne, vil anten vere ubrukeleg eller for brei.

Klientprofilar lever på den ikkje-klarerte sida

Ein administrert VPN-profil kan skyve ut ruter, reglar for delt tunnel eller applikasjonsfilter, og dei form gjev korleis ei veloppdragen eining oppfører seg. Dei er ikkje vern for tenesta, fordi klienten er parten du prøver å avgrense. Å fjerne ei rute i ein profil er heller ikkje autorisasjon, sidan ein klient kan ha ein annan veg til same destinasjon.

Behandle klientinnstillingar som komfort og gatewayinnstillingar som kontroll. Når dei to er usamde, har gatewayen rett, fordi det er han som ser pakkane.

Godta med to kontoar, og spor deretter i rekkjefølgje

Opprett to vanlege testkontoar med ulike tiltenkte løyve, etabler nye sesjonar og kontroller den effektive gatewaypolicyen for kvar. Test deretter éin ufarleg tillaten operasjon og éin spesifikt nekta ressurs. Ein mislukka ping beviser svært lite i seg sjølv, sidan ICMP kan vere filtrert medan TCP-tenesta bak svarar nøgd.

Når begge kontoane framleis får brei tilgang, spor i fast rekkjefølgje: kva policy som samsvarte, kva autorisasjon svaret bar, og kva gatewayen gjorde med han. Å leggje til fleire NPS-attributtar før du stadfestar at mottakaren implementerer dei, er måten eit lite autorisasjonsproblem blir eit endringsvindauge utan resultat.