NPS-groepbeleid is nie VPN-bronafdwinging nie

Twee groepe, twee toegangsprofiele, een VPN-gateway, en albei groepe bereik uiteindelik dieselfde bedieners. Die gewone rede is nie ’n stukkende beleid nie, maar ’n ontbrekende tweede helfte van die ontwerp: NPS besluit wie ’n sessie mag vestig, en iets anders moet besluit wat daardie sessie mag bereik. Wanneer net die eerste helfte bestaan, slaag magtiging vir almal wat authentiseer. Die beleid doen sy werk, en die ontwerp is steeds onvolledig.

’n Netwerkbeleid wat op ’n groep pas, is bewys oor toelating. Dit is nie bewys oor pakkette nie, en die gaping tussen daardie twee stellings is waar die meeste van hierdie werk plaasvind.

Vind die beleid wat die sessie werklik toegelaat het

NPS evalueer geordende netwerkbeleide, en die eerste geaktiveerde reël waarvan die voorwaardes pas, wen. Voorwaardes kan gebruikers- of rekenaargroepildmaatskap, verbindingstipe, tyd en toestand van die toestel insluit. ’n Breë beleid wat vroeër in die lys geplaas is, laat dus ’n verbinding toe voordat ’n nouer reël verder ondertoe ooit oorweeg word. Ordening is nie ’n detail van die koppelvlak nie; dit is die beleid.

Lees die lys in volgorde en identifiseer die een wat gepas het, en let dan op watter instellings dit teruggegee het. Die redigeerder se groepnaam is nie die resultaat nie; die resultaat is die magtiging wat die bediener ontvang het. Hou gebruikersmagtiging en toestelmagtiging apart waar die ontplooiing albei gebruik, want ’n rekening wat ’n tonnel mag oopmaak, is nie outomaties ’n rekening wat elke interne diens behoort te bereik nie.

Die RADIUS-antwoord is ’n opdrag, nie ’n filter nie

’n Filter-Id-kenmerk dra die naam van ’n filterlys. Dit lewer nie ’n draagbare stel pakketfilterreëls wat elke ontvanger verstaan nie, en om ’n naam te stuur wat die gateway nog nooit gedefinieer het nie, dwing glad niks af nie. Dieselfde versigtigheid geld vir VLAN-kenmerke: om ’n tonnelsessie aan ’n VLAN toe te wys, is op sigself nie ’n gerouteerde toegangsreël vir daardie gebruiker nie.

Dit is waar ’n ontwerp wat aan die NPS-kant volledig lyk, stilweg niks doen nie. Bevestig met die gateway-leweransier se dokumentasie watter magtigingskenmerke ondersteun word en wat die ontvanger met elkeen doen, eerder as om te aanvaar dat ’n standaardkenmerknaam standaardgedrag impliseer.

Plaas afdwinging waar die verkeer verbygaan

’n Gateway wat die gebruiker se pakkette verwerk, kan ’n filter vir elke sessie toepas, ’n groep aan ’n gateway-beleid koppel, of die sessie ’n adres gee uit ’n afgesonderde poel wat ’n firewall anders hanteer. Enige van dié kan werk, en hulle faal op verskillende maniere. Identifiseer watter meganisme jou gateway ondersteun voordat jy die beleid skryf wat dit noem. Skryf dan neer wat met ’n sessie gebeur wanneer daardie meganisme ontbreek, want stilte is die verstek.

Beskryf die beoogde toestemming in vier dele: bronidentiteit of groep, bestemming, protokol en poort. Voeg die afhanklikhede by wat die gebruiker werklik nodig het, soos DNS of ’n verifikasiediens, anders sal die beperking aanmeldvloei breek wat niemand gedink het om te toets nie. Skryf die reël teen die koppelvlak wat werklik filter, nie teen die koppelvlak wat toevallig in die redigeerder oop is nie.

Hou ook rekening met adresvertaling. As ’n stroomaf firewall een vertaalde bronadres vir elke tonnelgebruiker sien, kan dit nie individue bloot uit daardie adres onderskei nie, en ’n reël wat geskryf is asof dit kon, sal óf nutteloos óf te breed wees.

Kliëntprofiele woon aan die onbetroubare kant

’n Bestuurde VPN-profiel kan roetes, splits-tonnelreëls of toepassingsfilters stoot, en dié bepaal hoe ’n welgemanierde toestel optree. Hulle is nie beskerming vir die diens nie, want die kliënt is die party wat jy probeer beperk. Om ’n roete in ’n profiel te verwyder is ook nie magtiging nie, aangesien ’n kliënt ’n ander pad na dieselfde bestemming kan hê.

Behandel kliëntinstellings as gerief en gateway-instellings as beheer. Wanneer die twee verskil, is die gateway reg, want dit is die een wat die pakkette sien.

Aanvaar met twee rekeninge en volg dan in volgorde

Skep twee gewone toetsrekeninge met verskillende beoogde toestemmings, vestig nuwe sessies en kontroleer die effektiewe gateway-beleid vir elkeen. Toets dan een skadelose toegelate handeling en een spesifiek geweierde hulpbron. ’n Mislukte ping bewys baie min op sigself, want ICMP kan gefiltreer word terwyl die TCP-diens daaragter gewillig antwoord.

Wanneer albei rekeninge steeds breë toegang kry, volg in ’n vaste volgorde: watter beleid gepas het, watter magtiging die antwoord gedra het, en wat die gateway daarmee gedoen het. Om meer NPS-kenmerke by te voeg voordat jy bevestig dat die ontvanger hulle implementeer, is hoe ’n klein magtigingsprobleem ’n veranderingsvenster sonder resultaat word.