Помощь в выявлении проблемы OpenVPN (DoubleVPN)

Конфиг и логи лучше залить на pastebin какой-нибудь если их там много, а так для кода тут есть тег [code]\[/code] (вот тут про разметку).

Вот про разметку читал, но кат не сработал. А чисто кодом делал. Но много получилось, и удалил. Но сейчас попробую. Спасибо большое

http://pastebin.com/hYZip5ry Действительно очь удобно, спасибо

Вангую проблема уже описана 100500 раз mtu/mss
Вариации на тему:
tun-mtu
mtu-test (требует несколько минут для тестирования после поднятия соединения)
mssfix
Или
в iptables .... -j TCPMSS --clamp-mss-to-pmtu

сейчас погуглю, в этом направлении. Спасибо за то что ткнул куда рыть. Буду читать, что и как

Все вроде бы коннектится, с терминала даже пингуются ip сайтов.

Попробовать ping разной длиной пакета с запретом фрагментации. типа: ping x.x.x.x -s YYYY -M do

как только получаем что-то типа Frag needed and DF set - значит уперлись в ограничение MTU (максимально допустимого размера пакета) на интерфейсе. Методом дихотомии (или тупо из сообщения mtu=XXXX) определяем максимальную длину пакета, который проходит. И скорее всего она мала (что-то в районе 1472 или еще менее вместо 1500) поскольку туннель отъедает свое. Это типичная причина неоткрытия (или недоокрытия) сайтов. А также других неприятностей. Подробно рыть по слову TCP MSS.

Плохой совет. Например если клиенты выходят из рандомных мест подключения.

Какая разница, откуда они выходят. Внешне проблема очень похожа на ограничение MTU (не буду утвержать, что 100%, но похожа). Ну и наличие туннеля наводит на мысль.

Описанным методом - обрезание MTU легко локализуется и определяется, сколько от него осталось.

А дальше на сервере можно подхрихтовать MSS в запросах в проходящих c запросах, например с помощью таблицы mangle в iptables. По крайней мере меня такая беда (не открываются у удаленных клиентов сайты из-за MTU, а MTU режет туннель между клиентом и сервером) встречалась. И «рихтованием» MSS снялась. Может можно лучше. Но так - работает. К сожалению, аналога цискиной команды для туннелей ip mtu в линуксах, по моему, нет.

Да, про размер пакета, вы указали прям верно и сточностью до 100%))) Вот, что пинг выдал. Такого типа «Frag needed and DF set» не чего конечно не выдало, но я так понял, что размер пакета указанный в конфиге слишком длинный. Странно, до этого такой беды не было. Если не затруднит, для полноты понимания. Размер пакета нужно править на всех звеньях цепи, на EnterNode (клиен, сервер) ExitNode (сервер) и конфиг клиента? Ну и конечно же спасибо всем кто помогает. Даже огромное спасибо

PING 87.240.165.85 (87.240.165.85) 1472(1500) bytes of data.
1480 bytes from 87.240.165.85: icmp_seq=1 ttl=54 time=700 ms
1480 bytes from 87.240.165.85: icmp_seq=2 ttl=54 time=172 ms
1480 bytes from 87.240.165.85: icmp_seq=3 ttl=54 time=173 ms
1480 bytes from 87.240.165.85: icmp_seq=4 ttl=54 time=190 ms
1480 bytes from 87.240.165.85: icmp_seq=5 ttl=54 time=172 ms
1480 bytes from 87.240.165.85: icmp_seq=6 ttl=54 time=187 ms
1480 bytes from 87.240.165.85: icmp_seq=7 ttl=54 time=173 ms
1480 bytes from 87.240.165.85: icmp_seq=8 ttl=54 time=204 ms
1480 bytes from 87.240.165.85: icmp_seq=9 ttl=54 time=193 ms
1480 bytes from 87.240.165.85: icmp_seq=10 ttl=54 time=177 ms
1480 bytes from 87.240.165.85: icmp_seq=11 ttl=54 time=173 ms
1480 bytes from 87.240.165.85: icmp_seq=12 ttl=54 time=176 ms
1480 bytes from 87.240.165.85: icmp_seq=13 ttl=54 time=174 ms
1480 bytes from 87.240.165.85: icmp_seq=14 ttl=54 time=215 ms
1480 bytes from 87.240.165.85: icmp_seq=15 ttl=54 time=204 ms
1480 bytes from 87.240.165.85: icmp_seq=16 ttl=54 time=196 ms
1480 bytes from 87.240.165.85: icmp_seq=17 ttl=54 time=187 ms
1480 bytes from 87.240.165.85: icmp_seq=18 ttl=54 time=210 ms
1480 bytes from 87.240.165.85: icmp_seq=19 ttl=54 time=185 ms
1480 bytes from 87.240.165.85: icmp_seq=20 ttl=54 time=192 ms

PING 87.240.165.85 (87.240.165.85) 1473(1501) bytes of data.
ping: local error: Message too long, mtu=1500
ping: local error: Message too long, mtu=1500
ping: local error: Message too long, mtu=1500
ping: local error: Message too long, mtu=1500
ping: local error: Message too long, mtu=1500
ping: local error: Message too long, mtu=1500
ping: local error: Message too long, mtu=1500

Я вам ответил на это:

Методом дихотомии (или тупо из сообщения mtu=XXXX) определяем максимальную длину пакета, который проходит.

Т.е. я беру точку A где получил одно значение, а далее перехожу в точку B где например у меня подключение через pptp это значение уже окажется ниже. Поэтому и есть всякие другие варианты о которых я написал выше ТС.

Такого типа «Frag needed and DF set» не чего конечно не выдало

выдало «Message too long» - это тоже самое :-) От версии ping зависит, что именно будет в сообщении..

Но. У вас выдало MTU 1500 (минус заголовки - остается как раз 1472 данных, см «1472(1500) bytes of data.»). А для пакета больше 1500 - уже да, «слишком длинный пакет».Это нормально. И если от клиента до сайта пакет в 1500 байт ходит, то тогда проблема с «открытием сайтов» и все такое не в MTU.

Размер пакета нужно править на всех звеньях цепи, на EnterNode (клиен, сервер) ExitNode (сервер) и конфиг клиента?

1. mtu это не размер пакета (это вам так, для общего образования)
2. править... смотря чего править будете... Но имхо все уже несколько раз описали mss, mtu, флаг в руки.

И если от клиента до сайта пакет в 1500 байт ходит, то тогда проблема с «открытием сайтов» и все такое не в MTU.

Сами поняли что написали? Через тунель с mtu 1500 до сайта тоже пакет в 1500 дойдет без фрагментации?

Т.е. я беру точку A где получил одно значение, а далее перехожу в точку B где например у меня подключение через pptp это значение уже окажется ниже. Поэтому и есть всякие другие варианты о которых я написал выше ТС.

Или я не понял, в чем вопрос, или при чем тут точки А,В,Ы и т.п.? Как я понял - есть клиент, подключенный к внешнему миру через туннель, который терминируется на сервере. С клиента - проблемы с открытием сайтов и т.п. Вот с этого клиента и проверяем. Не таская его по точкам.

Если выясняем, что по дороге ничего не режется/не фрагментируется, то дело в данном случае не в MTU. А в другой точке может быть в MTU, но в данном случае, если я правильно его понял, не в нём.

Видимо мы друг друга не поняли. Я начал с «Плохой совет. Например если клиенты выходят из рандомных мест подключения.» Обычно когда народ устраивает сабж подразумевается и разные точки выхода клиентов.
Ваш вариант заточен только под одного единственного клиента и только на текущем подключении, читай если что-то поменялось «наколу мочало начинаем все сначала». Я же ТС намекнул на универсальное решение проблем.

Спасибо, пока не чего не понятно. Но буду сейчас курить форум и все, что связано с mss, mtu. Надеюсь дойдет, где нужно править, и как определить место неполадки. Потому что сейчас сделал такой же пинг на EnterNode там тоже MTU 1500 не проходит, слишком длинный.

