LINUX.ORG.RU
ФорумAdmin

OpenVPN сервер за NAT multi new connection by client to be dropped

 ,


1

1

Добрый день, прошу вашей помощи! Много пересмотрел форумов, но решения не нашёл. Есть шлюз с двумя сетевыми картами. Одна смотрит в инет, вторая в локалку. На нём проброшено подключение из вне к OpenVPN серверу. Сервер c Ubuntu 22.04 находится в локальной сети. Настройки на шлюзе следующие:

iptables -t nat -A PREROUTING -s 0/0 -d 92.92.92.92/32 -p udp -m udp --dport 1194 -j DNAT --to-destination 192.168.1.11:1194
iptables -A FORWARD -p udp -s 0/0 -d 192.168.1.11 --dport 1194 -j ACCEPT
iptables -A FORWARD -p udp -d 0/0 -s 192.168.1.11 --sport 1194 -j ACCEPT

На OpenVPN сервере настройки такие server.conf

mode server
port 1194
proto udp
dev tun
management localhost 7505
ca ca.crt
cert srv-ovpn.crt
key srv-ovpn.key
dh dh.pem
tls-crypt ta.key
server 20.20.28.0 255.255.252.0
ifconfig-pool-persist ipp.txt
client-config-dir /etc/openvpn/server/ccd
push "route 192.168.1.0 255.255.255.0"
push "dhcp-option DNS 192.168.1.1"
topology subnet
keepalive 10 120
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
status /var/log/openvpn/openvpn-status.log
log /var/log/openvpn/openvpn.log
verb 4
cipher AES-256-GCM
auth SHA256
tls-version-min 1.2
crl-verify crl.pem

client.conf

client
dev tun
proto udp
remote 92.92.92.92 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert pso.crt
key pso.key
remote-cert-tls server
tls-crypt ta.key 1
comp-lzo
verb 3
cipher AES-256-GCM
auth SHA256
tls-version-min 1.2

Пытался /etc/openvpn/server/ccd добавить в неё файлы pso с текстом

ifconfig-push 20.20.28.3 20.20.28.4
iroute 20.20.28.0 255.255.252.0

gorka1 с текстом

ifconfig-push 20.20.28.5 20.20.28.6
iroute 20.20.28.0 255.255.252.0

Сервер будто начихал на них. Путь правил до ccd.

cat /etc/sysctl.conf

net.ipv4.ip_forward=1
net.ipv4.conf.all.forwarding=1

в iptables стоит

-A POSTROUTING -s 20.20.28.0/22 -d 0/0 -j SNAT --to-source 192.168.1.11 (192.168.1.11 адрес ВПН сервера в локалке)

Проблема в том что при подключении из вне к OpenVPN серверу может подключиться только один клиент. Клиенты в филиале сидят за белым IP адресом, роутером. На ПК (4 шт.) стоит Windows 7/10 с установленными openvpn клиентами. У каждого в конфиге свой сертификат. При подключении второго клиента выходит ошибка на сервере! В итоге клиент не может подключиться.

MULTI: new connection by client ‘gorka1’ will cause previous active sessions by this client to be dropped. Remember to use the –duplicate-cn option if you want multiple clients using the same certificate or username to concurrently connect.

MULTI: bad source address from client [::], packet dropped

Если на сам шлюз установить OpenVPN сервер то всё работает как часы. Прошу вашей помощи ребята.



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

Погоди, всё обычно не так происходит, в начале, первый день, принято спрашивать всё что угодно и ничего не говорить про логи, а автор должен тупить и спрашивать как выполнить то, что его просят, а в случае всё же упоминания про логи - сказать, что не знает что это и как смотреть и что Linux он поставил только сегодня.

А вот на второй день - уже можно и про логи.

Торопишься.

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

Чтобы удалённый пользователь мог подключиться к сервисам - OpenVPN сервер должен передавать маршруты в сторону клиента.

А не вот этот вот NAT делать.

push "route 10.0.2.0 255.255.255.0"
push "route 10.0.4.0 255.255.255.0"
push "route 10.33.0.0 255.255.252.0"
push "route 10.33.8.0 255.255.252.0"
push "route 192.168.150.0 255.255.255.0"
push "route 192.168.152.0 255.255.255.0"
push "route 192.168.100.0 255.255.255.0"
push "route 192.168.133.0 255.255.255.0"

