Групавая палітыка NPS не з’яўляецца абмежаваннем рэсурсаў VPN

Дзве групы, два профілі доступу, адзін шлюз VPN, і абедзве групы ў выніку дасягаюць адных і тых жа сервераў. Звычайная прычына — не зламаная палітыка, а адсутная другая палова дызайну: NPS вырашае, хто можа ўсталяваць сесію, а нешта іншае павінна вырашаць, да чаго гэтая сесія можа дасягаць. Калі існуе толькі першая палова, аўтарызацыя паспяхова праходзіць для ўсіх, хто аўтэнтыфікуецца. Палітыка выконвае сваю працу, а дызайн усё яшчэ няпоўны.

Сеткавая палітыка, супастаўленая з групай, — гэта доказ пра допуск. Гэта не доказ пра пакеты, і прамежак паміж гэтымі двума сцверджаннямі — менавіта там адбываецца большая частка гэтай працы.

Знайдзіце палітыку, якая сапраўды дапусціла сесію

NPS ацэньвае ўпарадкаваныя сеткавыя палітыкі, і першае ўключанае правіла, умовы якога супадаюць, перамагае. Умовы могуць уключаць членства ў групе карыстальніка або камп’ютара, тып злучэння, час і стан прылады. Таму шырокая палітыка, змешчаная раней у спісе, дапускае злучэнне да таго, як больш вузкае правіла ніжэй наогул будзе разгледжана. Парадак — не дэталь інтэрфейсу; гэта і ёсць палітыка.

Прачытайце спіс па парадку і вызначце тое, што супала, затым адзначце, якія налады яно вярнула. Назва групы ў рэдактары — не вынік; вынік — гэта аўтарызацыя, якую атрымаў сервер. Трымайце аўтарызацыю карыстальніка і аўтарызацыю прылады асобна там, дзе разгортванне выкарыстоўвае абедзве, бо ўліковы запіс, які можа адкрыць тунель, не аўтаматычна ўліковы запіс, які павінен дасягаць кожнай унутранай службы.

Адказ RADIUS — гэта інструкцыя, а не фільтр

Атрыбут Filter-Id нясе назву спісу фільтраў. Ён не перадае пераносны набор правілаў фільтрацыі пакетаў, які разумее кожны атрымальнік, а адпраўка назвы, якую шлюз ніколі не вызначаў, не прымяняе нічога наогул. Тая ж асцярожнасць датычыцца атрыбутаў VLAN: прызначэнне сесіі тунеля пэўнаму VLAN само па сабе не з’яўляецца маршрутызаваным правілам доступу для гэтага карыстальніка.

Менавіта тут дызайн, які выглядае поўным на баку NPS, ціха нічога не робіць. Пацвердзіце па дакументацыі пастаўшчыка шлюза, якія атрыбуты аўтарызацыі падтрымліваюцца і што атрымальнік робіць з кожным, замест таго каб меркаваць, што стандартная назва атрыбута азначае стандартныя паводзіны.

Размясціце прымяненне там, дзе праходзіць трафік

Шлюз, які апрацоўвае пакеты карыстальніка, можа прымяніць фільтр для кожнай сесіі, супаставіць групу з палітыкай шлюза або выдаць сесіі адрас з адасобленага пула, які брандмаўэр апрацоўвае інакш. Любы з гэтых варыянтаў можа працаваць, і яны адмаўляюць па-рознаму. Вызначце, які механізм падтрымлівае ваш шлюз, перш чым пісаць палітыку, што яго называе. Затым запішыце, што адбываецца з сесіяй, калі гэтага механізму няма, бо маўчанне — гэта прадвызначаны стан.

Апішыце меркаваны дазвол у чатырох частках: ідэнтычнасць крыніцы або група, пункт прызначэння, пратакол і порт. Дадайце залежнасці, якія карыстальнік сапраўды мае патрэбу, напрыклад DNS або службу аўтэнтыфікацыі, інакш абмежаванне зламае сцэнарыі ўваходу, якія ніхто не здагадаўся пратэставаць. Пішыце правіла супраць інтэрфейсу, які сапраўды фільтруе, а не супраць інтэрфейсу, які выпадкова адкрыты ў рэдактары.

Улічыце таксама трансляцыю. Калі ніжэйшы брандмаўэр бачыць адзін трансляваны адрас крыніцы для ўсіх карыстальнікаў тунеля, ён не можа адрозніць асобных людзей толькі па гэтым адрасе, а правіла, напісанае так, нібы ён можа, будзе альбо бескарысным, альбо занадта шырокім.

Кліенцкія профілі жывуць на недавераным баку

Кіраваны профіль VPN можа прасоўваць маршруты, правілы раздзеленага тунеля або фільтры праграм, і яны фармуюць тое, як паводзіць сябе добрасумленная прылада. Яны не з’яўляюцца абаронай для службы, бо кліент — гэта бок, які вы спрабуеце абмежаваць. Выдаленне маршруту ў профілі таксама не аўтарызацыя, паколькі кліент можа мець іншы шлях да таго ж пункта прызначэння.

Разглядайце кліенцкія налады як зручнасць, а налады шлюза — як кантроль. Калі яны разыходзяцца, правы шлюз, бо менавіта ён бачыць пакеты.

Прыміце з двума ўліковымі запісамі, затым прасачыце па парадку

Стварыце два звычайныя тэставыя ўліковыя запісы з рознымі меркаванымі дазволамі, усталюйце свежыя сесіі і праверце дзейную палітыку шлюза для кожнага. Затым праверце адну бясшкодную дазволеную аперацыю і адзін канкрэтна забаронены рэсурс. Няўдалы ping сам па сабе даказвае вельмі мала, бо ICMP можа быць адфільтраваны, пакуль служба TCP за ім спакойна адказвае.

Калі абодва ўліковыя запісы ўсё яшчэ атрымліваюць шырокі доступ, прасачыце ў фіксаваным парадку: якая палітыка супала, якую аўтарызацыю нёс адказ і што шлюз з ёй зрабіў. Даданне новых атрыбутаў NPS перш за пацверджанне таго, што атрымальнік іх рэалізуе, — гэта шлях, якім дробная праблема аўтарызацыі ператвараецца ў акно змяненняў без выніку.