Wi-CAT LLC

Wireless Comprehensive Advanced Technology. Build your network now.

Wi-CAT LLC
Навигация Форума
Вы должны войти, чтобы создавать сообщения и темы.

OpenVPN и ошибка 10060

Вчера переехал со старого кинетика на 3.0.12.RU.10122020 / AP-Gateway(Router) / MT7621 CPU, MT7615DN 2T2R DBDC, 1000FDX. Подключение PurePPPoE, Justlan. Настольный комп по LAN гигабит. И сразу же стали происходить реконнекты клиента OpenVPN. Оговорюсь сразу, работаю через этого клиента не меньше пяти лет, сервер в моём городе, почти весь 2020 год клиент не выключался. Ни разу не видел такой причины разрыва соединения. И как только сменил роутер, началось. Через произвольные интервалы времени (иногда 10 минут, иногда 3 часа) происходит переконнект с сервером. В логе OpenVPN примерно следующее:

Thu Dec 10 18:34:56 2020 Initialization Sequence Completed
Thu Dec 10 18:56:40 2020 read TCP_CLIENT: Unknown error (code=10060)
Thu Dec 10 18:56:40 2020 Connection reset, restarting [-1]
Thu Dec 10 18:56:40 2020 SIGUSR1[soft,connection-reset] received, process restarting

Я на сервере не единственный клиент, но реконнекты там только у меня, остальные 50+ клиентов работают без сбоев.

Запускал в фоне пинги до гугла (8.8.8.8) и до собственно сервера с впн, в момент потери соединения пинги не тормозят, как были 22 мс и 1 мс соответственно, так и идут как вкопанные.

В логах роутера в эти моменты ничего нет.

Есть идеи, куда копать и что попробовать? Может какие-то расширенные логи есть? PPPoE посмотреть, например...

Опять вангу звать? Ок. Ванга грит keepalive... Больше ничего не говорит.

Что это за причина мне неведомо, но предполагаю (и ванга согласна) что за 7600с ни одного пакета по соединению не прошло и оно было вынесено из контрака как мёртврое (что верно ибо нафиг память на него тратить ещё). Что бы этого не происходило есть механизи keepalive в т.ч. в openvpn.

Не уточнил сразу: на компе работал mstsc-клиент, внутри которого по rdp я воочию наблюдаю последствия таких реконнектов в виде фриза на минуту. То есть по туннелю трафик был, была активная работа. Да и ping 10 был в конфиге ovpn

Ни я не ванга ничего не можем сказать на эту тему. Все предположеия которые можно сделать из данных в репорте даны выше. Увы, я не автор openvpn и даже не автор винды что бы по какому-то адовому error code (всяко винда возвращает) понять что ж там по факту случилось.

Роутер ничего не знает о вашем openvpn для него все соединения это udp или tcp, ну если нет под них конкретного ALG. Под openvpn ессно его нет и быть не может.

Как стандарт openvpn ISO то же не принимался. Т.е. RFC нет. Все остальные TCP прикладухи работают нормально? Ну значит и дебажить нужно начинать со стороны самого openvpn чего ему не нравиться. А к нам приходить уже с конкретикой.

Так что ой. Ничего кроме вышесказанного мне сказать не чего.

P.S. 2 раза намекнул уже что данных мало и даже базовые вещи указанные в теме рядом на тему того какие данные по минимуму нужно предоставлять не выполнены. Хотя они врятли помогут пока не будет понятно что там openvpn думает и что это за ошибка такая и чего значит. Вы думаете я зря к Ванге обращаюсь. =)))

Ванга тут ещё подсказывает, грит может NAT Offload вырубить. Ибо всякую нестандартщину таки временами при работающем оффлоаде может подплющивать. Хотя куда стандартнее TCP... =)

В общем не в курсе. Может вы там в netdiag в произвольное время clear cache тыкаете. Или провайдер решил пошалить (рядом есть темы где "началось" со сменой роутера, а оказалось совпало с работами на стороне провайдера. По описанию формата "началось", к сожалени даже лучшие европейские медиумы ничего сказать не в силах. Особенно в полночь. ;)

