LINUX.ORG.RU
решено ФорумAdmin

VPN-сервер не присваивает статичный IP виндовому клиенту. Линуксовому - присваивает

 , , ,


0

2

Есть openvpn-сервер на Centos 7. Его конфиг:

cat /etc/openvpn/server.conf
port 11000
proto udp
dev tun
ca /etc/openvpn/server/ca.crt
cert /etc/openvpn/server/VPN-October.crt
key /etc/openvpn/server/VPN-October.key
dh /etc/openvpn/server/dh2048.pem
tls-auth /etc/openvpn/server/ta.key 0
tls-server
tls-timeout 120
cipher AES-256-CBC
server 10.0.0.0 255.255.255.0
route 192.168.1.1 255.255.255.0
ifconfig-pool-persist ipp.txt
client-to-client
client-config-dir /usr/local/etc/ccd
keepalive 10 120
comp-lzo
tun-mtu 1500
persist-key
persist-tun
status /var/log/openvpn/openvpn-status.log
log /var/log/openvpn/openvpn.log
verb 3
user nobody
group nobody

В директорию с клиентскими настройками лежит файл с адресом для конкретного клиента:

cat /usr/local/etc/ccd/client
ifconfig-push 10.0.0.10 10.0.0.09

Сертификаты и ключи из конфига лежат в указанных местах.

Есть клиент на винде, его конфиг:

client
proto udp
remote-cert-tls server
tls-auth ta.key 1
dev tun
remote XX.XX.XX.XXX
port 11000
cipher AES-256-CBC
auth-nocache
verb 2
mute 20
keepalive 10 120
comp-lzo
persist-key
persist-tun
float
resolv-retry infinite
nobind

Клиент замечательно подключается к серверу. Но IP-адрес - только ближайший 10.0.0.6. Лог при этом такой:

Tue Oct 23 20:41:56 2018 OpenVPN 2.4.4 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Sep 26 2017
Tue Oct 23 20:41:56 2018 Windows version 6.1 (Windows 7) 64bit
Tue Oct 23 20:41:56 2018 library versions: OpenSSL 1.0.2l  25 May 2017, LZO 2.10
Enter Management Password:
Tue Oct 23 20:41:57 2018 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Oct 23 20:41:57 2018 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Oct 23 20:41:57 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]XX.XX.XX.XXX:11000
Tue Oct 23 20:41:57 2018 UDP link local: (not bound)
Tue Oct 23 20:41:57 2018 UDP link remote: [AF_INET]XX.XX.XX.XXX:11000
Tue Oct 23 20:41:57 2018 VERIFY OK: depth=1, C=US, ST=CA, L=SanFrancisco, O=Fort-Funston, OU=MyOrganizationalUnit, CN=Fort-Funston CA, name=EasyRSA, emailAddress=me@myhost.mydomain
Tue Oct 23 20:41:57 2018 VERIFY KU OK
Tue Oct 23 20:41:57 2018 Validating certificate extended key usage
Tue Oct 23 20:41:57 2018 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Tue Oct 23 20:41:57 2018 VERIFY EKU OK
Tue Oct 23 20:41:57 2018 VERIFY OK: depth=0, C=US, ST=CA, L=SanFrancisco, O=Fort-Funston, OU=MyOrganizationalUnit, CN=VPN-October, name=EasyRSA, emailAddress=me@myhost.mydomain
Tue Oct 23 20:41:57 2018 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
Tue Oct 23 20:41:57 2018 [VPN-October] Peer Connection Initiated with [AF_INET]XX.XX.XX.XXX:11000
Tue Oct 23 20:41:58 2018 Data Channel: using negotiated cipher 'AES-256-GCM'
Tue Oct 23 20:41:58 2018 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Tue Oct 23 20:41:58 2018 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Tue Oct 23 20:41:58 2018 open_tun
Tue Oct 23 20:41:58 2018 TAP-WIN32 device [Подключение по локальной сети 2] opened: \\.\Global\{7C109FB5-CF23-4F63-B80A-F75CD14A6BAB}.tap
Tue Oct 23 20:41:58 2018 Notified TAP-Windows driver to set a DHCP IP/netmask of 10.0.0.6/255.255.255.252 on interface {7C109FB5-CF23-4F63-B80A-F75CD14A6BAB} [DHCP-serv: 10.0.0.5, lease-time: 31536000]
Tue Oct 23 20:41:58 2018 Successful ARP Flush on interface [20] {7C109FB5-CF23-4F63-B80A-F75CD14A6BAB}
Tue Oct 23 20:41:58 2018 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Tue Oct 23 20:42:03 2018 Initialization Sequence Completed

