OpenVPN обрывает TCP соединения в туннеле

01.07.2013 02:11 #326823

Доброго времени суток!
У меня возникла довольно странная проблема:
У меня на сервере (ubuntu) стоит OpenVPN(уже год как), все работало отлично, но недавно OVPN сервер стал обрывать соединения внутри туннеля, как я понял только TCP, при условии что через соединение передается пакет данных примерно более 0.5КБайт, при этом туннель не обрывается, и UDP соединения работают так как и должны.

Примеры:

Показать

SSH через OVPN
пишем в консоль любую команду которая влечет за собой короткий ответ в консоль(строчек до 5), все работает
стоит открыть в консоль catом какой нибудь более или менее длинный файл или открыть например nano, mc, lsнуть какую нибудь большую папку, как консоль виснет и через некоторое время клиент сообщает об обрыве соединения.
Кидаем через SFTP файл байт на 300 пролетает в обе стороны сколько угодно, стоит кинуть хотябы килобайт, он посередине шкалы виснет и опять же дисконнект SSH, при этом туннель живет.
Открываем порт SSH наружу и коннектимся мимо OVPN все прекрасно

HTTP (внутреконторская база с php интерфейсом)
Открываем страничку прилетает макушка и далее бесконечное ожидание продолжения странички в браузере
Открываем порт наружу, мимо OVPN все открывается прекрасно

SAMBA
Открываем папку в которой мало файлов - открывается, можно туда/обратно кинуть мелкий файл как через SFTP, стоит хотябы открыть папку в которой много файлов - можно сразу килять проводник.
Наружу открывать не пробовал...

Во внутренней сети конторы, в которую прокинут маршрут, есть вечно включенный мой комп(винда), на нем есть расшареные папки и VNC сервер. Сквозь OVPN->маршрут на серве->сетку я могу проконнектиться из дома на свой рабочий комп. С расшаренными папками точно такая же история как на сервере, а вот VNC ходит без проблем, подчеркну что туда можно долезть только через OVPN(не каких внешек), и работает)))

Отличия WinShare/Samba, HTTP, SSH(+SFTP) от VNC пожалуй только в том что VNC ходит UDP протоколом а остальные TCP, из этого я сделал вывод, что рвутся именно TCP соединения.

Конфиг OpenVPN сервера

Показать

proto udp
port xxxx

ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/server.crt
key /etc/openvpn/keys/server.key
dh /etc/openvpn/keys/dh1024.pem
crl-verify /etc/openvpn/keys/crl.pem

dev tap
mode server
tls-server
ifconfig 192.168.20.1 255.255.255.0
ifconfig-pool 192.168.20.2 192.168.20.99
route 192.168.0.0 255.255.255.0
push "route 192.168.0.0 255.255.255.0 192.168.20.1"
push "dhcp-option DNS 192.168.20.1"
client-config-dir /etc/openvpn/ips

client-to-client
keepalive 10 60
comp-lzo
status /var/log/ovpn-st
verb 3
log-append /var/log/openvpn.log

В логах OpenVPN ничего криминального не увидел (там есть только когда кто прицепился и когда кто отцепился)
В логах Апача к примеру написано что он успешно выполняет все запросы...

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

Что скажите господа эксперты?

01.07.2013 16:40 #326876

Хотелось бы посмотреть на tcpdump log соединения с разрывом.

02.07.2013 01:14 · отредактировано #326921

Вот дамп повисшего SSH соединения, с момента нажатия на SSH клиенте Login, до момента когда SSH клиент сообщил о разрыве связи.
Дамп снимался с tap0, все лишнее, чтобы не мешало эксперементу было выключено, порт SSH в логе поменен на 22(чтоб ни кого не смущал)

Показать

01:05:03.935207 IP 192.168.20.8.3635 > server.22: Flags [S], seq 620832923, win 16384, options [mss 1336,nop,nop,sackOK], length 0
01:05:03.935332 IP server.22 > 192.168.20.8.3635: Flags [S.], seq 1039527691, ack 620832924, win 5840, options [mss 1460,nop,nop,sackOK], length 0
01:05:03.947106 IP 192.168.20.8.3635 > server.22: Flags [.], ack 1, win 17368, length 0
01:05:03.954216 IP 192.168.20.8.3635 > server.22: Flags [P.], seq 1:38, ack 1, win 17368, length 37
01:05:03.954254 IP server.22 > 192.168.20.8.3635: Flags [.], ack 38, win 5840, length 0
01:05:03.954300 IP 192.168.20.8.3635 > server.22: Flags [P.], seq 38:718, ack 1, win 17368, length 680
01:05:03.954315 IP server.22 > 192.168.20.8.3635: Flags [.], ack 718, win 6800, length 0
01:05:03.957765 IP server.22 > 192.168.20.8.3635: Flags [P.], seq 1:40, ack 718, win 6800, length 39
01:05:04.111203 IP 192.168.20.8.3635 > server.22: Flags [.], ack 40, win 17329, length 0
01:05:04.111255 IP server.22 > 192.168.20.8.3635: Flags [P.], seq 40:824, ack 718, win 6800, length 784
01:05:04.131104 IP 192.168.20.8.3635 > server.22: Flags [P.], seq 718:990, ack 824, win 16545, length 272
01:05:04.170031 IP server.22 > 192.168.20.8.3635: Flags [.], ack 990, win 8160, length 0
01:05:04.219523 IP server.22 > 192.168.20.8.3635: Flags [P.], seq 824:1672, ack 990, win 8160, length 848
01:05:04.231094 IP 192.168.20.8.3635 > server.22: Flags [P.], seq 990:1058, ack 1672, win 17368, length 68
01:05:04.231131 IP server.22 > 192.168.20.8.3635: Flags [.], ack 1058, win 8160, length 0
01:05:04.231228 IP server.22 > 192.168.20.8.3635: Flags [P.], seq 1672:1724, ack 1058, win 8160, length 52
01:05:04.238709 IP 192.168.20.8.3635 > server.22: Flags [P.], seq 1058:1418, ack 1724, win 17316, length 360
01:05:04.282030 IP server.22 > 192.168.20.8.3635: Flags [.], ack 1418, win 9520, length 0
01:05:04.365469 IP server.22 > 192.168.20.8.3635: Flags [P.], seq 1724:1760, ack 1418, win 9520, length 36
01:05:04.387228 IP 192.168.20.8.3635 > server.22: Flags [P.], seq 1418:1554, ack 1760, win 17280, length 136
01:05:04.387282 IP server.22 > 192.168.20.8.3635: Flags [.], ack 1554, win 10880, length 0
01:05:04.420446 IP server.22 > 192.168.20.8.3635: Flags [P.], seq 1760:1864, ack 1554, win 10880, length 104
01:05:04.427109 IP 192.168.20.8.3635 > server.22: Flags [P.], seq 1554:1758, ack 1864, win 17176, length 204
01:05:04.430075 IP server.22 > 192.168.20.8.3635: Flags [P.], seq 1864:2076, ack 1758, win 12240, length 212
01:05:04.434468 IP server.22 > 192.168.20.8.3635: Flags [P.], seq 2076:2432, ack 1758, win 12240, length 356
01:05:04.443221 IP 192.168.20.8.3635 > server.22: Flags [P.], seq 1758:1810, ack 2076, win 16964, length 52
01:05:04.443545 IP server.22 > 192.168.20.8.3635: Flags [P.], seq 2432:2580, ack 1810, win 12240, length 148
01:05:04.451128 IP 192.168.20.8.3635 > server.22: Flags [.], ack 2580, win 16460, length 0
01:05:04.658189 IP 192.168.20.8.3635 > server.22: Flags [P.], seq 1810:1862, ack 2580, win 16460, length 52
01:05:04.658482 IP server.22 > 192.168.20.8.3635: Flags [P.], seq 2580:2680, ack 1862, win 12240, length 100
01:05:04.683233 IP 192.168.20.8.3635 > server.22: Flags [P.], seq 1862:1930, ack 2680, win 16360, length 68
01:05:04.683709 IP server.22 > 192.168.20.8.3635: Flags [P.], seq 2680:2748, ack 1930, win 12240, length 68
01:05:04.699197 IP 192.168.20.8.3635 > server.22: Flags [P.], seq 1930:2030, ack 2748, win 16292, length 100
01:05:04.700455 IP server.22 > 192.168.20.8.3635: Flags [.], seq 2748:4084, ack 2030, win 12240, length 1336
01:05:04.700480 IP server.22 > 192.168.20.8.3635: Flags [P.], seq 4084:4336, ack 2030, win 12240, length 252
01:05:04.707176 IP 192.168.20.8.3635 > server.22: Flags [.], ack 2748, win 16292, options [nop,nop,sack 1 {4084:4336}], length 0
01:05:05.058064 IP server.22 > 192.168.20.8.3635: Flags [.], seq 2748:4084, ack 2030, win 12240, length 1336
01:05:05.766040 IP server.22 > 192.168.20.8.3635: Flags [.], seq 2748:4084, ack 2030, win 12240, length 1336
01:05:07.194038 IP server.22 > 192.168.20.8.3635: Flags [.], seq 2748:4084, ack 2030, win 12240, length 1336
01:05:07.346618 IP 192.168.20.8.3635 > server.22: Flags [P.], seq 2030:2098, ack 2748, win 16292, length 68
01:05:07.390032 IP server.22 > 192.168.20.8.3635: Flags [.], ack 2098, win 12240, length 0
01:05:09.099137 IP 192.168.20.8.3635 > server.22: Flags [P.], seq 2098:2150, ack 2748, win 16292, length 52
01:05:09.099230 IP server.22 > 192.168.20.8.3635: Flags [.], ack 2150, win 12240, length 0
01:05:10.046044 IP server.22 > 192.168.20.8.3635: Flags [.], seq 2748:4084, ack 2150, win 12240, length 1336
01:05:15.750037 IP server.22 > 192.168.20.8.3635: Flags [.], seq 2748:4084, ack 2150, win 12240, length 1336
01:05:27.162039 IP server.22 > 192.168.20.8.3635: Flags [.], seq 2748:4084, ack 2150, win 12240, length 1336
01:05:31.126041 IP server.22 > 192.168.20.8.3585: Flags [.], seq 3110679558:3110680894, ack 1054228930, win 12240, length 1336
01:05:50.006045 IP server.22 > 192.168.20.8.3635: Flags [.], seq 2748:4084, ack 2150, win 12240, length 1336
01:05:55.014028 ARP, Request who-has 192.168.20.8 tell 192.168.20.1, length 28
01:05:55.019099 ARP, Reply 192.168.20.8 is-at 00:ff:c7:e5:09:ad (oui Unknown), length 28

