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

openvpn нет соединения сервера с клиентом

 , ,


0

2

Здравствуйте, собственно, все делал по инструкции) ошибок явных не выдает, а подключаться не хочет. В чем может быть проблема? OC Centos 6
Заспойлерить не получилось конфиги и все в 1 строку, хз почему так получилось)
Конфигурация сервера:

port 1194
proto tcp
dev tun0
ca ca.crt
cert server.crt
key server.key
dh dh2048.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push «redirect-gateway def1 bypass-dhcp»
push «dhcp-option DNS 8.8.8.8»
push «dhcp-option DNS 8.8.4.4»
duplicate-cn
keepalive 10 120
comp-lzo
persist-key
persist-tun
status openvpn-status.log
log openvpn.log
log-append openvpn-append.log
verb 9

Конфиг клиента:
client
dev tun0
proto tcp
remote XX.XXX.XXX.XXX 1194 //запись изменил
resolv-retry infinite
nobind
persist-key
persist-tun
comp-lzo
verb 9
ca ca.crt
cert client.crt
key client.key

Конфиг iptables:
# Generated by iptables-save v1.4.7 on Fri Dec 25 13:11:16 2015
*filter
:INPUT ACCEPT [54:3760]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [28:2944]
-A INPUT -i eth0 -p tcp -m state --state NEW -m tcp --dport 1194
-j ACCEPT
-A INPUT -i tun+ -j ACCEPT
-A FORWARD -i tun+ -j ACCEPT
-A FORWARD -i tun+ -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i eth0 -o tun+ -m state --state RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -o tun+ -j ACCEPT
COMMIT
# Completed on Fri Dec 25 13:11:16 2015
# Generated by iptables-save v1.4.7 on Fri Dec 25 13:11:16 2015
*nat
:PREROUTING ACCEPT [2:80]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
-A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
-A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
-A POSTROUTING -o venet0 -j SNAT --to-source XX.XXX.XXX.XXX
-A POSTROUTING -s 10.8.0.0/24 -j SNAT --to-source XX.XXX.XXX.XXX
-A POSTROUTING -o venet0 -j MASQUERADE
-A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
COMMIT
# Completed on Fri Dec 25 13:11:16 2015

В логах на сервере в конце повторяется:
Fri Dec 25 12:11:13 2015 us=917050 MULTI: REAP range 80 -> 96
Fri Dec 25 12:11:13 2015 us=917176 MULTI TCP: multi_tcp_action a=TA_TIMEOUT p=0
Fri Dec 25 12:11:13 2015 us=917203 MULTI TCP: multi_tcp_dispatch a=TA_TIMEOUT mi=0x00000000
Fri Dec 25 12:11:13 2015 us=917231 MULTI TCP: multi_tcp_post TA_TIMEOUT -> TA_UNDEF
Fri Dec 25 12:11:13 2015 us=917254 SCHEDULE: schedule_find_least NULL
Fri Dec 25 12:11:23 2015 us=927430 MULTI: REAP range 96 -> 112
Fri Dec 25 12:11:23 2015 us=927623 MULTI TCP: multi_tcp_action a=TA_TIMEOUT p=0
Fri Dec 25 12:11:23 2015 us=927656 MULTI TCP: multi_tcp_dispatch a=TA_TIMEOUT mi=0x00000000
Fri Dec 25 12:11:23 2015 us=927681 MULTI TCP: multi_tcp_post TA_TIMEOUT -> TA_UNDEF
Fri Dec 25 12:11:23 2015 us=927704 SCHEDULE: schedule_find_least NULL

На клиенте:
Fri Dec 25 13:14:11 2015 us=214829 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340
Fri Dec 25 13:14:11 2015 us=214829 WE_CTL n=0 ev=00000000005002A8 rwflags=0x0001 arg=0x0
Fri Dec 25 13:14:11 2015 us=214829 WE_WAIT enter n=1 to=1000
Fri Dec 25 13:14:11 2015 us=214829 [0] ev=00000000000000E0 rwflags=0x0001 arg=0x0
Fri Dec 25 13:14:11 2015 us=215454 WE_WAIT leave rwflags=0x0001 arg=0x0
Fri Dec 25 13:14:11 2015 us=215454 WE_CTL n=0 ev=00000000005002A8 rwflags=0x0001 arg=0x0
Fri Dec 25 13:14:11 2015 us=215454 WE_WAIT enter n=1 to=1000
Fri Dec 25 13:14:11 2015 us=215454 [0] ev=00000000000000E0 rwflags=0x0001 arg=0x0
Fri Dec 25 13:14:11 2015 us=316309 WE_WAIT leave rwflags=0x0001 arg=0x0
Fri Dec 25 13:14:11 2015 us=316309 MANAGEMENT: CMD 'state on'
Fri Dec 25 13:14:11 2015 us=316309 WE_CTL n=0 ev=00000000005002A8 rwflags=0x0001 arg=0x0
Fri Dec 25 13:14:11 2015 us=316309 WE_WAIT enter n=1 to=1000
Fri Dec 25 13:14:11 2015 us=316309 [0] ev=00000000000000E0 rwflags=0x0001 arg=0x0
Fri Dec 25 13:14:11 2015 us=316309 WE_WAIT leave rwflags=0x0001 arg=0x0
Fri Dec 25 13:14:11 2015 us=316309 MANAGEMENT: CMD 'log all on'
Fri Dec 25 13:14:11 2015 us=320104 WE_CTL n=0 ev=00000000005002A8 rwflags=0x0001 arg=0x0
Fri Dec 25 13:14:11 2015 us=320104 WE_WAIT enter n=1 to=1000
Fri Dec 25 13:14:11 2015 us=320104 [0] ev=00000000000000E0 rwflags=0x0001 arg=0x0
Fri Dec 25 13:14:11 2015 us=411206 MANAGEMENT: CMD 'hold off'
Fri Dec 25 13:14:11 2015 us=411206 WE_WAIT leave rwflags=0x0001 arg=0x0
Fri Dec 25 13:14:11 2015 us=411206 WE_CTL n=0 ev=00000000005002A8 rwflags=0x0001 arg=0x0
Fri Dec 25 13:14:11 2015 us=411845 WE_WAIT enter n=1 to=1000
Fri Dec 25 13:14:11 2015 us=411845 [0] ev=00000000000000E0 rwflags=0x0001 arg=0x0
Fri Dec 25 13:14:12 2015 us=412170 WE_CTL n=0 ev=00000000005002A8 rwflags=0x0001 arg=0x0
Fri Dec 25 13:14:12 2015 us=412170 WE_WAIT enter n=1 to=1000
Fri Dec 25 13:14:12 2015 us=412170 [0] ev=00000000000000E0 rwflags=0x0001 arg=0x0
Fri Dec 25 13:14:13 2015 us=412760 WE_CTL n=0 ev=00000000005002A8 rwflags=0x0001 arg=0x0
Fri Dec 25 13:14:13 2015 us=412760 WE_WAIT enter n=1 to=1000
Fri Dec 25 13:14:13 2015 us=412760 [0] ev=00000000000000E0 rwflags=0x0001 arg=0x0
Fri Dec 25 13:14:14 2015 us=413374 WE_CTL n=0 ev=00000000005002A8 rwflags=0x0001 arg=0x0
Fri Dec 25 13:14:14 2015 us=413374 WE_WAIT enter n=1 to=1000
Fri Dec 25 13:14:14 2015 us=413374 [0] ev=00000000000000E0 rwflags=0x0001 arg=0x0
Fri Dec 25 13:14:15 2015 us=413830 WE_CTL n=0 ev=00000000005002A8 rwflags=0x0001 arg=0x0
Fri Dec 25 13:14:15 2015 us=413830 WE_WAIT enter n=1 to=1000 и повторяется пока не остановлю