Что-то вроде в конфиге сервера.

И в маршрутизации в твоей сети должно быть известно, либо про VPN сеть, либо да делать NAT для пакетов с tun / tap интерфейса на VPN сервере в IP адрес VPN сервера.

Вот так, тогда уж:

-A POSTROUTING -s 20.20.28.0/22 -o eth0 -j MASQUERADE
-A POSTROUTING -s 20.20.28.0/22 -o eth0 -j SNAT --to-source 192.168.1.11

Исходящий интерфейс, во внутреннюю сеть, сам правильно укажи. Иначе ты и в сторону VPN клиентов меняешь адрес источника на 192.168.1.11, а он в сторону клиентов должен быть либо 20.20.28.1, либо одним из /30, в зависимости от топологии сети.

kostik87 ★★★★★
()
Последнее исправление: kostik87 (всего исправлений: 3)
Ответ на: комментарий от kostik87
92.124.131.56:59396 Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1550,tun-mtu 1500,proto UDPv4,comp-lzo,cipher AES-256-GCM,auth [null-digest],keysize 256,key-method 2,tls-server'
92.124.131.56:59396 Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1550,tun-mtu 1500,proto UDPv4,comp-lzo,cipher AES-256-GCM,auth [null-digest],keysize 256,key-method 2,tls-client'
92.124.131.56:59396 TLS: Initial packet from [AF_INET]92.124.131.56:59396, sid=90e16f9f 8e85b50d
92.124.131.56:59396 VERIFY OK: depth=1, CN=CA_OGSE_2026
92.124.131.56:59396 VERIFY OK: depth=0, CN=gorka1
92.124.131.56:59396 peer info: IV_VER=2.4.6
92.124.131.56:59396 peer info: IV_PLAT=win
92.124.131.56:59396 peer info: IV_PROTO=2
92.124.131.56:59396 peer info: IV_NCP=2
92.124.131.56:59396 peer info: IV_LZ4=1
92.124.131.56:59396 peer info: IV_LZ4v2=1
92.124.131.56:59396 peer info: IV_LZO=1
92.124.131.56:59396 peer info: IV_COMP_STUB=1
92.124.131.56:59396 peer info: IV_COMP_STUBv2=1
92.124.131.56:59396 peer info: IV_TCPNL=1
92.124.131.56:59396 Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384, peer certificate: 384 bit EC, curve secp384r1, signature: RSA-SHA256
92.124.131.56:59396 [gorka1] Peer Connection Initiated with [AF_INET]92.124.131.56:59396
MULTI: new connection by client 'gorka1' will cause previous active sessions by this client to be dropped.  Remember to use the --duplicate-cn option if you want multiple clients using the same certificate or username to concurrently connect.
MULTI_sva: pool returned IPv4=20.20.28.8, IPv6=(Not enabled)
MULTI: Learn: 20.20.28.8 -> gorka1/92.124.131.56:59396
MULTI: primary virtual IP for gorka1/92.124.131.56:59396: 20.20.28.8
Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
gorka1/92.124.131.56:59396 PUSH: Received control message: 'PUSH_REQUEST'
gorka1/92.124.131.56:59396 SENT CONTROL [gorka1]: 'PUSH_REPLY,route 192.168.1.0 255.255.255.0,dhcp-option DNS 192.168.1.1,route-gateway 20.20.28.1,topology subnet,ping 10,ping-restart 120,ifconfig 20.20.28.8 255.255.252.0,peer-id 1,cipher AES-256-GCM' (status=1)
MULTI: multi_create_instance called
92.124.131.56:57462 Re-using SSL/TLS context
92.124.131.56:57462 Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
92.124.131.56:57462 Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
92.124.131.56:57462 Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
92.124.131.56:57462 Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
92.124.131.56:57462 LZO compression initializing
92.124.131.56:57462 Control Channel MTU parms [ L:1622 D:1156 EF:94 EB:0 ET:0 EL:3 ]
92.124.131.56:57462 Data Channel MTU parms [ L:1622 D:1450 EF:122 EB:406 ET:0 EL:3 ]
92.124.131.56:57462 Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1550,tun-mtu 1500,proto UDPv4,comp-lzo,cipher AES-256-GCM,auth [null-digest],keysize 256,key-method 2,tls-server'
92.124.131.56:57462 Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1550,tun-mtu 1500,proto UDPv4,comp-lzo,cipher AES-256-GCM,auth [null-digest],keysize 256,key-method 2,tls-client'
Indeez
() автор топика
Ответ на: комментарий от Pinkbyte

