LINUX.ORG.RU
ФорумAdmin

Openvpn разрывает соединение при подключении к клиенту по tcp

 , ,


0

2

Добрый день. Есть openvpn сервер к нему подключаются клиенты и всё отлично работает, но если из подсети за сервером подключиться к клиенту по rdp или чем угодно работающем по tcp после секунд 40-ка соединение разрывается. Потом переподключается и опять в течении минуты всё норм и потом разрыв. В логах ни на сервере ни на клиенте ничего нет. Вот мой конфиг :


port 1194
proto udp
dev tun0
management 192.168.1.1 7505
ca /etc/openvpn/ca.crt
cert /etc/openvpn/server.crt
key /etc/openvpn/server.key
dh /etc/openvpn/dh1024.pem
crl-verify /etc/openvpn/crl.pem
server 60.50.40.0 255.255.255.0
sndbuf 0
rcvbuf 0
push "sndbuf 393216"
push "rcvbuf 393216"
push "dhcp-option DNS 10.3.1.1"
push "route 192.168.0.0 255.255.0.0"
client-config-dir ccd
client-to-client
route 60.50.40.0 255.255.255.252
route 10.1.0.0  255.255.0.0
route 10.2.0.0  255.255.0.0
auth MD5 #
cipher BF-CBC
keepalive 10 120
max-clients 250
tun-mtu 1500
persist-key
persist-tun
status /var/log/openvpn-status.log
log /var/log/openvpn.log
verb 3
tcp-nodelay


nc тоже так себя ведёт?

Попробуй nc и если воспроизведётся сними дамп. Так нифига не понятно даже кто коннект рвёт?

Есть идея - mtu не совпадает в сетях а фрагментация вырублена.

pon4ik ★★★★★
()

tun-mtu 1500
sndbuf
rcvbuf

попробуй закомментировать это везде ( в опциях push тоже).

Deleted
()

Сейчас куча пользователей сидит вечером отпишусь по результатам.

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

Сейчас куча пользователей сидит

И терпит боль.

Ну и это, песочницу бы хорошо иметь раз куча пользователей сидит.

pon4ik ★★★★★
()

Существует параллельная площадка с теми же конфигами и всё работает. Из чего был сделан вывод , что всё стабильно. А эта проблема вылезла на днях. И приходиться её решать в ночное время

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

Отключение параметров ничего не дало. NC не рвёт соединение и всё нормально работает. Импирически выяснил что , из под Linux c гуём в Remmine с rdp сессией всё нормально. Соответсвенно дело всё таки в windows 2012 hyperv и их настройкой . Хотя ума не приложу куда начинать копать .

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

NC не рвёт соединение и всё нормально работает

данные - ты конечно же передавал?

Это я к тому, что просто поддержание коннекта всяко уместится в mtu.

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

И копировал файлики и bash запускал и чатик устраивал и нифига. Посоветуй как лучше его пригрузить?

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

Вот дамп при разрыве :

18:23:43.782754 IP 10.3.1.11.64349 > 10.1.1.9.3389: Flags [.], ack 95803, win 64531, length 0
18:23:43.782840 IP 10.3.1.11.64349 > 10.1.1.9.3389: Flags [.], ack 95973, win 64361, length 0
18:23:43.784185 IP 10.3.1.11.64349 > 10.1.1.9.3389: Flags [.], ack 99545, win 64073, length 0
18:23:43.786918 IP 10.1.1.9.3389 > 10.3.1.11.64349: Flags [.], ack 80179, win 63240, length 0
18:23:43.787092 IP 10.1.1.9.3389 > 10.3.1.11.49521: UDP, length 105
18:23:43.787311 IP 10.1.1.9.3389 > 10.3.1.11.49521: UDP, length 89
18:23:43.787870 IP 10.1.1.9.3389 > 10.3.1.11.64349: Flags [.], ack 80381, win 63038, length 0
18:23:43.788004 IP 10.3.1.11.49521 > 10.1.1.9.3389: UDP, length 89
18:23:43.802006 IP 10.1.1.9.3389 > 10.3.1.11.64349: Flags [.], ack 80567, win 62852, length 0
18:23:43.804353 IP 10.1.1.9.3389 > 10.3.1.11.64349: Flags [.], ack 80753, win 62666, length 0
18:23:43.804531 IP 10.1.1.9.3389 > 10.3.1.11.64349: Flags [.], ack 80955, win 64000, length 0
18:23:43.852290 IP 10.3.1.11.49521 > 10.1.1.9.3389: UDP, length 1218
18:23:43.852318 IP 10.3.1.11.49521 > 10.1.1.9.3389: UDP, length 1218
18:23:43.852325 IP 10.3.1.11.49521 > 10.1.1.9.3389: UDP, length 914
18:23:43.856593 IP 10.3.1.11.49521 > 10.1.1.9.3389: UDP, length 105
18:23:43.874499 IP 10.1.1.9.3389 > 10.3.1.11.49521: UDP, length 105
18:23:43.874676 IP 10.1.1.9.3389 > 10.3.1.11.49521: UDP, length 137
18:23:43.875342 IP 10.3.1.11.49521 > 10.1.1.9.3389: UDP, length 12
18:23:43.875534 IP 10.3.1.11.49521 > 10.1.1.9.3389: UDP, length 105
18:23:43.875934 IP 10.1.1.9.3389 > 10.3.1.11.49521: UDP, length 12
18:23:43.876418 IP 10.1.1.9.3389 > 10.3.1.11.49521: UDP, length 12
18:23:43.877090 IP 10.1.1.9.3389 > 10.3.1.11.49521: UDP, length 425
18:23:44.058041 IP 10.3.1.11.49521 > 10.1.1.9.3389: UDP, length 12
18:23:44.110044 IP 10.1.1.9.3389 > 10.3.1.11.49521: UDP, length 12
18:23:44.136869 IP 10.3.1.11.64349 > 10.1.1.9.3389: Flags [P.], seq 80955:81040, ack 99747, win 63871, length 85
18:23:44.206106 IP 10.1.1.9.3389 > 10.3.1.11.64349: Flags [.], ack 81040, win 63915, length 0
18:23:45.879358 IP 10.1.1.9.3389 > 10.3.1.11.64349: Flags [P.], seq 99747:99832, ack 81040, win 63915, length 85
18:23:45.933982 IP 10.3.1.11.64349 > 10.1.1.9.3389: Flags [.], ack 99832, win 63786, length 0

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

Проблема решилась , как я и предполагал . Дело было в Hyperv и настройке сети Large Send Offload была включена и она имела мозги . Спасибо за советы.

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

Если файлики копировал, то видимо всё ок, я не уверен что nc должен делать что-то круче чем пихать в сокет пока дают.

pon4ik ★★★★★
()

Просто начал смотреть до впн чего происходит. Теперь другая фигня . На одном гипервизоре работает и всё ок на другом та же проблема осталась. Вот ищу чего дальше можно сделать.

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