P.S. Пинги в фоне не прерываются значит в логах PPPOE смотерть нечего т.е. сессия не теряется. Запсутите параллельно mtr и помониторьте потери. Запросто может оказаться что где-то на промежуточном хопе в моменты отвалов лавинообразно возникают потери. Чудес не бывает. Но что бы я мог помочь, мне нужны данные, особенно когда речь идёт о сервисах которые я лично не юзаю и о них мне ничего неизвестно. Тогда нужны данные начиная с версии сервера на обратном конце, всех настроек и сервера и клиента и т.д. и т.п. Правда это в любом случае вопросы то наверное уже мимо, и роутер тут очень сильно сбоку... Но mtr в отличии от пинга (интервал только поменьше поставьте) возможно подскажет в чём беда и где.

Да я понимаю, что это рвётся в первую очередь соединение операционки. И OpenVPN после этого ничего поделать уже не может.

У меня была надежда, что можно какие-нибудь детальные логи включить посмотреть, может это у провайдера что-то не честно. Кстати, можете себе плашку Квант-Телекома (Джастлан их бренд) повесить на страницу операторов интернета в ЦФО :)

Ой эти все плашки. =))) Лучше бы они в тест бы железки бы запросили, глядишь какие-нить нюансы бы выяснились.

P.S. см о mtr выше, вот он может попутно что-то подсказать. Роутер чего, он занатил и выплюнул пакет (ну грубо говоря), если tcp и не получил ack плюнул ещё несколько раз и забил. Он транзитный узел. Хоть циска будь хоть кто угодно. Диагностировать на его уровне особенно нечего как минимум до понимания чего не нравиться клиенту или серверу. Даже Шерлоку нужно понимать от чего отталкиваться. А тут как в том мультике "-Ничего не понимаю... --Аналогично!" =)))

Да забыл. Размер пакета тоже и пингу и mtr поставить ну пусть 1400, на мелких пакетах потери можно и не заметить.

Вчера погонял mtr на штатных настройках. В момент обрыва соединения каких-то отклонений в динамике показателей не заметил. Сегодня увеличил размер с 64 до 1400, качественно ничего не изменилось. Картинка за вчера

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

Сегодня выключил NAT offload и теперь жду. Пока мало времени прошло

Загруженные файлы:
  • Вам нужно войти, чтобы просматривать прикрепленные файлы..

Спрашивал у товарища сегодня не видит ли он у себя чего подобного. Грит нет и порекомендовал стартовать openvpn с ключиками -remote peer и –ping 5 если ходит поверх другого туннеля с NAT (pppoe тоже подпадает под это).

-remote peer и –ping 5

Эти ключики есть в конфиге.

 

С выключенным NAT offload вот уже 9 часов нет ни одного реконнекта.

А вот зацепка: я попробовал задействовать файрвол на роутере. Просто переключил в Enable пункт MAC/IP/Port Filtering и нажал Apply, даже не вводя никакие правила. И тут же знакомая ошибка 10060 и реконнект. Делаю Disable и Apply -- опять реконнект

Цитата: Lexus от 11/12/2020, 23:20

-remote peer и –ping 5

Эти ключики есть в конфиге.

 

С выключенным NAT offload вот уже 9 часов нет ни одного реконнекта.

Плохо. Пробуйте отключать оффлоады не полностью а перейти только в софтварный и только в хардварный. Выяснить нужно какой оффлоад приводит к тому что openvpn подплющивает.

Скорее всего это будет хардварный. Который увы из себя представляет чёрный ящик и максимум что от текущего состояния с ним можно сделать это исключать выборочно трафик из него. Т.к. openvpn может работать по любому порту и использовать как tcp так и udp то придётся видимо делать крутилку индивидуально.

