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

OpenVPN за шлюзом

 ,


0

1

Доброго времени суток.

Есть сервер выполняющий функцию интернет-раздачи. На этом сервере 2 сетевых интерфейса:
- eth0 - смотрит в локальную сеть. 192.168.1.1 - адрес в локальной сети.
- eth1 - смотрит в интернет с «белым» ip адресом провайдера. ${WAN_IP} - ip адрес провайдера.

Подняли сервер в локальной сети с OpenVPN. 192.168.1.2 - адрес в локальной сети. Из локальной сети подключение к OpenVPN (в качестве теста) успешно устанавливается.

Цель: Подключение к серверу с OpenVPN из сети интернет.

На сервере интернет-раздачи составлены правила переадресации порта на сервер с OpenVPN: 

iptables -t nat -A PREROUTING -d ${WAN_IP} -i eth1 -p udp --dport 1194 -j DNAT --to-destination 192.168.1.2:1194
iptables -t nat -A POSTROUTING -d 192.168.1.2 -p udp --dport 1194 -j SNAT --to-source 192.168.1.1

Но к сожалению подключиться с интернет к OpenVPN не получается. Подскажите в чем ошибка.

Заранее спасибо всем откликнувшимся.

★★★★★

Не уверен, но второе правило по идее не нужно, потому что обычно добавляют правило для всей подсети на замену адреса на 192.168.1.1 при обращении к WAN из LAN.

(время редактирования закончилось)

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

На сервере в лог ничего не попадает, так как туда запрос не попал. А на клиенте в логах интересная фигня: 

Wed Sep 04 18:56:08 2019 read UDP: Unknown error (code=10054)

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

Клиент на Win10x64. Весь лог на клиенте: 

Wed Sep 04 18:56:02 2019 OpenVPN 2.4.7 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Apr 25 2019
Wed Sep 04 18:56:02 2019 Windows version 6.2 (Windows 8 or greater) 64bit
Wed Sep 04 18:56:02 2019 library versions: OpenSSL 1.1.0j  20 Nov 2018, LZO 2.10
Wed Sep 04 18:56:02 2019 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340
Wed Sep 04 18:56:02 2019 Need hold release from management interface, waiting...
Wed Sep 04 18:56:03 2019 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340
Wed Sep 04 18:56:03 2019 MANAGEMENT: CMD 'state on'
Wed Sep 04 18:56:03 2019 MANAGEMENT: CMD 'log all on'
Wed Sep 04 18:56:03 2019 MANAGEMENT: CMD 'echo all on'
Wed Sep 04 18:56:03 2019 MANAGEMENT: CMD 'bytecount 5'
Wed Sep 04 18:56:03 2019 MANAGEMENT: CMD 'hold off'
Wed Sep 04 18:56:03 2019 MANAGEMENT: CMD 'hold release'
Wed Sep 04 18:56:08 2019 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Sep 04 18:56:08 2019 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Sep 04 18:56:08 2019 TCP/UDP: Preserving recently used remote address: [AF_INET]*.*.*.*:1194
Wed Sep 04 18:56:08 2019 Socket Buffers: R=[65536->65536] S=[65536->65536]
Wed Sep 04 18:56:08 2019 UDP link local: (not bound)
Wed Sep 04 18:56:08 2019 UDP link remote: [AF_INET]*.*.*.*:1194
Wed Sep 04 18:56:08 2019 MANAGEMENT: >STATE:1567605368,WAIT,,,,,,
Wed Sep 04 18:56:08 2019 read UDP: Unknown error (code=10054)
Wed Sep 04 18:56:10 2019 read UDP: Unknown error (code=10054)
Wed Sep 04 18:56:15 2019 read UDP: Unknown error (code=10054)
Wed Sep 04 18:56:23 2019 read UDP: Unknown error (code=10054)
Wed Sep 04 18:56:39 2019 read UDP: Unknown error (code=10054)
Wed Sep 04 18:57:08 2019 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Wed Sep 04 18:57:08 2019 TLS Error: TLS handshake failed
Wed Sep 04 18:57:08 2019 SIGUSR1[soft,tls-error] received, process restarting
Wed Sep 04 18:57:08 2019 MANAGEMENT: >STATE:1567605428,RECONNECTING,tls-error,,,,,
Wed Sep 04 18:57:08 2019 Restart pause, 5 second(s)
Wed Sep 04 18:57:13 2019 TCP/UDP: Preserving recently used remote address: [AF_INET]*.*.*.*:1194
Wed Sep 04 18:57:13 2019 Socket Buffers: R=[65536->65536] S=[65536->65536]
Wed Sep 04 18:57:13 2019 UDP link local: (not bound)
Wed Sep 04 18:57:13 2019 UDP link remote: [AF_INET]*.*.*.*:1194
Wed Sep 04 18:57:13 2019 MANAGEMENT: >STATE:1567605433,WAIT,,,,,,
Wed Sep 04 18:57:13 2019 read UDP: Unknown error (code=10054)
Wed Sep 04 18:57:16 2019 read UDP: Unknown error (code=10054)
Wed Sep 04 18:57:20 2019 read UDP: Unknown error (code=10054)
Wed Sep 04 18:57:28 2019 read UDP: Unknown error (code=10054)
Wed Sep 04 18:57:44 2019 read UDP: Unknown error (code=10054)

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

