Како пријава на VPN стиже до RADIUS-а и вашег добављача идентитета

Прошле недеље корисник је могао да се пријави на VPN и ипак заврши на мрежи где се ништа није решавало. Клијент је рекао повезан, дневник пролаза је рекао Access-Accept, а тим за идентитет је рекао да је налог у реду. Пријава је успела; ауторизација иза ње није. Када пријава на VPN не успе, идем путем којим захтев заиста пролази — клијент, пролаз, RADIUS сервер, добављач идентитета — и заустављам се на првом кораку чији се одговор не слаже са следећим.

Клијент никада не говори RADIUS

Шта год приказивала апликација на преносном рачунару, њен први корак је VPN протокол: IKEv2, OpenVPN, WireGuard или клијент заснован на TLS-у. RADIUS се не појављује у тој размени. Клијент се аутентификује код пролаза сертификатом, корисничким именом и лозинком или EAP методом која се преноси у подешавању тунела.

То је важно када читате дневнике, јер општу грешку аутентификације коју корисник види ствара пролаз пошто је већ разговарао са нечим другим. Ако клијент никада не стигне до пролаза, нема RADIUS захтева за отклањање грешака и сат проведен на RADIUS серверу је изгубљен. Потврдите да се тунел уопште подигао пре него што дотакнете backend.

Пролаз је 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-до-директоријум: истекао bind налог, недоступан директоријум или захтев упућен на погрешан backend. Ако корисничко име носи суфикс домена, сервер може да рутира по њему, и исти налог послат као CORP\alice и [email protected] може да заврши на различитим местима. У Windows NPS-у Security дневник бележи 6272 за дозволу и 6273 за одбијање, што вам каже да ли је одлука уопште дошла од NPS-а.

Читајте неуспех на кораку који га је створио

Једна порука о немогућности повезивања покрива четири различита неуспеха. Пре него што било шта промените, ускладите симптом са кораком који га је створио.

Последњи ред је онај који шаље људе погрешном тиму. Access-Accept значи да су акредитиви прихваћени; то не значи да је пролаз сместио корисника у прави базен или гурнуо руте. Атрибути групе су важни само ако их политика пролаза чита. Видео сам тачну пријаву да заврши у гостећем базену зато што је мапирање група на страни RADIUS-а било подешено за други атрибут од оног који пролаз проверава.

Пратите једну пријаву од почетка до краја

Изаберите један тест налог и један пролаз, па посматрајте исти покушај на све четири тачке. Покрените отклањање грешака на страни RADIUS-а — freeradius -X исписује захтев и сваки модул који дотакне — пратите дневник аутентификације пролаза и покрените tcpdump за UDP размену. Повежите се једном и прочитајте четири трага по реду.

Оно што желите да видите је сагласност: пролаз је питао о кориснику којег сте очекивали, RADIUS сервер је изабрао backend који сте очекивали, тај backend је вратио одлуку, а атрибути у одговору одговарају политици коју пролаз примењује. Прво место где се трагови не слажу је ваша линија квара. Ако одговор не носи атрибут групе, проблем је на страни RADIUS-а, не у VPN профилу; ако атрибут постоји и пролаз га игнорише, проблем је политика пролаза.

Једна безбедносна напомена док сте тамо. Заједничка тајна штити размену, али не шифрује већину атрибута. Ако су пролаз и RADIUS сервер на различитим сегментима, ставите тај корак на RADIUS преко TLS-а или приватног пута. Шифровани кориснички тунел не говори ништа о вези са backend-ом.

Пре него што затворите тикет, потврдите четири ствари. Пролаз може да стигне до RADIUS сервера на порту за који је заиста конфигурисан. Заједничка тајна се поклапа на обе стране. RADIUS сервер разрешава тачан облик корисничког имена који пролаз шаље. Прихватање носи атрибуте који су потребни политици пролаза. Када сва четири важе, пријава која и даље не успева је проблем политике пролаза, не аутентификације.