Як уваход у VPN дасягае RADIUS і вашага пастаўшчыка ідэнтычнасці
Прайдзіце ўваход у VPN ад кліента да запыту RADIUS ад шлюза, пастаўшчыка ідэнтычнасці за ім і палітыкі, якая ўжываецца пасля accept.
На мінулым тыдні карыстальнік змог увайсці ў VPN і ўсё ж трапіў у сетку, дзе нічога не развязвалася. Кліент паведаміў, што злучаны, журнал шлюза паказаў Access-Accept, а каманда ідэнтычнасці сказала, што ўліковы запіс у парадку. Уваход спрацаваў; аўтарызацыя за ім — не. Калі ўваход у VPN не ўдаецца, я іду шляхам, які запыт фактычна праходзіць — кліент, шлюз, сервер RADIUS, пастаўшчык ідэнтычнасці — і спыняюся на першым кроку, адказ якога разыходзіцца з наступным.
Кліент ніколі не гаворыць на RADIUS
Што б ні паказваў праграма на ноўтбуку, яе першы крок — пратакол VPN: IKEv2, OpenVPN, WireGuard або кліент на аснове TLS. RADIUS у гэтым абмене не з'яўляецца. Кліент аўтэнтыфікуецца на шлюзе сертыфікатам, імем карыстальніка і паролем або метадам EAP, які перадаецца ў наладзе тунэля.
Гэта важна, калі вы чытаеце журналы, бо агульную памылку аўтэнтыфікацыі, якую бачыць карыстальнік, стварае шлюз пасля таго, як ён ужо звяртаўся да чагосьці іншага. Калі кліент зусім не дасягае шлюза, запыту RADIUS для адладкі не існуе, і гадзіна, праведзеная на серверы RADIUS, марная. Пацвердзіце, што тунэль увогуле ўзняўся, перш чым чапаць бэкенд.
Шлюз — гэта кліент RADIUS
Як толькі налада тунэля даходзіць да моманту, калі трэба праверыць уліковыя даныя, шлюз становіцца серверам сеткавага доступу. Ён будуе Access-Request: User-Name, пароль або карысную нагрузку EAP, NAS-IP-Address або NAS-Identifier і Message-Authenticator, калі метад гэтага патрабуе. Запыт па змаўчанні ідзе на UDP 1812, а ўлік — на 1813. Старыя разгортванні ўсё яшчэ выкарыстоўваюць 1645 і 1646, таму правіла міжсеткавага экрана, напісанае для адной пары, тлумачыць шмат ціхіх збояў.
Абодва бакі падзяляюць сакрэт, і гэта не ўліковыя даныя карыстальніка. Ён падпісвае абмен, і кожны адказ правяраецца супраць яго. Наладзьце сакрэт па-рознаму на двух баках — і сервер не адкажа дрэнным сакрэтам: ён скідвае запыт або адказ не праходзіць праверку, таму шлюз паведамляе пра тайм-аўт. Няправільны сакрэт і мёртвы сервер выглядаюць з шлюза аднолькава, таму я правяраю гэты крок кліенцкім інструментам, перш чым вінаваціць каталог.
Пратакол малы і стары — RFC 2865 вызначае абмен аўтэнтыфікацыі — але атрыбуты, якія ён нясе, — гэта тое, на чым будуецца большасць палітык VPN.
# ask the RADIUS server directly, from the gateway host
radtest alice 'test-password' 127.0.0.1 0 testing123
# watch the exchange the gateway actually sends
tcpdump -ni any -c 20 'udp port 1812'Сервер RADIUS можа стаяць толькі перад пастаўшчыком ідэнтычнасці
Людзі кажуць пра RADIUS і пастаўшчыка ідэнтычнасці, як быццам гэта адзін і той жа скрыня. Часта гэта не так. Сервер RADIUS атрымлівае Access-Request і затым пытаецца ў чагосьці іншага — Active Directory праз LDAP або Kerberos, лакальны файл карыстальнікаў або знешні сэрвіс — перш чым адказаць. FreeRADIUS з модулем LDAP або krb5, Windows NPS і Cisco ISE усе стаяць на гэтай пазіцыі.
Гэта розніца вырашае, куды глядзець. Адхілены пароль — гэта адказ пастаўшчыка ідэнтычнасці, перададзены RADIUS. Тайм-аўт звычайна азначае ўчастак ад RADIUS да каталога: пратэрмінаваны ўліковы запіс прывязкі, недаступны каталог або запыт, накіраваны на няправільны бэкенд. Калі імя карыстальніка мае суфікс дамена, сервер можа маршрутызаваць па ім, і той жа ўліковы запіс, адпраўлены як CORP\alice і [email protected], можа трапіць у розныя месцы. У Windows NPS журнал Security запісвае 6272 для дазволу і 6273 для адмовы, што паказвае, ці прыйшло рашэнне наогул ад NPS.
Чытайце збой на тым кроку, які яго стварыў
Адно паведамленне пра немагчымасць злучыцца ахоплівае чатыры розныя збоі. Перш чым нешта змяняць, суаднясіце сімптом з крокам, які яго стварыў.
| What you see | Where it comes from | First check |
|---|---|---|
| Gateway timeout, no reply | Shared secret mismatch, UDP 1812 blocked, unknown NAS, wrong server address | tcpdump at the gateway; radtest from the gateway host |
| Immediate reject | Credentials, account state, domain suffix, RADIUS policy | NPS 6273 or the FreeRADIUS auth log; test the account directly |
| Repeated challenge or MFA loop | Access-Challenge state not returned, or a token that expired mid-flow | Client prompt timing and the State attribute in debug output |
| Accept, then no access | Authorization attributes unmapped, wrong pool, route or ACL policy | Gateway policy and the attributes in the Access-Accept |
Менавіта апошні радок адпраўляе людзей да не той каманды. Access-Accept азначае, што ўліковыя даныя прыняты; гэта не азначае, што шлюз змясціў карыстальніка ў правільны пул або прасунуў маршруты. Атрыбуты групы маюць значэнне, толькі калі палітыка шлюза іх чытае. Я бачыў, як правільны ўваход трапляў у гасцявы пул, бо адлюстраванне груп было наладжана на баку RADIUS для іншага атрыбута, чым той, які правярае шлюз.
Прасачыце адзін уваход ад пачатку да канца
Вазьміце адзін тэставы ўліковы запіс і адзін шлюз, затым назірайце за адной і той жа спробай у чатырох кропках. Запусціце адладку на баку RADIUS — freeradius -X друкуе запыт і кожны модуль, якога ён тыкаецца — сочыце за журналам аўтэнтыфікацыі шлюза і запусціце tcpdump для абмену UDP. Злучыцеся адзін раз і прачытайце чатыры трасы па парадку.
Вы хочаце ўбачыць згоду: шлюз запытаў пра карыстальніка, якога вы чакалі, сервер RADIUS выбраў бэкенд, які вы чакалі, гэты бэкенд вярнуў рашэнне, а атрыбуты ў адказе адпавядаюць палітыцы, якую ўжывае шлюз. Першае месца, дзе трасы разыходзяцца, — гэта ваша лінія разлому. Калі адказ не нясе атрыбута групы, праблема на баку RADIUS, а не ў профілі VPN; калі атрыбут ёсць, а шлюз яго ігнаруе, праблема ў палітыцы шлюза.
Адна заўвага па бяспецы, пакуль вы там. Агульны сакрэт абараняе абмен, але ён не шыфруе большасць атрыбутаў. Калі шлюз і сервер RADIUS знаходзяцца ў розных сегментах, змясціце гэты крок на RADIUS праз TLS або прыватны шлях. Зашыфраваны карыстальніцкі тунэль нічога не кажа пра сувязь з бэкендам.
Перш чым закрыць тыкет, пацвердзіце чатыры рэчы. Шлюз можа дасягнуць сервера RADIUS на порце, для якога ён фактычна наладжаны. Агульны сакрэт супадае на абодвух баках. Сервер RADIUS развязвае дакладную форму імя карыстальніка, якую шле шлюз. Accept нясе атрыбуты, якія патрабуе палітыка шлюза. Калі ўсе чатыры выконваюцца, уваход, які ўсё яшчэ не ўдаецца, — гэта праблема палітыкі шлюза, а не аўтэнтыфікацыі.