Ответ на: комментарий от Shakior

cut только в новостях (то что на главной странице) работает. Еще тег code есть, его тоже желательно использовать чтоб местный умный парсер не коверкал код.

А почему время разное на хостах (часы в смысле)? Или действительно был час между получением логов из каждого источника? Вроде какие-то проблемы были с этим связаны.

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

Просто взял где-то более новый лог, где-то старый, но кроме времени, сообщения там идентичны

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

По идее, даже если на сервере пусто, а на клиенте установлен openvpn, то я должен видеть в снифере отправку tcp сообщений с клиента, на тот ip, который я указал в конфиге клиента, так? Но я их не вижу, значит как минимум проблема на клиенте. Верно?

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

Не телнетится к порту 1194. Но пинг есть. Значит на этом порту ничего нет? Как можно из сервера проверить, есть ли на нем что-то?

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

Сейчас уже нет(наверное)) А как проверить? Мне просто дали ip, рут и сказали сделать) А в администрирования я не силен и этим почти никогда не занимался.

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

cat /proc/user_beancounters

Че нить выдает? Если да - то это контейнер, настройка openvpn в контейнере посмотри в инете - она отличается от обычной + 1194 может рубиться на хостовой машине.

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

Как я понял висит openvpn на этом порту
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:1194 0.0.0.0:* LISTEN 31512/openvpn

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

Да. Тогда обращайся к админам своей сети чтоб проверили - может там какая-то хитрая политика безопасности, наты, вот это все.

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

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 52:54:00:7d:62:6b brd ff:ff:ff:ff:ff:ff
35: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100 link/[65534]

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

-A POSTROUTING -o venet0 -j SNAT --to-source XX.XXX.XXX.XXX

странное правило

погаси iptables - service iptables stop

и попробуй подконнектится telnet-ом или клиентом

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

-A POSTROUTING -o venet0 -j SNAT --to-source XX.XXX.XXX.XXX — где-то нашел типа может помочь(не помогло, ip я иксами тут заменил)
По поводу телнета: на порт 23 - ошибка, на порт 1194 Putty просто сворачивается.
Microsoft Telnet на оба порта сбой
С клиентом без изменений, крутит тот же лог

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

2-35 tun0 несколько раз исчезал, возможно, когда появлялся его номер увеличивался)

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

так стоп

клиент на винде?

пропиши полные пути к сертификатам типа ca «C:\\OpenVPN\\ssl\\ca.crt» - как то так (винды под рукой нет)

http://www.odmin4eg.ru/2010/openvpn-win-klient-openvpn-windows-client/

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

Клиент на винде, абсолютные пути ничего не изменили. Снифер во время подключения должен показывать что пакеты на ip сервера идут?

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

Спасибо. Попробую на виртуальной машине сделать сервер, и буду к ней конектиться. Если получится буду что-то решать.

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

Снифер во время подключения должен показывать что пакеты на ip сервера идут?

Да должен.

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

В общем случае на сервере и на клиенте вывод о поступающих пакетах должен совпадать. Если это не так, то что-то стоит по середине и это что-то мешает. Ну либо фаерволы проверь по обоим концам (на клиенте и на сервере).

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

Сервер у тебя стоит за натом? Если -да, то на сервере с натом делай проброс внутрь. Если - нет, то это правило бесполезно.

dmnord ()

Решилось следующим образом: был взят новый конфиг для сервера и новый для клиента, причем визуально для клиента нет никаких изменений, но при запуске нового - работает, при запуске старого - нет)

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

визуально

Ну так diff'ом проверь. И серверный тоже. Интересно же в чем проблема была.

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