Как влизането във VPN достига до RADIUS и вашия доставчик на идентичност

Миналата седмица потребител успя да влезе във 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.

Четете отказа на стъпката, която го е създала

Едно съобщение за невъзможност за свързване покрива четири различни отказа. Преди да промените нещо, съпоставете симптома със стъпката, която го е създала.

Последният ред е този, който изпраща хората при грешния екип. Access-Accept означава, че идентификационните данни са приети; не означава, че шлюзът е поставил потребителя в правилния пул или е изпратил маршрути. Атрибутите на групата имат значение само ако политиката на шлюза ги чете. Виждал съм правилно влизане да попада в гост пул, защото съпоставянето на групи е било настроено от страна на RADIUS за различен атрибут от този, който шлюзът проверява.

Проследете едно влизане от началото до края

Изберете един тестов акаунт и един шлюз, след което наблюдавайте един и същ опит в четирите точки. Стартирайте дебъг от страна на RADIUS — freeradius -X отпечатва заявката и всеки модул, до който се докосне — следете журнала за автентикация на шлюза и пуснете tcpdump за UDP размяната. Свържете се веднъж и прочетете четирите следи по ред.

Това, което искате да видите, е съгласие: шлюзът е попитал за потребителя, когото сте очаквали, RADIUS сървърът е избрал бекенда, който сте очаквали, този бекенд е върнал решение и атрибутите в отговора съответстват на политиката, която шлюзът прилага. Първото място, където следите се разминават, е вашата линия на отказа. Ако отговорът не носи атрибут за група, проблемът е от страна на RADIUS, а не във VPN профила; ако атрибутът е там и шлюзът го игнорира, проблемът е в политиката на шлюза.

Една бележка за сигурността, докато сте там. Споделената тайна защитава размяната, но не криптира повечето атрибути. Ако шлюзът и RADIUS сървърът са в различни сегменти, поставете тази отсечка на RADIUS през TLS или частен път. Криптираният потребителски тунел не казва нищо за връзката към бекенда.

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