На точно таком же сервере до этого работало присвоение статичного IP на виндовом клиенте (этом же), сейчас - нет. Конфиги делаю одинаковыми, результат - разный.

Пробовала сделать еще один сертификат для линуксовского клиента, создаем сертификат, добавляем в /usr/local/etc/ccd/client2018092107 запись, замечательно подключается с указанным IP. Логи подключения:

окт 23 21:03:50 client-centos openvpn[10700]: Tue Oct 23 21:03:50 2018 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
окт 23 21:03:50 client-centos openvpn[10700]: Tue Oct 23 21:03:50 2018 [VPN-October] Peer Connection Initiated with [AF_INET]XX.XX.XX.XXX:11000
окт 23 21:03:51 client-centos openvpn[10700]: Tue Oct 23 21:03:51 2018 Data Channel: using negotiated cipher 'AES-256-GCM'
окт 23 21:03:51 client-centos openvpn[10700]: Tue Oct 23 21:03:51 2018 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
окт 23 21:03:51 client-centos openvpn[10700]: Tue Oct 23 21:03:51 2018 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
окт 23 21:03:51 client-centos openvpn[10700]: Tue Oct 23 21:03:51 2018 TUN/TAP device tun0 opened
окт 23 21:03:51 client-centos openvpn[10700]: Tue Oct 23 21:03:51 2018 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
окт 23 21:03:51 client-centos openvpn[10700]: Tue Oct 23 21:03:51 2018 /sbin/ip link set dev tun0 up mtu 1500
окт 23 21:03:51 client-centos openvpn[10700]: Tue Oct 23 21:03:51 2018 /sbin/ip addr add dev tun0 local 10.0.0.14 peer 10.0.0.13
окт 23 21:03:51 client-centos openvpn[10700]: Tue Oct 23 21:03:51 2018 Initialization Sequence Completed

Конфиг сентосного клиента:

# cat /etc/openvpn/client-centos.conf
client
proto udp
remote-cert-tls server
tls-auth ta.key 1
dev tun
remote XX.XX.XX.XXX 11000
cipher AES-256-CBC
auth-nocache
verb 2
mute 20
keepalive 10 120
comp-lzo
persist-key
persist-tun
float
resolv-retry infinite
nobind 

Куда посмотреть, чтобы найти косяк?

/usr/local/etc/ccd/client

файл client (имя файла - имя которому выдан сертификат) следующего содержания

Это тупость конечно, но имена точно совпадают?

mandala ★★★★ ()
Ответ на: комментарий от mandala

Это тупость конечно, но имена точно совпадают?

Вы очень правильно замечаете, как не странно это «Не тупость». Уже куча тем на разных ресурсах утыкалась в это. Обычно доходит до не читаемого символа в имени файла.

anc ★★★★★ ()
Ответ на: комментарий от anc

Да, непечатный символ я как то дебагом в портянке конфига вылавливал...

А кодировка из windows не может влиять? А еще в client может закрасться русская с.

mandala ★★★★ ()
Последнее исправление: mandala (всего исправлений: 1)
Ответ на: комментарий от mandala

Все это лирика имеющая место быть. Но, дождемся таки лога сервака, как вы правильно попросили выше. Думаю что ТС не заставит себя ждать с ними.

anc ★★★★★ ()
Ответ на: комментарий от ivn86

см. Subnet topology is the current recommended topology.

В котором точно такой же пример --ifconfig-push 10.8.0.10 10.8.0.9

ЗЫ И просто интересно вы с какого потолка придумали такую маску 255.255.255.224 ?

anc ★★★★★ ()
Ответ на: комментарий от anc

В котором точно такой же пример --ifconfig-push 10.8.0.10 10.8.0.9

