NPS-gruppepolitik er ikke håndhævelse af VPN-ressourcer

To grupper, to adgangsprofiler, én VPN-gateway, og begge grupper ender med at nå de samme servere. Den sædvanlige grund er ikke en brudt politik, men en manglende anden halvdel af designet: NPS afgør, hvem der må etablere en session, og noget andet skal afgøre, hvad den session må nå. Når kun den første halvdel findes, lykkes autorisationen for alle, der godkendes. Politikken gør sit arbejde, og designet er stadig ufuldstændigt.

En netværkspolitik, der matcher en gruppe, er bevis om adgang. Det er ikke bevis om pakker, og kløften mellem de to udsagn er, hvor det meste af dette arbejde foregår.

Find den politik, der faktisk lukkede sessionen ind

NPS vurderer ordnede netværkspolitikker, og den første aktiverede regel, hvis betingelser matcher, vinder. Betingelser kan omfatte gruppemedlemskab for bruger eller computer, forbindelsestype, tid og enhedstilstand. Derfor lukker en bred politik, der er placeret tidligere på listen, en forbindelse ind, før en snævrere regel længere nede overhovedet overvejes. Rækkefølgen er ikke en detalje i grænsefladen; rækkefølgen er politikken.

Læs listen i rækkefølge, og identificér den, der matchede, og notér derefter, hvilke indstillinger den returnerede. Gruppens navn i editoren er ikke resultatet; resultatet er den autorisation, serveren modtog. Hold brugerautorisation og enhedsautorisation adskilt, hvor udrulningen bruger begge, fordi en konto, der må åbne en tunnel, ikke automatisk er en konto, der bør nå enhver intern tjeneste.

RADIUS-svaret er en instruktion, ikke et filter

Attributten Filter-Id bærer navnet på en filterliste. Den leverer ikke et bærbart sæt pakkefilterregler, som enhver modtager forstår, og at sende et navn, som gatewayen aldrig har defineret, håndhæver slet intet. Den samme forsigtighed gælder VLAN-attributter: at tildele en tunnelsession til et VLAN er ikke i sig selv en routet adgangsregel for den bruger.

Det er her, et design, der ser komplet ud på NPS-siden, stille gør ingenting. Bekræft med gatewayleverandørens dokumentation, hvilke autorisationsattributter der understøttes, og hvad modtageren gør med hver af dem, i stedet for at antage, at et standardattributnavn betyder standardadfærd.

Anbring håndhævelsen, hvor trafikken passerer

En gateway, der behandler brugerens pakker, kan anvende et filter for hver session, knytte en gruppe til en gatewaypolitik eller give sessionen en adresse fra en adskilt pulje, som en firewall behandler anderledes. Enhver af disse kan fungere, og de fejler på forskellige måder. Afgør, hvilken mekanisme din gateway understøtter, før du skriver politikken, der navngiver den. Skriv derefter ned, hvad der sker med en session, når mekanismen mangler, fordi tavshed er standarden.

Beskriv den tilsigtede tilladelse i fire dele: kildeidentitet eller gruppe, destination, protokol og port. Tilføj de afhængigheder, brugeren reelt har brug for, såsom DNS eller en godkendelsestjeneste, ellers bryder begrænsningen loginforløb, som ingen fandt på at teste. Skriv reglen mod den grænseflade, der faktisk filtrerer, ikke mod den grænseflade, der tilfældigvis er åben i editoren.

Tag højde for oversættelse også. Hvis en firewall længere nede ser én oversat kildeadresse for hver tunnelbruger, kan den ikke skelne enkeltpersoner alene ud fra den adresse, og en regel skrevet, som om den kunne, vil enten være ubrugelig eller for bred.

Klientprofiler lever på den ikke-betroede side

En administreret VPN-profil kan skubbe ruter, regler for delt tunnel eller applikationsfiltre, og de former, hvordan en velopdragen enhed opfører sig. De er ikke beskyttelse for tjenesten, fordi klienten er den part, du forsøger at begrænse. At fjerne en rute i en profil er heller ikke autorisation, da en klient kan have en anden vej til samme destination.

Behandl klientindstillinger som bekvemmelighed og gatewayindstillinger som kontrol. Når de to er uenige, har gatewayen ret, fordi det er den, der ser pakkerne.

Accepter med to konti, og sporet derefter i rækkefølge

Opret to almindelige testkonti med forskellige tilsigtede tilladelser, etabler friske sessioner, og kontrollér den effektive gatewaypolitik for hver. Test derefter én harmløs tilladt handling og én specifikt nægtet ressource. En mislykket ping beviser meget lidt i sig selv, da ICMP kan være filtreret, mens TCP-tjenesten bagved svarer glad.

Når begge konti stadig får bred adgang, spor i en fast rækkefølge: hvilken politik der matchede, hvilken autorisation svaret indeholdt, og hvad gatewayen gjorde med den. At tilføje flere NPS-attributter, før man bekræfter, at modtageren implementerer dem, er måden, hvorpå et lille autorisationsproblem bliver til et ændringsvindue uden resultat.