Ну что ты говоришь, автор же сказал - нет )

Возможно, причиной кривой SNAT на VPN:

-A POSTROUTING -s 20.20.28.0/22 -d 0/0 -j SNAT --to-source 192.168.1.11

Тут во всех пакетах, в том числе и уходящих в tun интерфейс меняется адрес источника.

Тогда уж так:

-A POSTROUTING -s 20.20.28.0/22 -o eth0 -j MASQUERADE
-A POSTROUTING -s 20.20.28.0/22 -o eth0 -j SNAT --to-source 192.168.1.11
kostik87 ★★★★★
()
Ответ на: комментарий от kostik87

Спасибо за комментарии, чтобы не путаться удалил в конфиге сервера ссылку на каталог ccd. Осталось push «route 192.168.1.0 255.255.255.0». Это как раз тот маршрут который прописывается у клиента. И это у меня уже есть. Но когда клиент делает пинг на сервер 192.168.1.123 то пакеты приходят с адреса 20.20.28.3 и чтобы ему ответить нужно на этом сервере прописать маршрут. Но я не стал этого делать и решил добавить правила в nat postrouting. Дальше есть разбирать правила. Это по сути одно и тоже. Маскарад больше для dhcp интерфейса, а у меня статика.

-A POSTROUTING -s 20.20.28.0/22 -o eth0 -j MASQUERADE -A POSTROUTING -s 20.20.28.0/22 -o eth0 -j SNAT –to-source 192.168.1.11. А вот как раз вторая строка в сторону клиентов впн ничего не меняет. Поправьте меня гуру если я не прав.

Indeez
() автор топика
Ответ на: комментарий от XMPP

Вот свежий вариант, первый уже подключен, подключаюсь вторым