А вот зацепка: я попробовал задействовать файрвол на роутере. Просто переключил в Enable пункт MAC/IP/Port Filtering и нажал Apply, даже не вводя никакие правила. И тут же знакомая ошибка 10060 и реконнект. Делаю Disable и Apply -- опять реконнект

Это не зацепка, а штатное поведение. Что бы правила применялись не когда-нить потом а сразу, при любых манипуляциях на странице фаервола после нажатия применить сбрасываются все стэйты контрака и текущие соединения порвуться.

В общем пробуйте описанное выше. Отключать оффлоады зло, надо определить какой оффлоад, дальше подумаем как красиво сделать возможность обхода проблемы совместимости с ним.

Цитата: sfstudio от 12/12/2020, 08:13

Плохо. Пробуйте отключать оффлоады не полностью а перейти только в софтварный и только в хардварный. Выяснить нужно какой оффлоад приводит к тому что openvpn подплющивает.

По умолчанию был включен Complex. Когда я стал отключать оффлоад, то попробовал сначала перейти на рекомендуемый для PPPoE режим Hardware. В течение часа в нём тоже произошел реконнект и я просто поставил Disable. Software вчера не пробовал, запущу сегодня. Отпишу тогда

Upd: 7 часов, полёт стабильный

В общем, на софтовом оффлоаде проблем нет, как и на выключенном

Ок. Сейчас соберётся 3.0.14 проверим на ней. Если будет повторяться скажу что ещё нужно будет проверить и сделаем тады крутилку что бы можно было по портам выкусывать трафик из PPE т.к. порт зарание неизвестен увы.

ООочень всё это всё же странно, есть догадка почему такое может быть, но скорее из области фантастики т.к. приводило бы к проблемам не только с openvpn а вообще с любыми TCP. Скорее всё же что-то там такое openvpn пытается такое в заголовках tcp чудить что блок PPE аппаратно переварить не в силах. А значит только выкусывать.

Попробую у себя развернуть повторить на всякий. Но не факт что повториться.

Цитата: sfstudio от 14/12/2020, 08:44

Ок. Сейчас соберётся 3.0.14 проверим на ней. Если будет повторяться скажу что ещё нужно будет проверить и сделаем тады крутилку что бы можно было по портам выкусывать трафик из PPE т.к. порт зарание неизвестен увы.

Накатил 3.0.14, сделал сброс и минимальные настройки: OpenVPN разорвался через полтора часа.

приводило бы к проблемам не только с openvpn а вообще с любыми TC

Когда я онлайн-радио слушал, воспроизведение пропадало одновременно с некоторыми разрывами OpenVPN. Причем без обновления страницы радио воспроизведение само не восстанавливалось.

Что за радио? Openvpn у меня вот прямо сейчас работает и ни единого разрыва.

Жду когда порвется.

Может хоть на радио повторю...

Цитата: sfstudio от 14/12/2020, 14:24

Что за радио? Openvpn у меня вот прямо сейчас работает и ни единого разрыва.

101.ru

Сейчас одновременно с RDP по OpenVPN, запущенному на компьютере с LAN, я полтора часа проводил видеоконференцию с помощью Jitsi meet с андроид-телефона по Wi-Fi. Не интересовался, что там за протокол, но соединение Jitsi не рвалось, а OpenVPN за это время раза 4 реконнектился. Сервер в обоих случаях один и тот же. Либо протокол более устойчив к обрывам сессии, либо дело в том, что Jitsi работал поверх WLAN (и напрямую без VPN, сам по себе), а OpenVPN поднят на LAN-интерфейсе

Или еще 100500 причин. Хоть загадайся пока у меня повторяемости нет.

Как и за 10ток лет не было массовых жалоб.

Это веяния каких-то изменений либо на стороне приложений либо на стороне ос которые видимо и приводят к какому-то хитрому поведению ppe.

Вот это в разы вероятнее.

Бум пробовать разобраться.

Ок с радио проверю.

