Skupinska politika NPS ni uveljavljanje virov VPN

Dve skupini, dva profila dostopa, en prehod VPN in na koncu obe skupini dosežeta iste strežnike. Običajni razlog ni pokvarjena politika, ampak manjkajoča druga polovica zasnove: NPS odloči, kdo sme vzpostaviti sejo, in nekaj drugega mora odločiti, kam ta seja sme doseči. Ko obstaja le prva polovica, avtorizacija uspe vsakomur, ki se avtenticira. Politika opravlja svoje delo, zasnova pa je še vedno nepopolna.

Omrežna politika, ki se ujema s skupino, je dokaz o sprejemu. Ni dokaz o paketih, in vrzel med tema dvema trditvama je kraj, kjer se zgodi večina tega dela.

Poiščite politiko, ki je sejo dejansko sprejela

NPS vrednoti urejene omrežne politike in zmaga prvo omogočeno pravilo, katerega pogoji se ujemajo. Pogoji lahko vključujejo članstvo v skupini uporabnika ali računalnika, vrsto povezave, čas in stanje naprave. Zato široka politika, nameščena višje na seznamu, sprejme povezavo, preden je ožje pravilo nižje sploh obravnavano. Vrstni red ni podrobnost vmesnika; vrstni red je politika.

Preberite seznam po vrsti in prepoznajte tisto, ki se je ujemalo, nato zabeležite, katere nastavitve je vrnilo. Ime skupine v urejevalniku ni rezultat; rezultat je avtorizacija, ki jo je prejel strežnik. Ohranite avtorizacijo uporabnika in avtorizacijo naprave ločeno tam, kjer uvajanje uporablja obe, ker račun, ki sme odpreti tunel, ni samodejno račun, ki bi moral doseči vsako notranjo storitev.

Odgovor RADIUS je navodilo, ne filter

Atribut Filter-Id nosi ime seznama filtrov. Ne prinaša prenosnega nabora pravil za filtriranje paketov, ki bi ga razumel vsak prejemnik, in pošiljanje imena, ki ga prehod nikoli ni določil, ne uveljavi prav ničesar. Enaka previdnost velja za atribute VLAN: dodelitev tunelske seje omrežju VLAN sama po sebi ni usmerjeno pravilo dostopa za tega uporabnika.

Tu zasnova, ki je na strani NPS videti popolna, tiho ne naredi ničesar. V dokumentaciji ponudnika prehoda preverite, kateri atributi avtorizacije so podprti in kaj prejemnik naredi z vsakim od njih, namesto da bi domnevali, da standardno ime atributa pomeni standardno vedenje.

Uveljavljanje postavite tja, kjer promet prehaja

Prehod, ki obdeluje uporabnikove pakete, lahko uporabi filter za vsako sejo, preslika skupino v politiko prehoda ali seji dodeli naslov iz ločenega nabora, ki ga požarni zid obravnava drugače. Vsaka od teh možnosti lahko deluje in vsaka odpove na svoj način. Ugotovite, kateri mehanizem podpira vaš prehod, preden napišete politiko, ki ga imenuje. Nato zapišite, kaj se zgodi s sejo, ko tega mehanizma ni, ker je tišina privzeto stanje.

Opišite predvideno dovoljenje v štirih delih: identiteta vira ali skupina, cilj, protokol in vrata. Dodajte odvisnosti, ki jih uporabnik res potrebuje, na primer DNS ali storitev avtentikacije, sicer bo omejitev zlomila tokove prijave, ki jih nihče ni pomislil preizkusiti. Pravilo pišite proti vmesniku, ki resnično filtrira, ne proti vmesniku, ki je slučajno odprt v urejevalniku.

Upoštevajte tudi prevajanje naslovov. Če požarni zid nižje vidi en preveden izvorni naslov za vsakega uporabnika tunela, ne more razlikovati posameznikov samo po tem naslovu, in pravilo, napisano, kot da bi lahko, bo bodisi neuporabno bodisi preširoko.

Odjemalski profili živijo na nezaupanja vredni strani

Upravljani profil VPN lahko potisne poti, pravila razdeljenega tunela ali filtre aplikacij, in ti oblikujejo, kako se vede dobro vzgojena naprava. Niso zaščita za storitev, ker je odjemalec tista stran, ki jo poskušate omejiti. Odstranitev poti v profilu prav tako ni avtorizacija, saj ima lahko odjemalec drugo pot do istega cilja.

Nastavitve odjemalca obravnavajte kot udobje, nastavitve prehoda pa kot nadzor. Ko se dve ne strinjata, ima prehod prav, ker je on tisti, ki vidi pakete.

Sprejmite z dvema računoma, nato sledite po vrsti

Ustvarite dva običajna preizkusna računa z različnimi predvidenimi dovoljenji, vzpostavite nove seje in preverite veljavno politiko prehoda za vsakega. Nato preizkusite eno neškodljivo dovoljeno operacijo in en posebej zavrnjen vir. Neuspešen ping sam po sebi dokaže zelo malo, ker je ICMP lahko filtriran, medtem ko storitev TCP za njim mirno odgovarja.

Ko oba računa še vedno dobita širok dostop, sledite v stalnem vrstnem redu: katera politika se je ujemala, kakšno avtorizacijo je nosil odgovor in kaj je prehod z njo storil. Dodajanje več atributov NPS pred potrditvijo, da jih prejemnik izvaja, je pot, po kateri majhna težava z avtorizacijo postane okno sprememb brez rezultata.