Лог при успешном подключении с клиента из локальной сети. Клиент на Win10x64. 

Wed Sep 04 19:01:58 2019 OpenVPN 2.4.7 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Apr 25 2019
Wed Sep 04 19:01:58 2019 Windows version 6.2 (Windows 8 or greater) 64bit
Wed Sep 04 19:01:58 2019 library versions: OpenSSL 1.1.0j  20 Nov 2018, LZO 2.10
Wed Sep 04 19:01:58 2019 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340
Wed Sep 04 19:01:58 2019 Need hold release from management interface, waiting...
Wed Sep 04 19:01:59 2019 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340
Wed Sep 04 19:01:59 2019 MANAGEMENT: CMD 'state on'
Wed Sep 04 19:01:59 2019 MANAGEMENT: CMD 'log all on'
Wed Sep 04 19:01:59 2019 MANAGEMENT: CMD 'echo all on'
Wed Sep 04 19:01:59 2019 MANAGEMENT: CMD 'bytecount 5'
Wed Sep 04 19:01:59 2019 MANAGEMENT: CMD 'hold off'
Wed Sep 04 19:01:59 2019 MANAGEMENT: CMD 'hold release'
Wed Sep 04 19:01:59 2019 WARNING: --ns-cert-type is DEPRECATED.  Use --remote-cert-tls instead.
Wed Sep 04 19:02:03 2019 MANAGEMENT: CMD 'password [...]'
Wed Sep 04 19:02:03 2019 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Wed Sep 04 19:02:03 2019 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Sep 04 19:02:03 2019 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Sep 04 19:02:03 2019 TCP/UDP: Preserving recently used remote address: [AF_INET]192.168.1.2:1194
Wed Sep 04 19:02:03 2019 Socket Buffers: R=[65536->65536] S=[65536->65536]
Wed Sep 04 19:02:03 2019 UDP link local: (not bound)
Wed Sep 04 19:02:03 2019 UDP link remote: [AF_INET]192.168.1.2:1194
Wed Sep 04 19:02:03 2019 MANAGEMENT: >STATE:1567605723,WAIT,,,,,,
Wed Sep 04 19:02:03 2019 MANAGEMENT: >STATE:1567605723,AUTH,,,,,,
Wed Sep 04 19:02:03 2019 TLS: Initial packet from [AF_INET]192.168.1.2:1194, sid=38affa9f 44fe83f3
Wed Sep 04 19:02:03 2019 VERIFY OK: depth=1, C=RU, ST=56ORB, L=ORENBURG, O=PIROGOVA, OU=PIROGOVA, CN=PIROGOVA CA, name=EasyRSA, emailAddress=uc@orenpirogova.ru
Wed Sep 04 19:02:03 2019 VERIFY OK: nsCertType=SERVER
Wed Sep 04 19:02:03 2019 VERIFY OK: depth=0, C=RU, ST=56ORB, L=ORENBURG, O=PIROGOVA, OU=PIROGOVA, CN=ServerV1, name=EasyRSA, emailAddress=uc@orenpirogova.ru
Wed Sep 04 19:02:03 2019 Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
Wed Sep 04 19:02:03 2019 [ServerV1] Peer Connection Initiated with [AF_INET]192.168.1.2:1194
Wed Sep 04 19:02:05 2019 MANAGEMENT: >STATE:1567605725,GET_CONFIG,,,,,,
Wed Sep 04 19:02:05 2019 SENT CONTROL [ServerV1]: 'PUSH_REQUEST' (status=1)
Wed Sep 04 19:02:05 2019 PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,dhcp-options DNS 8.8.8.8,route 192.168.230.1,topology net30,ping 10,ping-restart 120,ifconfig 192.168.230.6 192.168.230.5,peer-id 1,cipher AES-256-GCM'
Wed Sep 04 19:02:05 2019 Options error: Unrecognized option or missing or extra parameter(s) in [PUSH-OPTIONS]:2: dhcp-options (2.4.7)
Wed Sep 04 19:02:05 2019 OPTIONS IMPORT: timers and/or timeouts modified
Wed Sep 04 19:02:05 2019 OPTIONS IMPORT: --ifconfig/up options modified
Wed Sep 04 19:02:05 2019 OPTIONS IMPORT: route options modified
Wed Sep 04 19:02:05 2019 OPTIONS IMPORT: peer-id set
Wed Sep 04 19:02:05 2019 OPTIONS IMPORT: adjusting link_mtu to 1625
Wed Sep 04 19:02:05 2019 OPTIONS IMPORT: data channel crypto options modified
Wed Sep 04 19:02:05 2019 Data Channel: using negotiated cipher 'AES-256-GCM'
Wed Sep 04 19:02:05 2019 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Wed Sep 04 19:02:05 2019 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Wed Sep 04 19:02:05 2019 interactive service msg_channel=672
Wed Sep 04 19:02:05 2019 ROUTE_GATEWAY 192.168.6.100/255.255.255.0 I=3 HWADDR=1c:1b:0d:4c:d3:74
Wed Sep 04 19:02:05 2019 open_tun
Wed Sep 04 19:02:05 2019 TAP-WIN32 device [Ethernet 3] opened: \\.\Global\{4FBEC1A0-1E39-4357-B9D9-53032CDA5A57}.tap
Wed Sep 04 19:02:05 2019 TAP-Windows Driver Version 9.23 
Wed Sep 04 19:02:05 2019 Notified TAP-Windows driver to set a DHCP IP/netmask of 192.168.230.6/255.255.255.252 on interface {4FBEC1A0-1E39-4357-B9D9-53032CDA5A57} [DHCP-serv: 192.168.230.5, lease-time: 31536000]
Wed Sep 04 19:02:05 2019 Successful ARP Flush on interface [9] {4FBEC1A0-1E39-4357-B9D9-53032CDA5A57}
Wed Sep 04 19:02:05 2019 MANAGEMENT: >STATE:1567605725,ASSIGN_IP,,192.168.230.6,,,,
Wed Sep 04 19:02:10 2019 TEST ROUTES: 2/2 succeeded len=1 ret=1 a=0 u/d=up
Wed Sep 04 19:02:10 2019 C:\Windows\system32\route.exe ADD 192.168.1.2 MASK 255.255.255.255 192.168.6.100
Wed Sep 04 19:02:10 2019 Route addition via service succeeded
Wed Sep 04 19:02:10 2019 C:\Windows\system32\route.exe ADD 0.0.0.0 MASK 128.0.0.0 192.168.230.5
Wed Sep 04 19:02:10 2019 Route addition via service succeeded
Wed Sep 04 19:02:10 2019 C:\Windows\system32\route.exe ADD 128.0.0.0 MASK 128.0.0.0 192.168.230.5
Wed Sep 04 19:02:10 2019 Route addition via service succeeded
Wed Sep 04 19:02:10 2019 MANAGEMENT: >STATE:1567605730,ADD_ROUTES,,,,,,
Wed Sep 04 19:02:10 2019 C:\Windows\system32\route.exe ADD 192.168.230.1 MASK 255.255.255.255 192.168.230.5
Wed Sep 04 19:02:10 2019 Route addition via service succeeded
Wed Sep 04 19:02:10 2019 Initialization Sequence Completed
Wed Sep 04 19:02:10 2019 MANAGEMENT: >STATE:1567605730,CONNECTED,SUCCESS,192.168.230.6,192.168.1.2,1194,,

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