пологаю проблема как то связана с последними 2мя строчками лога?

02.07.2013 02:03 #326922

Они связаны, только если у вас в openvpn-сети два одинаковых ip есть =).

02.07.2013 07:45 · отредактировано #326925

elve написал:
Они связаны, только если у вас в openvpn-сети два одинаковых ip есть =).

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

Но тогда как я понимаю все получается как бы прекрасно: запрос получен, на него отправлен ряд ответов, а больше запросов как будто и не приходило. На месте конца выложенного лога все виснет(хотя должно продолжаться), и примерно через минуту клиент говорит о разрыве связи, при этом в логе ничего уже не появляется.

02.07.2013 10:54 #326942

Тогда смотрите параллельно еще и лог openvpn предварительно увеличив verbose

02.07.2013 12:44 #326958

А ip сервера это 192.168.20.1?

02.07.2013 22:38 #327012

Macumazan написал:
А ip сервера это 192.168.20.1?

IP сервера на котором открыты все нужные порты (HTTP SSH SAMBA...) 192.168.0.1 и смотрит он в локальную сеть конторы, IP интерфейса tap0 192.168.20.1 и все клиенты OVPN получают адреса из пулла 192.168.20.2-192.168.20.99 (это должно быть видно из конфига).
Так же из конфига должно быть видно, что на сервер добавляется маршрут из 192.168.0 в 192.168.20, и клиентам передается маршрут из 192.168.20 в 192.168.0 и с маршрутами там все ровно они работают. Я по ним хожу с домашнего компа через серв на любой комп на работе (чаще на свой), и со своего рабочего компа на свой домашний(так же сквозь серв и OVPN туннель), и как я уже говорил VNC через эти маршруты ходит в обе стороны, на серве VNC не могу поднять для проверки там ток консоль.
И еще повторюсь оно все работало идеально целый год, и из за чего вдруг стало траффик заваливать при чем не весь, я даж предположить не могу(вроде ниче не ставил, не обновлял)

03.07.2013 11:14 #327064

ssh сессия на 192.168.20.1 и на 192.168.0.1 ведет себя одинаково?
Вторая мысль: в момент активной сессии arp запись, соответствующая ip 192.168.20.8 на сервере vpn не может исчезнуть в никуда.
Этот лог

text

 ARP, Request who-has 192.168.20.8 tell 192.168.20.1, length 28

говорит о том, что запись все же пропала. Что похоже на разрыв vpn соединения или его переинициализацию.

04.07.2013 09:57 #327220

на 192.168.20.1 SSH ведет себя точно так же как и на 192.168.0.1
если в это же время параллельно работает VNC сессия на 192.168.0.8 (сквозь сервер на мой раб. комп) у нее даже картинка не останавливается - следовательно OVPN соединение не обрывается