Запрос на функцию: Использование беспроводной личной парольной фразы в качестве совпадения в списке доступа

С WPA2-EAP это можно сделать по стандартам. Почти все клиенты это поддерживают.

Ты всегда можешь купить AP, который это поддерживает! Полностью все функции в любых устройствах по любым ценам ты никогда не найдёшь.

Да, такие устройства, как Chromecast и принтеры, не поддерживают EAP. Раньше я тоже мечтал о назначении VLAN на основе пароля без использования RADIUS. В итоге я сделал это через хотспот, CAPSMAN и немного скриптов — логины в хотспоте попадают в отдельный VLAN. Работает очень хорошо, учитывая, что RADIUS вообще не задействован. Разумеется, использование хотспота означает отсутствие шифрования Wi-Fi (пока не появится WPA3).

Я использую этот скрипт на системе хотспота: hotspot-to-wpa (добавьте его с on-login=hotspot-to-wpa в профиль хотспота). Пользователю нужно подключиться к открытой сети и пройти аутентификацию на хотспоте. Создаётся запись в списке доступа для его устройства (по MAC-адресу), используя пароль хотспота в качестве WPA-пароля. Это не совсем то, что требовалось, но, возможно, кому-то пригодится или даст идеи.

Итак, нужно назначить пользователя конкретной VLAN. Можно использовать имя пользователя (доступно как $UserName) или его часть. То есть, если пользователь с именем «1234» и паролем «secret» входит в систему, вы создаёте запись списка доступа для VLAN 1234, с MAC-адресом пользователя и его паролем «secret». Либо можно получить VLAN из комментариев в «/ ip hotspot user»…

Мой скрипт ожидает, что у вас есть открытая сеть для точки доступа (назовём её «example») и сеть с включённым WPA, имя которой заканчивается на «-wpa» (в нашем случае это будет «example-wpa»). Вы можете добавить информацию и инструкции в «alogin.html», чтобы они отображались гостям после успешного входа.

Точка доступа (AP) не «проверяет» пароль, потому что клиент его никогда не отправляет AP. AP использует известный пароль в вычислениях и с помощью этих проверок определяется, знает ли клиент тот же пароль. По сути, 802.11 PSK — это алгоритм, который позволяет обеим сторонам (как AP, так и клиенту) подтвердить, что другой использует тот же пароль, не передавая его по воздуху. Так работает протокол, подробности смотрите в стандарте 802.11.

Это означает, что на практике невозможно, например, отправить пароль, который использует клиент, на RADIUS-сервер или использовать его для сравнения с access-list. Также учтите, что сравнение с access-list происходит до обмена ключами, подтверждающего пароль — к тому же access-list может даже предоставить этот пароль через private-passphrase после срабатывания правила.

Я говорю «на практике», потому что теоретически AP мог бы проверить информацию, которую клиент передает, с каждой возможной фразой. Это возможно, поскольку AP первым проверяет данные от клиента, чтобы определить, использовался ли правильный пароль. Вероятно, такую функцию можно было бы реализовать в некоторой мере, чтобы AP проверял по фиксированному набору паролей и выполнял нужное действие, но, к сожалению, это невозможно встроить в текущий access-list (проверка access-list происходит до обмена ключами) или отправить пароль на RADIUS-сервер (пароль неизвестен).