La política de grup NPS no és aplicació de recursos VPN

Dos grups, dos perfils d’accés, un gateway VPN i, al final, tots dos grups arriben als mateixos servidors. El motiu habitual no és una política trencada sinó una segona meitat absent del disseny: NPS decideix qui pot establir una sessió, i una altra cosa ha de decidir a què pot arribar aquesta sessió. Quan només existeix la primera meitat, l’autorització té èxit per a tots els qui s’autentiquen. La política fa la seva feina i el disseny encara és incomplet.

Una política de xarxa que coincideix amb un grup és una prova sobre l’admissió. No és una prova sobre els paquets, i el buit entre aquestes dues afirmacions és on passa la major part d’aquesta feina.

Trobeu la política que realment va admetre la sessió

NPS avalua polítiques de xarxa ordenades i guanya la primera regla habilitada les condicions de la qual coincideixen. Les condicions poden incloure la pertinença a un grup d’usuaris o d’ordinadors, el tipus de connexió, l’hora i l’estat del dispositiu. Per tant, una política àmplia situada abans a la llista admet una connexió abans que una regla més estreta de més avall arribi a considerar-se. L’ordre no és un detall de la interfície; l’ordre és la política.

Llegiu la llista en ordre i identifiqueu la que va coincidir, i després anoteu quins paràmetres va retornar. El nom del grup a l’editor no és el resultat; el resultat és l’autorització que va rebre el servidor. Mantingueu separades l’autorització d’usuari i la del dispositiu quan el desplegament fa servir totes dues, perquè un compte que pot obrir un túnel no és automàticament un compte que hauria d’arribar a cada servei intern.

La resposta RADIUS és una instrucció, no un filtre

L’atribut Filter-Id porta el nom d’una llista de filtres. No envia un conjunt portàtil de regles de filtratge de paquets que tots els receptors entenguin, i enviar un nom que el gateway no ha definit mai no aplica absolutament res. La mateixa precaució val per als atributs VLAN: assignar una sessió de túnel a una VLAN no és, per si sol, una regla d’accés encaminada per a aquest usuari.

Aquí és on un disseny que sembla complet a la banda de NPS no fa res en silenci. Confirmeu amb la documentació del proveïdor del gateway quins atributs d’autorització s’admeten i què fa el receptor amb cadascun, en lloc de suposar que un nom d’atribut estàndard implica un comportament estàndard.

Poseu l’aplicació on passa el trànsit

Un gateway que processa els paquets de l’usuari pot aplicar un filtre per sessió, assignar un grup a una política del gateway o donar a la sessió una adreça d’un conjunt segregat que el tallafoc tracta de manera diferent. Qualsevol d’aquestes opcions pot funcionar, i fallen de maneres diferents. Identifiqueu quin mecanisme admet el vostre gateway abans d’escriure la política que el nomena. Després anoteu què passa amb una sessió quan aquest mecanisme no hi és, perquè el silenci és el valor per defecte.

Descriviu el permís previst en quatre parts: identitat d’origen o grup, destinació, protocol i port. Afegiu les dependències que l’usuari necessita de veritat, com ara DNS o un servei d’autenticació, o la restricció trencarà fluxos d’inici de sessió que ningú no va pensar a provar. Escriviu la regla contra la interfície que realment filtra, no contra la interfície que casualment està oberta a l’editor.

Tingueu en compte també la traducció d’adreces. Si un tallafoc posterior veu una sola adreça d’origen traduïda per a cada usuari del túnel, no pot distingir individus només amb aquesta adreça, i una regla escrita com si pogués serà inútil o massa àmplia.

Els perfils de client viuen a la banda no confiable

Un perfil VPN gestionat pot empènyer rutes, regles de túnel dividit o filtres d’aplicacions, i aquests donen forma al comportament d’un dispositiu ben educat. No són protecció per al servei, perquè el client és la part que intenteu restringir. Treure una ruta d’un perfil tampoc no és autorització, ja que un client pot tenir un altre camí cap a la mateixa destinació.

Tracteu la configuració del client com a comoditat i la del gateway com a control. Quan les dues discrepen, el gateway té raó perquè és qui veu els paquets.

Accepteu amb dos comptes i després seguiu l’ordre

Creeu dos comptes de prova corrents amb permisos previstos diferents, establiu sessions noves i comproveu la política efectiva del gateway per a cadascun. Després proveu una operació permesa innòcua i un recurs denegat específicament. Un ping fallit demostra molt poc per si sol, ja que ICMP pot estar filtrat mentre el servei TCP al darrere respon tranquil·lament.

Quan tots dos comptes encara obtenen accés ampli, seguiu un ordre fix: quina política va coincidir, quina autorització portava la resposta i què va fer el gateway amb ella. Afegir més atributs NPS abans de confirmar que el receptor els implementa és com un petit problema d’autorització es converteix en una finestra de canvi sense resultat.