В конфиге на сервере интернет-раздачи присутствует (и присутствовало) правило: 

iptables -A INPUT -i eth1 -p udp --dport 1194 -j ACCEPT

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

Присутствуют.

Приведу все правила iptables, что бы было понятно:

iptables -t nat -A PREROUTING -d ${WAN_IP} -i eth1 -p udp --dport 1194 -j DNAT --to-destination 192.168.1.2:1194
iptables -t nat -A POSTROUTING -d 192.168.1.2 -p udp --dport 1194 -j SNAT --to-source 192.168.1.1

iptables -A INPUT -i eth1 -p udp --dport 1194 -j ACCEPT
iptables -A FORWARD -i eth1 -p udp --dport 1194 -j ACCEPT
iptables -A FORWARD -s 192.168.1.2 -i eth0 -p udp --sport 1194 -j ACCEPT
iptables -t nat -A OUTPUT -d ${WAN_IP} -j DNAT --to-destination 192.168.1.2 -p udp --dport 1194

Еще раз. Возможно я где то допустил ошибку, поэтому прошу помощи.

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

1.
iptables -t nat -A POSTROUTING -d 192.168.1.2 -p udp --dport 1194 -j SNAT --to-source 192.168.1.1
Если с локалки на внешний адрес соединяться не нужно, то это правило не нужно.
2.
iptables -A INPUT -i eth1 -p udp --dport 1194 -j ACCEPT
Не нужно
3.
iptables -t nat -A OUTPUT -d ${WAN_IP} -j DNAT --to-destination 192.168.1.2 -p udp --dport 1194
Не нужно.
4.
iptables -A FORWARD -s 192.168.1.2 -i eth0 -p udp --sport 1194 -j ACCEPT
Непонятно зачем, но пусть будет.

