Обхват за удостоверяване на VPN: кое пространство от имена на акаунти печели?
Обхватът насочва влизането към една система за идентичност, а не към държава. Задайте правилната форма на името, проследете заявката през проксито и запишете кой е отговорил.
Всяко влизане през VPN попада в някакво пространство от имена на акаунти и обхватът е селекторът, който решава кое. Той не казва нищо за държавата, местоположението на сървъра или нивото на доверие. Две еднакви потребителски имена могат да живеят в различни обхвати, затова правилна парола понякога удостоверява грешния акаунт. Това ръководство първо оправя формата на идентичността, после проследява заявката до системата, която действително е отговорила.
Какво избира обхватът
Шлюзът получава потребителско име и трябва да реши къде да го провери. Обхватът е частта от това име или атрибутът до него, който избира базата данни: директория, RADIUS пул, локален файл с акаунти. NPS на Microsoft нарича това име на обхват и насочва по него заявките за връзка, а мрежовият идентификатор за достъп EAP носи същата идея като наставка след знака @ в RFC 7542. И двете са селектори и нито едно не решава дали идентификационните данни са добри.
Това разделение поражда два много различни отказа. Обхват, който насочва правилно с грешна парола, дава един отказ, а обхват, който насочва към грешна база, може да отхвърли правилна парола или да приеме чужда. Никоя от грешките не споменава обхвата, затова първата диагностика винаги е една и съща: разберете коя система е отговорила.
Синтаксисът на обхвата принадлежи на разгръщането. Някои услуги искат неквалифицирано име плюс атрибут, други искат user@domain, а малцина очакват форма с обратна наклонена черта, която повечето ръководства не споменават.
Използвайте формата, която бекендът очаква
Попитайте оператора каква форма да въведете, преди да пробвате наставки от урок. Име с домейн, което стигне до бекенд, очакващ просто име, обикновено се проваля при търсенето, а не при проверката на паролата. Едно и също кратко име в две директории е случаят, в който липсващият обхват нанася най-голяма вреда.
Не приемайте административния акаунт за доказателство. Уеб конзолата, от която администрирате услугата, може да се удостоверява срещу локален файл, докато тунелът проверява съвсем друга директория. Тествайте с данните, които би използвал реален потребител, на интерфейса, който би използвал реален потребител. Успешното влизане в конзолата не казва нищо за обхвата, който шлюзът прилага към VPN удостоверяването.
Браузърите и пощенските клиенти понякога кешират предишна идентичност и я изпращат отново тихо. Когато отчетеното потребителско име се различава от въведеното, този кеш е първото място за проверка.
Проследете заявката през проксито
На фронтенд FreeRADIUS обхватите се декларират в конфигурацията на проксито и декларираната наставка решава кой домашен сървър получава заявката. Прочетете този файл, преди да промените нещо, защото заявка без съответстващ обхват по подразбиране се обработва локално.
grep -n -A4 '^realm' /etc/freeradius/3.0/proxy.conf
radtest '[email protected]' 'wrong-password' 10.20.30.10 0 testing123
journalctl -u freeradius --since '-10 min' | grep -iE 'realm|stripped'
grep показва кои наставки съществуват и към кой пул сочи всяка. Извикването radtest изпраща име с обхват и умишлено грешна парола, така че отказът доказва, че са се изпълнили и маршрутът, и проверката на данните. Редовете от журнала около този опит показват дали името е било отрязано преди проксирането и кой домашен сървър го е поел. Ако журналът не показва никакво съвпадение на обхват, заявката никога не е напускала локалния сървър и проблемът е в наставката, а не в паролата.
Променяйте по едно нещо и повтаряйте опита, защото журналът разделя маршрутизацията от отказа на данните само когато входът се различава между пусканията. Дръжте споделената тайна извън историята на shell, където инструментът поддържа четене от файл или от подкана.
Запишете опита, без да го издавате
Запишете отказа във форма, по която администратор може да действа: интерфейсът, формата на идентичността, имало ли е обхват и точната несекретна грешка. Дръжте живото потребителско име извън публичните доклади, а обхвата — вътре. Замъгляването на всяка идентичност до един и същ заместител скрива точно несъответствието, което търсите. Времевата марка също е важна, защото шлюзът, проксито и директорията водят отделни журнали.
После документирайте печелившата форма за потребителите, защото следващият, който я сбърка, отваря същия тикет. Нулирането на парола не оправя заявка, която продължава да попада в грешното пространство от имена. Обхватът е решение за маршрутизация и решенията за маршрутизация се оправят, като се именуват правилно.