Аутентификация OpenVPN по доменным уч.записям.
-
Доброго времени! имеется pfSense 2.4.4-RELEASE-p3, на нем настроен OpenVPN, на pf имеется две локальных учетных записи, OpenVPN по ним работает замечательно, но хотелось бы что бы не заводить под каждого локальную учетную запись на pf, организовать аутентификацию по доменным учетным записям, в настройка System/User Manager/Authentication Servers все настроил, в System/User Manager/Settings если сделать Test:
Attempting connection to OK
Attempting bind to OK
Attempting to fetch Organizational Units from OK
так же если во вкладке Diagnostics/Authentication проверить любую доменную учетную запись, то она проходит проверку подлинности, создал дополнительный сервер OpenVPN по аналогии с работающим на данный момент, только в Backend for authentication указал не локальную базу а базу из AD, во вкладке Client Export Utility в пункте Remote Access Server выбираю новый сервер, в пункте OpenVPN Clients у меня отображаются всего три учетных записи, две из которых мои локальные pf, только у них уже название другое "Certificate with External Auth" а в случае с локальной базой, они отображаются по другому, но не суть, есть еще третий пользователь и в качестве него отображается имя корневого сертификат pf, хотелось бы узнать так должно быть или все таки там должны отобразиться все доменные учетные записи и конфигурации к ним?, попробовал конфигурацию которая с именем корневого сертификата, доменные учетные записи не подключаются к серверу OpenVPN:
TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
TLS Error: TLS handshake failed
что я делаю не так? -
@Guf-Rolex-X said in Аутентификация OpenVPN по доменным уч.записям.:
TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Проверьте для начала подключение клиента с локальной учетной записью.
само по себе сообщение
TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
с вероятностью 99% может говорить просто о невозможности начать соединение клиент->сервер, причин для этого множество. -
@pigbrother при подключении с локальной учетной записью все в порядке, второй сервер OpenVPN настраивал идентично, только в пункте Remote Access Server выбрал учетные записи из AD, в остальном все так же, почему не хочет подключаться не понятно.
-
@Guf-Rolex-X said in Аутентификация OpenVPN по доменным уч.записям.:
OpenVPN настраивал идентично, только в пункте Remote Access Server выбрал учетные записи из AD,
Эта ошибка возникает на этапе начала "рукопожатия" клиент->сервер, до какой либо аутентификации еще далеко.
Посмотрите логи сервера, скорее всего никаких попыток подключения не увидите.
Отключите от клиента интернет и с вероятностью 99,9% процента в логе клиента после 60 секунд ожидания будет:TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
TLS Error: TLS handshake failed -
@Guf-Rolex-X
Либо TLS key не задан в конф-ции клиента. Или не задан обмен этим ключом там же. -
@werter said in Аутентификация OpenVPN по доменным уч.записям.:
@Guf-Rolex-X
Либо TLS key не задан в конф-ции клиента. Или не задан обмен этим ключом там же.В этом случае а логах сервера обычно идет идет ругань на тему HMAC.
@pigbrother said in Аутентификация OpenVPN по доменным уч.записям.:
Посмотрите логи сервера
Это явно не было сделано.
@pigbrother said in Аутентификация OpenVPN по доменным уч.записям.:
причин для этого множество.
Посыл был - аутентификация явно не при чем, в конфигурации сервера\клиента явно ошибка(и) и искать их - задача ТС.
-
здравствуйте! спасибо что отозвались, попробовал сменить режиме сервера (для теста) выбрал Remote acces (User Auth) в данном режиме сразу стала срабатывать аутентификация по доменным уч.записям, в случае с локальной базой выбран режим Remote acces (SSL/TLS+User Auth), если изменить на такой же режим то в журнале клиента: TCP/UDP: Incoming packet rejected from [AF_INET]IP:1194[2], expected peer address: [AF_INET]IP:1195 (allow this incoming source address/port by removing --remote or adding --float) откуда берется порт 1194 не пойму?, я же подключаюсь по порту 1195 так как указал его при настройке второго сервера, что бы был отличный от дефолтного, правило на порт 1195 на WAN интерфейсе имеется, из логов с pf:
Mar 31 13:13:49 openvpn 46282 178.44.153.124:1194 VERIFY ERROR: depth=0, error=unsupported certificate purpose: C=RU, ST=Region, L=Gorod, O=Organizacion, emailAddress=mail.ru, CN=192.168.50.6
Mar 31 13:13:49 openvpn 46282 178.44.153.124:1194 OpenSSL: error:14089086:SSL routines:ssl3_get_client_certificate:certificate verify failed
Mar 31 13:13:49 openvpn 46282 178.44.153.124:1194 TLS_ERROR: BIO read tls_read_plaintext error
Mar 31 13:13:49 openvpn 46282 178.44.153.124:1194 TLS Error: TLS object -> incoming plaintext read error
Mar 31 13:13:49 openvpn 46282 178.44.153.124:1194 TLS Error: TLS handshake failed
в статусе OpenVPN то же отображает подключение по порту 1194 а не 1195, что за? -
@Guf-Rolex-X said in Аутентификация OpenVPN по доменным уч.записям.:
в статусе OpenVPN то же отображает подключение по порту 1194 а не 1195, что за?
Не знаю, почему так.
Реально используемые настройки сервера(клиента) удобно посмотреть тут:
/var/etc/openvpn/serverX.conf (clientX.conf)
Можно прямо из
Diagnostics->Edit FileУ вас, похоже, еще и и ошибка с назначением сертификатов:
@Guf-Rolex-X said in Аутентификация OpenVPN по доменным уч.записям.:
VERIFY ERROR: depth=0, error=unsupported certificate purpose: C=RU, ST=Region, L=Gorod, O=Organizacion, emailAddress=mail.ru, CN=192.168.50.6
Для чего в качестве CN вы используете IP?
-
@pigbrother вот и я не понимаю как так получается что указан порт один а подключается на другой, в настройках сервера server2.conf если посмотреть то указан lport 1195, пробовал менять на другие порты безрезультатно, попробовал сменить в настройках сервера с UDP на TCP, проверил доступность порта telnet-ом, порт открыт, пробую подключиться:
Wed Apr 01 13:04:51 2020 Attempting to establish TCP connection with [AF_INET]IP:1195 [nonblock]
Wed Apr 01 13:04:52 2020 TCP connection established with [AF_INET]IP:1195
Wed Apr 01 13:04:52 2020 TCP_CLIENT link local: (not bound)
Wed Apr 01 13:04:52 2020 TCP_CLIENT link remote: [AF_INET]IP:1195
Wed Apr 01 13:04:52 2020 Connection reset, restarting [0]
и постоянный рестарт, как попал IP-адрес в CN не знаю, по идее там должно быть имя, но думаю это не критично так как там что угодно можно написать, в сертификате реально сменить CN или только заново пересоздавать сертификат? -
@Guf-Rolex-X said in Аутентификация OpenVPN по доменным уч.записям.:
в сертификате реально сменить CN или только заново пересоздавать сертификат?
Заново издать.
-
@pigbrother подскажите с чем может быть связана "ошибка с назначением сертификата", переиздал заново все сертификаты: CA сертификат, Серверный сертификат, Клиентский сертификат, CN указывал имя как с пробелом так и через дефис, все равно в логах ошибки
VERIFY ERROR: depth=0, error=unsupported certificate purpose
OpenSSL: error:14089086:SSL routines:ssl3_get_client_certificate:certificate verify failed
TLS_ERROR: BIO read tls_read_plaintext error
TLS Error: TLS object -> incoming plaintext read error
TLS handshake failed
принципиально что бы совпадало имя pf и имя CN? -
@Guf-Rolex-X said in Аутентификация OpenVPN по доменным уч.записям.:
принципиально что бы совпадало имя pf и имя CN?
Нет, не принципиально.
С подобными ошибками не встречался.
-
доброго дня! разобрался, когда создавал второй сервер OpenVPN с другой подсетью и портом то в пункте Server certificate указывал этот же сертификат сервера т.е тот же который указан в первом сервер OpenVPN отсюда ошибка:
TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
TLS Error: TLS handshake failed- скачивал конфигурацию для клиента с сертификатом сервера а не клиента, издал новый сертификат сервера и клиента и все заработало, что касается ошибки:
TCP/UDP: Incoming packet rejected from [AF_INET]IP:1194[2], expected peer address: [AF_INET]IP:1195 (allow this incoming source address/port by removing --remote or adding --float)
то в конфигурации клиента последней строчкой указал параметр "float", в общем сейчас подключаюсь по доменным уч.записям без проблем, всем спасибо за помощь.
- скачивал конфигурацию для клиента с сертификатом сервера а не клиента, издал новый сертификат сервера и клиента и все заработало, что касается ошибки:
-
This post is deleted!
