Груповата политика на NPS не е налагане на VPN ресурси

Две групи, два профила за достъп, един VPN шлюз и накрая и двете групи достигат до същите сървъри. Обичайната причина не е счупена политика, а липсваща втора половина от дизайна: NPS решава кой може да установи сесия, а нещо друго трябва да реши до какво тази сесия може да достига. Когато съществува само първата половина, разрешението успява за всеки, който се удостовери. Политиката си върши работата, а дизайнът все още е непълен.

Мрежова политика, съпоставена с група, е доказателство за допускане. Тя не е доказателство за пакети и разликата между тези две твърдения е мястото, където се случва по-голямата част от тази работа.

Намерете политиката, която действително е допуснала сесията

NPS оценява подредени мрежови политики и първото включено правило, чиито условия съвпадат, печели. Условията могат да включват членство в група на потребител или компютър, тип на връзката, време и състояние на устройството. Затова широка политика, поставена по-рано в списъка, допуска връзка, преди по-тясно правило по-надолу изобщо да бъде разгледано. Редът не е подробност от интерфейса; той е самата политика.

Прочетете списъка по ред и определете кое е съвпаднало, после отбележете какви настройки е върнало. Името на групата в редактора не е резултатът; резултатът е разрешението, което сървърът е получил. Дръжте разрешението на потребителя и разрешението на устройството отделно там, където внедряването използва и двете, защото акаунт, който може да отвори тунел, не е автоматично акаунт, който трябва да достига до всяка вътрешна услуга.

Отговорът на RADIUS е инструкция, а не филтър

Атрибутът Filter-Id носи името на списък с филтри. Той не пренася преносим набор от правила за филтриране на пакети, които всеки получател разбира, а изпращането на име, което шлюзът никога не е дефинирал, не налага нищо изобщо. Същото внимание важи и за атрибутите на VLAN: задаването на тунелна сесия към VLAN само по себе си не е маршрутизирано правило за достъп за този потребител.

Тук дизайн, който изглежда завършен от страната на NPS, тихо не прави нищо. Потвърдете от документацията на доставчика на шлюза кои атрибути за разрешение се поддържат и какво прави получателят с всеки от тях, вместо да предполагате, че стандартно име на атрибут означава стандартно поведение.

Поставете налагането там, където минава трафикът

Шлюз, който обработва пакетите на потребителя, може да приложи филтър за всяка сесия, да съпостави група с политика на шлюза или да даде на сесията адрес от изолиран пул, който защитната стена третира различно. Всеки от тези варианти може да работи и всеки се проваля по различен начин. Определете кой механизъм поддържа вашият шлюз, преди да напишете политиката, която го назовава. После запишете какво се случва със сесията, когато този механизъм липсва, защото тишината е поведението по подразбиране.

Опишете предвиденото разрешение в четири части: идентичност на източника или група, дестинация, протокол и порт. Добавете зависимостите, от които потребителят наистина се нуждае, например DNS или услуга за удостоверяване, иначе ограничението ще счупи потоци за вход, за които никой не се е сетил да тества. Пишете правилото срещу интерфейса, който действително филтрира, а не срещу интерфейса, който случайно е отворен в редактора.

Отчетете и транслацията. Ако по-надолу защитна стена вижда един транслатиран адрес на източника за всички потребители на тунела, тя не може да различи отделните хора само по този адрес, а правило, написано сякаш може, ще бъде или безполезно, или прекалено широко.

Профилите на клиента живеят от недоверената страна

Управляван профил на VPN може да изпрати маршрути, правила за разделен тунел или филтри за приложения и те оформят как се държи едно примерно устройство. Те не са защита за услугата, защото клиентът е страната, която се опитвате да ограничите. Премахването на маршрут в профил също не е разрешение, тъй като клиентът може да има друг път до същата дестинация.

Третирайте клиентските настройки като удобство, а настройките на шлюза като контрол. Когато двете се разминават, шлюзът е прав, защото той е този, който вижда пакетите.

Приемете с два акаунта, после проследете по ред

Създайте два обикновени тестови акаунта с различни предвидени разрешения, установете нови сесии и проверете действащата политика на шлюза за всеки. После тествайте една безвредна разрешена операция и един конкретно забранен ресурс. Неуспешен ping сам по себе си доказва много малко, тъй като ICMP може да е филтриран, докато TCP услугата зад него отговаря спокойно.

Когато и двата акаунта все още получават широк достъп, проследете в фиксиран ред: коя политика е съвпаднала, какво разрешение е носил отговорът и какво е направил шлюзът с него. Добавянето на още атрибути на NPS преди потвърждаване, че получателят ги реализира, е начинът, по който малък проблем с разрешенията се превръща в прозорец за промени без резултат.