Нет. Если посмотреть внимательно, то для сабнета там пример

--ifconfig-push 10.8.0.3 255.255.255.0

вы с какого потолка придумали такую маску 255.255.255.224 ?

А что не так в этой маске? Подсеть на тридцать хостов, ИМХО более чем достаточно для мелкого корпоративного VPN.

ivn86 ()
Ответ на: комментарий от ivn86

Нет. Если посмотреть внимательно, то для сабнета там пример

Если «посмотреть внимательно» у ТС не subnet. Вот зачем давать советы которые не применимы?

anc ★★★★★ ()
Ответ на: комментарий от ivn86

А что не так в этой маске? Подсеть на тридцать хостов, ИМХО более чем достаточно для мелкого корпоративного VPN.

Вам это голоса в голове подсказали что ТС достаточно 30? Я в топике такого не увидел.

anc ★★★★★ ()
Ответ на: комментарий от anc

у ТС не subnet.

Топология явно не указана, и учитывая что это Centos 7, openvpn 2.4.6, то там субнет по умолчанию.

Вот зачем давать советы которые не применимы?

Затем, что у меня Centos 7, openvpn 2.4.6, 27 подсеть и всё работает.

ivn86 ()

notified TAP-Windows driver to set a DHCP IP/netmask of 10.0.0.6/255.255.255.252 on interface {7C109FB5-CF23-4F63-B80A-F75CD14A6BAB} [DHCP-serv: 10.0.0.5, lease-time: 31536000]

10.0.0.5 кто в данном случае? {7C109FB5-CF23-4F63-B80A-F75CD14A6BAB} в виндовом реестре обнулить

anonymous ()
Ответ на: комментарий от anc

Вам это голоса в голове подсказали что ТС достаточно 30? Я в топике такого не увидел.

Последний октет ip ТС ниже 30 и для попробовать этого достаточно. На этом я заканчиваю флуд с тобой, тебе, видимо, скучно.

ivn86 ()
Ответ на: комментарий от ivn86

Топология явно не указана, и учитывая что это Centos 7, openvpn 2.4.6, то там субнет по умолчанию.

Вот не поверил я вам и решил проверить на тестовой машинке
Конфиг почти полностью (прямо скопипастил) соответствует конфигу ТС, за исключением путей и названий сертификатов.

CentOS Linux release 7.5.1804 (Core) 
OpenVPN 2.4.6 x86_64-redhat-linux-gnu [Fedora EPEL patched] [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Apr 26 2018
Wed Oct 24 18:40:26 2018 test1/172.19.0.1:40123 SENT CONTROL [test1]: 'PUSH_REPLY,route 10.0.0.0 255.255.255.0,topology net30,ping 10,ping-restart 120,ifconfig 10.0.0.10 10.0.0.9,peer-id 0' (status=1)[br]
Суслика topology net30 видим? Так что плиз не надо голословных утверждений, если сами не разбираетесь в теме.

Но нет худа без добра ваша упоротость помогла. Отвечу ТС отдельно.

anc ★★★★★ ()

Найденное решение. ifconfig-push 10.0.0.10 10.0.0.09 нолик уберите перед 9-кой, т.е. должно быть так ifconfig-push 10.0.0.10 10.0.0.9 и вы могли бы это сами увидеть в логах сервера, при 10.0.0.09 он пытается отрезолвить, т.е. считает это именем.

anc ★★★★★ ()
Последнее исправление: anc (всего исправлений: 1)
Ответ на: комментарий от anc

субнет по умолчанию.

не надо голословных утверждений

Признаю свой косяк. Ещё раз сличил свой конфиг и ТС — в моём случае tap device и для него: :

–topology mode ... This directive has no meaning in –dev tap mode, which always uses a subnet topology

Если «посмотреть внимательно» у ТС не subnet.

Согласен, прошу прощения.

ivn86 ()
Ответ на: комментарий от ivn86

Ничего страшного, бывает. Я ведь даже повелся (найдете в удаленных) :)
Но зато (хоть и косвенно) скорее всего выяснили проблему раньше чем ТС «проснулась» с логами сервака :)

anc ★★★★★ ()