Радио играет уже более 12 часов через OpenVPN работающий через 2шт DUO-G каскадом по LAN. Проблемы ни первой ни второй не вижу ;(

Ось какая на клиентах?

Единственная догадка которая приходит в голову это то что таки регулярно есть потери где-то по пути. В случае с PPE отсутствует практически буферизация т.е. нет шансов что передатчик задетектит потери и перепошлёт пакет и обработка таких ситуаций ложиться на клиентскую ось. В софт режиме из-за избыточной буферизации проблему может быть просто не видно или она ооочень сильно отодвигается во времени.

Косвенно об этом может говорить отсутсвие проблемы через wifi т.к. там сам драйвер тасует пакеты, занимается агрегацией и т.д. т.е. имеет очень жирный буфер (иначе скорость по радио была бы мягко сказать), в то время как по LAN для сессий обслуживаемых PPE выплёвывается буквально сразу из него напрямую в железо минуя всю программную обработку включая буферизацию.

Но это всё же только догадка.

Попробуем локализовать траблу и придумать что-то.

Для этого нужно для начала выяснить.

В обоих ли направлениях оффлоад приводит к такому поведению. Для этого используем тулзу hw_nat

Only Speed UP (0=Upstream, 1=Downstream, 2=Bi-Direction) flow 
Ex: hw_nat -Z 1

После полной загрузки командуем hw_nat -Z 1 т.е. переключаем в режим оффлоада только в download path. Проверяем. Затем так же только с hw_nat -Z 0.

 

Эти настройки не сохраняются т.е. работают до релоада драйвера PPE.

Радио играет уже более 12 часов через OpenVPN

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

Ось какая на клиентах?

Домашние компьютеры на вин10 2004. Сегодня полдня работал с другого домашнего компа (воткнут в соседний порт LAN) -- те же проблемы.

Для этого нужно для начала выяснить. В обоих ли направлениях оффлоад приводит к такому поведению

Да, в обоих. И после hw_nat -Z 1, и после hw_nat -Z 0 наблюдаются реконнекты

 

Ок буду искать винду. Не могу на рабочем ПК выделить ей столько рабочего времени на повторение. Под *nix (разных) не повторяется ни в туннеле ни сбоку.

Запустил OpenVPN до того же сервера под Ubuntu 20.04 (внутри WSL2 виндов, хост -- всё та же win10), которая выходит в свет через VirtualBox-сетевой адаптер в режиме NAT. За 8 часов ни одного реконнекта

Вывод? Tcp стэк винды чудит или возможно какой-нить встроенный в антивирус фаер плющит что и приводит к чудесам на стороне ppe.

Wsl2 нынче тупо виртуалка

В общем на чистой 10тке (специально водрузил на старый ноут свежую систему) так же не увидел проблемы.

Что стоит из антивирусов и т.п. в системе? Вот почти уверен где-то там собака зарыта. Надо добиться повторяемости у меня что бы придумать как обойти безболезненно. Ну или хотя бы понять кому репортить.

Что стоит из антивирусов и т.п. в системе?

Kaspersky Anti-Virus 21.2. Встроенный в вин10 дефендер отключен настолько, насколько это возможно. Ну офис, браузеры и игры тут вроде влиять не должны, а больше и нет ничего особенного.

Вот момент обрыва соединения: пакет 13628

Загруженные файлы:
  • Вам нужно войти, чтобы просматривать прикрепленные файлы..

С касперским были траблы в RTNL из-за чего с goahead спозли на nginx. Он время от времени решал дропать часть ACK при этом UI роутера начинал страшно тормозить, ибо goahead не посылал следующую порцию данных.

Решением было добавление в исключения адреса роутера у касперского. Отключение его не помогало никак. Либо адрес в исключения либо полное удаление.

Дампы трафика тут ни чем не помогут (особенно в виде скринов). Мне нужна повторяемость. Буду пробовать с касперским чего делать. Надеюсь у них есть бесплатная версия. Ибо тырить софт не приучен.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Сообщить об опечатке

Текст, который будет отправлен нашим редакторам: