Даданне карыстальніка ў групу VPN само па сабе не дае доступу
Членства ў групе — умова, а не дазвол. Паглядзіце, што менавіта супаставіў шлюз, прачытайце запіс пра прыём ці адмову і праверце абодва вынікі.
Вы змясцілі ўліковы запіс у патрэбную групу, уваход прайшоў, а злучэнне ўсё яшчэ адхіляецца або ўстанаўліваецца і не дасягае нічога карыснага. Звычайная рэакцыя — дадаваць карыстальніка ў новыя групы, пакуль нешта не зменіцца, і менавіта так арганізацыі выдаюць нашмат больш правоў, чым патрабавала заяўка. Членства ў групе — адзін уваход у рашэнне аб аўтарызацыі, але ніколі само рашэнне: шлюз збірае некалькі фактаў пра сесію, супастаўляе іх з упарадкаванай палітыкай і толькі потым вырашае, да чаго сесія мае доступ. Калі не выканалася іншая ўмова, змена групы не змяняе нічога, акрамя вашай экспазіцыі.
Членства ў групе — умова, а не дазвол
У RADIUS група прыходзіць як атрыбут аўтарызацыі, а атрыбуты апісваюць сесію, а не дазваляюць яе. Сервер адказвае Access-Accept або Access-Reject; пры прыёме ён можа далучыць Filter-Id, Class або тунельныя атрыбуты з RFC 2868, і сеткавае абсталяванне на іншым канцы тлумачыць іх так, як вырашыў вытворца. Нішто ў пратаколе не ператварае групу ў поўны доступ; гэтае супастаўленне піша той, хто наладзіў палітыку на шлюзе або серверы сеткавага доступу, і яно можа быць вузкім як адзін хост.
Таму аднолькавая назва групы паводзіць сябе па-рознаму ў дзвюх сістэмах. Microsoft NPS збірае сеткавыя палітыкі з умоў, абмежаванняў і наладжванняў і ацэньвае іх у зададзеным парадку. OpenVPN Access Server мае ўласную мадэль груп і правілаў доступу, а супольны сервер OpenVPN часта перадае ўсё пытанне скрыпту client-connect або файлу client-config-dir. Кожны спажывае групу; ні адзін не падзяляе лагіку прыярытэту іншага.
Вырашае правіла, якое супала, а не група, якую вы чакалі
Большасць рухавікоў спыняецца на першай палітыцы, што супала, або на самай канкрэтнай. Калі палітыка 3 адхіляе, а палітыка 7 дазваляе, сесія можа праваліцца, так і не дасягнуўшы правіла, якое б яе прапусціла. Парадак — рэальная наладка ў NPS і большасці прадуктаў кантролю сеткавага доступу, і ён зрушваецца з гадамі.
Умовы, што ідуць разам з групай, — другая палова. Стан прылады, метад аўтэнтыфікацыі, завяршэнне MFA, зыходная сетка, суб’ект сертыфіката або часавае акно могуць быць у той самай палітыцы. Калі адна з іх не выканана, палітыка не супадае, рухавік ідзе далей, і дзейнічае адмова па змаўчанні. З боку карыстальніка гэта выглядае як ігнараванне групы; з боку рухавіка група наогул не разглядалася.
Дэталі каталога ствараюць тую ж ілюзію. Палітыка, што супастаўляе членства ў групах Windows, чытае SID у токене карыстальніка, а там пералічаны толькі групы бяспекі — група размеркавання ніколі не з’яўляецца. Асноўная група карыстальніка захоўваецца ў асобным полі, а не ў пераліку, таму палітыка, прывязаная да яе, можа моўчкі не спрацаваць.
Прачытайце запіс пра прыём або адмову, перш чым чапаць групу
Спачатку адно пытанне: ці дайшоў запыт да стадыі аўтарызацыі? У NPS адказ ужо ў журнале падзей, дзе 6272 фіксуе дазвол, 6273 — адмову, а 6274 — запыт, адкінуты серверам да ацэнкі палітыкі. Гэтыя тры нумары дзеляць праблему на тры розныя расследаванні, і толькі адно з іх пра групы.
| What the record shows | What it means | Where to look next |
|---|---|---|
| 6272, access granted | Authentication and authorization both succeeded | Routes, split tunnel, DNS, per-resource rules |
| 6273, access denied | A policy matched and denied, or nothing matched and the default denied | The conditions of the policy that fired, in order |
| 6274, request discarded | The request never reached authorization | Shared secret, NAS client entry, proxy chain, malformed attributes |
Калі журнал недаступны, спытайце сервер напрамую і прачытайце адказ. Адказ без Filter-Id і без тунельных атрыбутаў кажа, што сервер лічыць сесію звычайнай, а шлюз прымяняе ўласныя правілы. Адказ з атрыбутамі, якіх пункт прымянення не рэалізуе, — іншая няспраўнасць: аўтарызацыя прайшла, а прылада праігнаравала вынік.
radtest alice 'password' 10.0.0.5 0 testing123Параўнайце вернутыя атрыбуты з тымі, што дакументуе шлюз, а не з тым, што мяркуе назва групы. Гэтае параўнанне звычайна аддзяляе праблему палітыкі ад праблемы прымянення.
Змена групы не дзейнічае рэтраактыўна
Атрыбуты аўтарызацыі вяртаюцца адзін раз, пры аўтэнтыфікацыі сесіі. Шлюз захоўвае іх у сесіі і не перачытвае каталог на кожны пакет, таму ўсталяваная сесія працягвае працаваць пасля выдалення карыстальніка з групы, а новая можа не прайсці, пакуль старая яшчэ жыве.
Каб змена ўступіла ў сілу, патрэбна новае рашэнне аб аўтарызацыі, а не проста новыя ключы. Калі сервер падтрымлівае дынамічную аўтарызацыю RFC 5176, Disconnect-Request або CoA-Request на UDP 3799 прымушае сесію да пераацэнкі; інакш адключыце кліента і дайце яму перападключыцца. Перамоўнасць абнаўляе ключы тунеля і звычайна не чапае вынік аўтарызацыі.
Выпраўляйце ўмову, а не групу
Калі вядома, якая палітыка спрацавала, выпраўленне звычайна малое: пераўпарадкуйце адмову, што засланяе патрэбны дазвол, дадайце адсутную ўмову прылады або MFA ў палітыку, якую мелі на ўвазе, або напішыце вузкае правіла для аднаго рэсурсу замест таго, каб падвышаць карыстальніка ў групу з дзесяццю іншымі.
Кароткі цыкл трымае змену сумленнай:
- Узнавіце адмову з першапачатковым уліковым запісам і запішыце ID падзеі, перш чым нешта змяняць.
- Змяніце адзін аб’ект — парадак палітык, адну ўмову або адну групу — і запішыце, які менавіта.
- Адкрыйце новую сесію, пераканайцеся, што дазвол з’явіўся ў журнале, і што рэсурс сапраўды адкрываецца.
- Праверце карыстальніка, якому яшчэ трэба адмаўляць, каб выпраўленне не пашырыла палітыку выпадкова.
Калі дазвол правільны, а рэсурс не адкрываецца, праблема перайшла да маршрутызацыі або развязання імён у момант поспеху аўтарызацыі. Трымайце гэтыя дзве няўдачы асобна, і наступная заяўка зойме хвіліны, а не паўдня.