MULTI: multi_create_instance called
92.124.131.56:60637 Re-using SSL/TLS context
92.124.131.56:60637 Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
92.124.131.56:60637 Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
92.124.131.56:60637 Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
92.124.131.56:60637 Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
92.124.131.56:60637 LZO compression initializing
92.124.131.56:60637 Control Channel MTU parms [ L:1622 D:1156 EF:94 EB:0 ET:0 EL:3 ]
92.124.131.56:60637 Data Channel MTU parms [ L:1622 D:1450 EF:122 EB:406 ET:0 EL:3 ]
92.124.131.56:60637 Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1550,tun-mtu 1500,proto UDPv4,comp-lzo,cipher AES-256-GCM,auth [null-digest],keysize 256,key-method 2,tls-server'
92.124.131.56:60637 Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1550,tun-mtu 1500,proto UDPv4,comp-lzo,cipher AES-256-GCM,auth [null-digest],keysize 256,key-method 2,tls-client'
92.124.131.56:60637 TLS: Initial packet from [AF_INET]92.124.131.56:60637, sid=33ab7156 68214a6e
92.124.131.56:60637 VERIFY OK: depth=1, CN=CA_OGSE_2026
92.124.131.56:60637 VERIFY OK: depth=0, CN=pso
92.124.131.56:60637 peer info: IV_VER=2.4.6
92.124.131.56:60637 peer info: IV_PLAT=win
92.124.131.56:60637 peer info: IV_PROTO=2
92.124.131.56:60637 peer info: IV_NCP=2
92.124.131.56:60637 peer info: IV_LZ4=1
92.124.131.56:60637 peer info: IV_LZ4v2=1
92.124.131.56:60637 peer info: IV_LZO=1
92.124.131.56:60637 peer info: IV_COMP_STUB=1
92.124.131.56:60637 peer info: IV_COMP_STUBv2=1
92.124.131.56:60637 peer info: IV_TCPNL=1
92.124.131.56:60637 Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384, peer certificate: 384 bit EC, curve secp384r1, signature: RSA-SHA256
92.124.131.56:60637 [pso] Peer Connection Initiated with [AF_INET]92.124.131.56:60637
MULTI: new connection by client 'pso' will cause previous active sessions by this client to be dropped.  Remember to use the --duplicate-cn option if you want multiple clients using the same certificate or username to concurrently connect.
MULTI_sva: pool returned IPv4=20.20.28.7, IPv6=(Not enabled)
MULTI: Learn: 20.20.28.7 -> pso/92.124.131.56:60637
MULTI: primary virtual IP for pso/92.124.131.56:60637: 20.20.28.7
Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
pso/92.124.131.56:60637 PUSH: Received control message: 'PUSH_REQUEST'
pso/92.124.131.56:60637 SENT CONTROL [pso]: 'PUSH_REPLY,route 192.168.1.0 255.255.255.0,dhcp-option DNS 192.168.1.1,route-gateway 20.20.28.1,topology subnet,ping 10,ping-restart 120,ifconfig 20.20.28.7 255.255.252.0,peer-id 2,cipher AES-256-GCM' (status=1)
pso/92.124.131.56:60637 MULTI: bad source address from client [::], packet dropped
Indeez
() автор топика
Ответ на: комментарий от Pinkbyte
root@srv-ovpn:/etc/openvpn/ca/easy-rsa/pki/issued# openssl x509 -in pso.crt -serial -issuer -fingerprint -pubkey -noout
serial=B55D8910894758B3DAE28A6FD2AF84E2
issuer=CN = CA_OGSE_2026
SHA1 Fingerprint=57:75:B8:DC:3B:85:55:21:E8:AF:38:DF:AC:2F:E1:48:AD:AB:9C:A6
-----BEGIN PUBLIC KEY-----
MHYwEAYHKoZIzj0CAQYFK4EEACIDYgAE9di9gZxh1BaIgrD+t9ksSq4b+UfTSnD4
pvbdLaZfXedZWIA1xOfo+El+rs70sv7k01i8L+rzeJ3wrJvIFomLyYdlJVKOVNzg
HvW9fBsb4lONCde7m+aMevVlSBvruIfl
-----END PUBLIC KEY-----
root@srv-ovpn:/etc/openvpn/ca/easy-rsa/pki/issued# openssl x509 -in gorka1.crt -serial -issuer -fingerprint -pubkey -noout
serial=5374350977D0BA054EF7876306FA915D
issuer=CN = CA_OGSE_2026
SHA1 Fingerprint=71:E4:30:D1:D2:65:E9:CE:C0:80:D7:57:05:B3:D0:8B:62:A3:77:1F
-----BEGIN PUBLIC KEY-----
MHYwEAYHKoZIzj0CAQYFK4EEACIDYgAE55I01zSjQZHcVkW6tO7KZVGKqz83M/Gq
LqLnxk/zWvHSh2v/v4eLPYQjoLjHaYkfmL3LNKWnQ0Ry38P8w0OJPCML2P8MPYC/
d6PCpjgYCx80ve6QPwFNUnWWmWIgKz3M
-----END PUBLIC KEY-----
root@srv-ovpn:/etc/openvpn/ca/easy-rsa/pki/issued#

Indeez
() автор топика

Пытался /etc/openvpn/server/ccd добавить в неё файлы pso с текстом

ifconfig-push 20.20.28.3 20.20.28.4 iroute 20.20.28.0 255.255.252.0

gorka1 с текстом

ifconfig-push 20.20.28.5 20.20.28.6 iroute 20.20.28.0 255.255.252.0

Сервер будто начихал на них. Путь правил до ccd.

Что вы пытаетесь этим добиться?

  • ifconfig-push с теми параметрами, что вы указываете, были бы правильны при topology net30, а у вас subnet.
  • iroute это маршрутизация подсети к клиенту (ip route via …, только для L3-туннеля). Одна подсеть не может быть смаршрутизирована двум клиентам одновременно.

MULTI: new connection by client ‘gorka1’ will cause previous active sessions by this client to be dropped. Remember to use the –duplicate-cn option if you want multiple clients using the same certificate or username to concurrently connect.

Вы либо используете неуникальные ключи, либо подключились заново, когда старое соединение ещё не разорвалось. В последнем случае ничего страшного.

MULTI: bad source address from client [::], packet dropped

Вызвано вашими неверными iroute’ами.

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

Вы либо используете неуникальные ключи, либо подключились заново, когда старое соединение ещё не разорвалось. В последнем случае ничего страшного.

ValdikSS ★★★★★
()