Како најавата на 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 серверот ја решава точната форма на корисничкото име што ја праќа портата. Прифаќањето ги носи атрибутите што и требаат на политиката на портата. Кога сите четири важат, најава што сѐ уште не успева е проблем на политиката на портата, не на автентикацијата.