Сервер L2TP/IPsec - зарезервировать IP-адрес для определенного пользователя в AD

Я установил довольно простой L2TP/IPsec-сервер с xl2tpd, который имеет пул IP-адресов в xl2tpd.conf, настроенный для VPN-клиентов. Теперь мне нужно назначить определенный IP-адрес VPN-клиенту, если этот клиент использует определенное имя пользователя с правильным паролем. Проблема в том, что pppd настроен для запуска помощника по аутентификации для аутентификации пользователей в домене Active Directory, поэтому я не могу использовать файл chap.secrets, чтобы указать IP-адрес для соединения, которое установлено с данным именем пользователя. Более того, pppd получает предложенные (?) IP-адреса из пула xl2tpd, таким образом, адрес выделяется до аутентификации, и он также, похоже, игнорирует ipcp-accept-remote директива в файле опций, которая технически позволяет клиенту L2TP указывать желаемый IP-адрес, или я бы просто установил статический IP-адрес в настройках клиента. Клиент в Windows 7.

Как я могу заставить pppd назначать определенный IP-адрес соединению после его аутентификации в Windows AD?

Редактировать: похоже, что с настроенным помощником проверки подлинности NTLM pppd никогда не использует файл chap-secrets, поэтому все, что я ввожу туда, просто не используется. Итак, это просто невозможно?

1 ответ

Короче говоря, нет ничего невозможного, просто нужно больше или другие инструменты. Мне удалось настроить сервер RADIUS, я использовал freeradius, чтобы не мешать работе с Windows, но, возможно, сервер MS-RADIUS с его msRADIUSFramed-IP-Address Атрибут тоже подойдет. Настроил пул для "обычных" пользователей, назначил его через файл пользователя DEFAULT затем настройте оба типа аутентификации (требуется дополнительное тестирование, в любом случае работает ntlm_auth поверх mschap), а затем пошли на сопоставление имени пользователя, чтобы назначить IP-адреса непосредственно в конфигурации freeradius. Тупой но работает.

Набор хаков: во-первых, я не смог правильно заполнить Stripped-User-Name атрибут, поэтому пошел с mschap:User-Name для предоставления в ntlm_auth, иначе вызов / резонанс формируется против полного имени вместо сокращенного имени, и ntlm_auth быстро завершается неудачей, так как winbind не ожидает полных имен. Maaaybe Я должен заставить его работать правильно, но winbindd склонен к сбою, когда UPN начинают вызывать, а sssd backend не использует NTLM для аутентификации mschap-sequence. Во-вторых, я переехал files до mschap в последовательности авторизации, чтобы иметь обоих типов пользователей, локальных и доменных. В-третьих, я сначала все протестировал с PAP, и при переходе на mschap я обнаружил, что mschap сообщает о том, что ntlm_auth не может читать vs winbindd. Я не смог заставить radiusd правильно запустить ntlm_auth как пользователь с ограниченными правами (вне времени) и вместо этого заставил radiusd запускаться от имени пользователя root. (Пожалуйста, сделайте это надлежащим образом, когда вы будете выполнять проверку подлинности RADIUS-сервера на домене!) Но RADIUS прослушивает только 127.0.0.1, поэтому ожидается, что безопасность не ухудшится.

Другие вопросы по тегам