AWS Client VPN: уваход прайшоў, але падсетка недасяжная

Ваш кліент паказвае Connected, сертыфікат сапраўдны, а старонка інтранэта ўсё яшчэ сканчаецца тайм-аўтам. Гэтая розніца амаль ніколі не звязана з аўтэнтыфікацыяй. AWS Client VPN аўтарызуе прызначэнні асобна ад уваходу, і звычайна ёсць дзве прычыны: значэнне групы, якое не супадае з тым, што даслаў пастаўшчык ідэнтычнасці, і больш канкрэтнае правіла прызначэння, якое перамагае шырокае. Абодва бачныя ў канфігурацыі endpoint, калі ведаеш, куды глядзець.

Уваход прайшоў; правіла не супала

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

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

Адкуль насамрэч бярэцца значэнне групы

У Active Directory поле access-group змяшчае SID групы, а не яе адлюстраванае імя. Пры федэрацыі SAML яно змяшчае ID або імя групы, якое фактычна нясе наладжаны атрыбут групы SAML. Капіюйце значэнне з assertion або з запыту да каталога, а не са старонкі wiki.

Група IAM — гэта іншая плоскасць кіравання. Дазвол адміністраваць endpoint Client VPN не робіць групу IAM VPN-групай карыстальніка, і ўстаўка імені групы IAM у поле access-group не ператварае яго ў SID AD або значэнне атрыбута SAML.

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

Перамагае самы доўгі прэфікс, уключаючы 0.0.0.0/0

Аўтарызацыя ацэньваецца па найдоўгім супадзенні прэфікса, і правіла для ўсіх прызначэнняў ацэньваецца апошнім, а не першым. Дадайце правіла 10.46.0.0/16 для Engineering і правіла 0.0.0.0/0 для ўсіх, і карыстальнік па-за Engineering усё роўна не зможа дасягнуць 10.46.20.10 праз шырокае правіла.

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

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

Аддзяліце аўтарызацыю ад шляху даных

Правіла, якое супадае, — гэта не маршрут. Endpoint патрабуе звязаную падсетку і запіс у табліцы маршрутызацыі для прызначэння, а група бяспекі мэтавага рэсурсу павінна прымаць трафік. Зваротны трафік і DNS таксама павінны працаваць.

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

Калі IP-адрас працуе, а імя хоста не, паглядзіце на resolver, перш чым чапаць аўтарызацыю. Калі ніякі маршрут не пакрывае адрас, выпраўце асацыяцыю або табліцу маршрутызацыі. Калі пакет прыходзіць, а сэрвіс адхіляе яго, наступны крок — палітыка гэтага сэрвісу. Пашырэнне матрыцы аўтарызацыі на ўсіх карыстальнікаў хавае, які менавіта пласт быў сапраўды зламаны.

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