В остальном все верно.

А теперь самое главное. Это же не все ваши правила? Дропать может правило выше.

ЗЫ Ну и не часто встречающийся случай, дропает пров, что бы исключить этот вариант запустите tcpdump на роутере и посмотрите долетают ли пакеты.

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

Ни одного правила DROP нет. Все убрал. И соединение не идет. Что то еще должно быть, как мне кажется. tcpdump сейчас попробую.

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

tcpdump молчит.

Ну значит пров. Меняйте порт/протокол по вкусу, что заработает.

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

Неверно. В tcpdump прилетевший пакет вы увидите, в не зависимости от правил. А ТС написал что «tcpdump молчит». Значит пакеты даже не долетают.

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

Для полноты картины хотелось бы знать как ТС tcpdump смотрит. Хотя вот правила посмотрел, вроде легально выглядят.

turtle_bazon ★★★★★
()
Последнее исправление: turtle_bazon (всего исправлений: 1)

блэт, мужики. т.е. бред сивой кобылы всем как бы пофиг?

iptables -t nat -A PREROUTING -d ${WAN_IP} -i eth1 -p udp --dport 1194 -j DNAT --to-destination 192.168.1.2:1194
iptables -t nat -A POSTROUTING -d 192.168.1.2 -p udp --dport 1194 -j SNAT --to-source 192.168.1.1

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

Поясните свой негодуй плиз. Может действительно что-то не замечаем.
Хотяяя в чем-то вы правы, внимательно присмотревшись про второе правило к своему предыдущему комментарию я бы добавил, что оно однозначно не нужное в любом случае.

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

блэт. оно не ненужное! оно ломает все. куда полетит пакет ответный от 192.168.1.2??? @ полетит на 192.168.1.1:1194 @ что блэт там по этому назначению?

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

мое разумение: 1. iptables -t nat -A PREROUTING -i eth1 -p udp --dport 1194 -j DNAT --to-destination 192.168.1.2:1194

2. iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE

все. ну второе можно и даже нужно так:

2. iptables -t nat -A POSTROUTING -o eth1 -p udp --sport 1194 -j SNAT --to-source WAN-блэт-IP:1194

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

Ну во-первых нет

куда полетит пакет ответный от 192.168.1.2??? @ полетит на 192.168.1.1:1194 @

Точнее возможно, но только при случае если и исходный был тоже с 1194.

Во-вторых. Давайте рассмотрим все цепочки.
Первое правило

iptables -t nat -A PREROUTING -d ${WAN_IP} -i eth1 -p udp --dport 1194 -j DNAT --to-destination 192.168.1.2:1194

Изменит dst ip с ${WAN_IP} на 192.168.1.2

Второе правило

iptables -t nat -A POSTROUTING -d 192.168.1.2 -p udp --dport 1194 -j SNAT --to-source 192.168.1.1

Изменит src ip.

Предполагаем что ${WAN_IP} это 1.1.1.1 а адрес клиента 2.2.2.2. После прохождения первого правила у нас получилось src 2.2.2.2 dst 192.168.1.2
После второго правила
src 192.168.1.1 dst 192.168.1.2

Но так как это(192.168.1.1) роутер, ответ вернется на него, и будет обратное преобразование.

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

Пункты 2(два) не нужны. Уже попало в conntrack так что обратное преобразование будет выполнено.

anc ★★★★★
()

В общем, причину нашел. Вся проблема в провайдере. Блочат порт. То работает, то не работает.

Сменил пор на нестандартный. Все теперь работает. Всем спасибо за помощь. Лишние правила удалил.

ivanlex ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
Admin