Уже хотя бы ясно в каком направлении копать, а то сидел, не мог понять в чем беда и чего делать вообще. Эх трудно жить обезьяной не понимающей((

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

Сами поняли что написали? Через тунель с mtu 1500 до сайта тоже пакет в 1500 дойдет без фрагментации?

бывают варианты :-) конкретно за openVPN не скажу, пользовался им редко и давно. а в GRE между цисками, например, запросто. Естественно, в туннеле пакет фрагментируется, но потом обратно собирается и «снаружи» этого никто не видит. Даже если взведен DF-бит. Поэтому от клиента до сайта - да, доходит без фрагментации.

В данном случае:

PING 87.240.165.85 (87.240.165.85) 1472(1500) bytes of data. 1480 bytes from 87.240.165.85: icmp_seq=1 ttl=54 time=700 ms

если это пинг до сайта через туннель, то, как видите доходит :-) если это что-то другое, то значит введен в заблуждение.

Ваш вариант заточен только под одного единственного клиента

под диагностику данного конкретного случая, точнее пока не выяснено, в чем проблема - прописывать лечение без толку :-)

Простое решение (и даже наверное должно работать :) )
Начните с mtu-test в конфигах (всех) только tun-mtu удалите (он и так по дэфолту поднимется). После подьема всех соединений мин пять подождите (хотя эта инфа и так в логи вывалиться).

бывают варианты :-) конкретно за openVPN не скажу, пользовался им редко и давно. а в GRE между цисками, например, запросто.

От это круто вы смешали «коней и людей» :)
Предлагаю все-таки порешать проблему ТС а не... «в вакууме » :)

Только что заметил одну странность в поведении всего этого момента. Сделал как вы порекомендовали. Во всех конфигах вместо tun-mtu прописал mtu-test. результат ниже. Дальше я так понял, нужно разобратся с «mssfix» У меня открыты 2 сервера по ssh EnterNode не теряет конект после подключения к vpn а ExitNode теряет, приходится переподключатся. Хотя всегда при подключении коннект обрывался со всеми серверами.

Thu Sep  1 20:39:33 2016 NOTE: Empirical MTU test completed [Tried,Actual] local->remote=[1601,1601] remote->local=[1601,1601]

Thu Sep  1 19:39:44 2016 client/185.90.60.73:52868 NOTE: Empirical MTU test completed [Tried,Actual] local->remote=[1601,1601] remote->local=[1601,1601]

Thu Sep  1 19:38:58 2016 client/77.218.230.88:1153 NOTE: Empirical MTU test completed [Tried,Actual] local->remote=[1601,1601] remote->local=[1601,1601]

Хммм... это у вас сервер-сервер? А что на сервер клиент?

Да получается, клиент конектица к EnterNod. На ней сервер и клиент, далее передает на ExitNod там, ток сервер. Получается на Enternode tun0 и tun3 интерфейс, на ExitNode tun0

Нашел на хабре статейку https://habrahabr.ru/post/136871/ Сейчас попробую применить описаные там манипуляции. В этом всем моменте, не понятно одно, как определять верно. На каком узле эта беда ибо 1472 MTU проходит везде. А как выявить плешивую овцу пока не понятно, может недостаточно гуглил. Или просто еще не пришло понимание момента. Этот ВПН только для личного пользования)

Статью не читал :)
Если я правильно путаю, между точками(серверами) у вас все нормально было, можно и не трогать а вот например на клиентах уже выставить mssfix с меньшем значением.
Вариант простой, пальцем небо, низкие tun-mtu (и тамже mssfix с еще более низким значением) заработает значит все ок. Но я этого не советовал. :)
А вообще есть еще такая команда как tracepath, помогает увидеть pmtu на маршруте.
PS А случайно ваши клиенты не через еще один роутер работают?

Да клиент вообщем то я. А сижу я через 4g модем. Ибо у меня тут крайне специфическое место. Нужно или 4g модем пользовать, или ВПН делать, ибо нормальный интеренет, можно сказать почти, что публичный. Спасибо за ваши советы, буду сейчас пробовать. Весь день убил. Но зато много нового узнал/ прочитал.

tun-mtu 1380
mssfix 1000
Должно заработать :)
Это на клиенте

СПАСИБО ОГРОМНОЕ!!!!!!! 11 часов сегодня я боролся с этой бедой. И да, оно заработало. Поменял на EnterNod на клиенте tun-mtu 1380 mssfix 1000 И все заработало. Просто нет слов, для выражения моей благодарности и признательности!Низкий поклон!!!

Эммм, это я вообще-то с большим перезакладом написал :)