[Comm] OpenVPN через спутник

[Comm] OpenVPN через спутник

[Vladimir Karpinsky]

Здравствуйте!

Есть 2 параллельных туннеля до хоста через спутник: ipsec и openvpn. Через 
ipsec нормально работает и rsync и vnc. Через openvpn rsync отваливается по 
таймауту, vnc рисует верхний правый угол рабочего стола и висит.

2013/02/06 17:31:43 [28860] receiving file list
2013/02/06 17:33:54 [28884] [receiver] io timeout after 120 seconds -- exiting
2013/02/06 17:33:54 [28884] rsync error: timeout in data send/receive (code 
30) at io.c(140) [receiver=3.0.9]
2013/02/06 17:33:54 [28860] rsync: connection unexpectedly closed (38667 
bytes received so far) [generator]
2013/02/06 17:33:54 [28860] rsync error: error in rsync protocol data 
stream (code 12) at io.c(605) [generator=3.0.9]

Может ли такая ситуация быть вызвана какими-то настройками openvpn, не 
учитывающими удалённость хоста --- отклик ping не менее 700 мс? Скорость 
достаточная, но первый пакет надо ждать долго.

Можно ли что-то "подкрутить"? желательно, конечно, только для этого 
клиента, хотя, можно и глобально, если остальным портить жизнь не будет.

Возможно проблема совсем не в этом: ipsec-туннель соединяет маршрутизаторы, 
openvpn --- компьютеры за ними. Не знаю с какой стороны подойти к выявлению 
причины. Трудность ещё и в то, что на дальнем конце 
маршрутизатор-коробочка, за ним компьютер --- винда.

-- 
	С уважением,
		Владимир.

Re: [Comm] OpenVPN через спутник

[Nikolay A. Fetisov]

В Ср, 06/02/2013 в 21:41 +0400, Vladimir Karpinsky пишет:
> Есть 2 параллельных туннеля до хоста через спутник: ipsec и openvpn. Через 
> ipsec нормально работает и rsync и vnc. Через openvpn rsync отваливается по 
> таймауту, vnc рисует верхний правый угол рабочего стола и висит.

Канал OpenVPN - через UDP, через TCP? В логах OpenVPN что по состоянию 
соединения пишется?
Если вопрос в таймаутах соединения - то можно смотреть на опции
keepalive, ping, inactive и т.п.


И, наугад - а это не MTU ли случаем? Может, OpenVPN его просто
неправильно угадывает?


-- 
С уважением,
Николай Фетисов

Re: [Comm] OpenVPN через спутник

[Vladimir Karpinsky]

06.02.2013 22:09, Nikolay A. Fetisov пишет:
> В Ср, 06/02/2013 в 21:41 +0400, Vladimir Karpinsky пишет:
>> Есть 2 параллельных туннеля до хоста через спутник: ipsec и openvpn. Через
>> ipsec нормально работает и rsync и vnc. Через openvpn rsync отваливается по
>> таймауту, vnc рисует верхний правый угол рабочего стола и висит.
>
> Канал OpenVPN - через UDP, через TCP?

UDP

> В логах OpenVPN что по состоянию соединения пишется?

На сервере:
Feb  6 22:22:25 plkv openvpn[22364]: VAL/11.22.33.44:1032 
Authenticate/Decrypt packet error: packet HMAC authentication failed

Интересно, что команды типа rsync -L (список) завершаются успешно. Вообще 
говоря, список файлов для rsync достаточно велик (более 2000).

> Если вопрос в таймаутах соединения - то можно смотреть на опции
> keepalive, ping, inactive и т.п.

Буду смотреть.

> И, наугад - а это не MTU ли случаем? Может, OpenVPN его просто
> неправильно угадывает?

А как это выяснить?

-- 
	С уважением,
		Владимир.

Re: [Comm] OpenVPN через спутник

[Vladimir Karpinsky]

06.02.2013 22:36, Vladimir Karpinsky пишет:
>> Если вопрос в таймаутах соединения - то можно смотреть на опции
>> keepalive, ping, inactive и т.п.

Поставил keepalive 10 600 --- без успеха. Но похоже, что здесь не соединение.

-- 
	С уважением,
		Владимир.

Re: [Comm] OpenVPN через спутник

[Vasily Tereshko]

06.02.2013 21:00, Vladimir Karpinsky пишет:
> 06.02.2013 22:36, Vladimir Karpinsky пишет:
>>> Если вопрос в таймаутах соединения - то можно смотреть на опции
>>> keepalive, ping, inactive и т.п.
>
> Поставил keepalive 10 600 --- без успеха. Но похоже, что здесь не
> соединение.
>
А попробуйте лучше TCP вместо UDP.
Было у меня такое на ненадежном линке, сконфигурировал ходить через TCP
и после проблем не было ни разу.

-- 
Толми

Re: [Comm] OpenVPN через спутник

[Vladimir Karpinsky]

06.02.2013 23:11, Vasily Tereshko пишет:
> А попробуйте лучше TCP вместо UDP.
> Было у меня такое на ненадежном линке, сконфигурировал ходить через TCP
> и после проблем не было ни разу.

А, ведь, помогло! Спасибо большое! Правда теперь всех клиентов надо 
перетаскивать...

-- 
	С уважением,
		Владимир.

Re: [Comm] OpenVPN через спутник

[Vladimir Karpinsky]

Да, забыл спросить: "А чем это мне теперь грозит с какого-нибудь другого 
боку?" Наверное, недаром UDP стоит по умолчанию...

06.02.2013 23:25, Vladimir Karpinsky пишет:
> 06.02.2013 23:11, Vasily Tereshko пишет:
>> А попробуйте лучше TCP вместо UDP.
>> Было у меня такое на ненадежном линке, сконфигурировал ходить через TCP
>> и после проблем не было ни разу.
>
> А, ведь, помогло! Спасибо большое! Правда теперь всех клиентов надо
> перетаскивать...
>

-- 
	С уважением,
		Владимир.

Re: [Comm] OpenVPN через спутник

[Vasily Tereshko]

06.02.2013 21:28, Vladimir Karpinsky пишет:
> Да, забыл спросить: "А чем это мне теперь грозит с какого-нибудь
> другого боку?" Наверное, недаром UDP стоит по умолчанию...
>
>>
>>> А попробуйте лучше TCP вместо UDP.
>>> Было у меня такое на ненадежном линке, сконфигурировал ходить через TCP
>>> и после проблем не было ни разу.
>>
>> А, ведь, помогло! Спасибо большое! Правда теперь всех клиентов надо
>> перетаскивать...
>>
>
Теоретически UDP быстрее. Но хорошо работает только в "лабораторных
условиях",  вот на таких странных линках все преимущества быстро сходят
на нет.
По поводу "переводить всех" - а зачем ? Вам  что, открытых портов жалко?
Пусть будут и UDP, и TCP.



-- 
Толми

Re: [Comm] OpenVPN через спутник

[Nikolay A. Fetisov]

В Ср, 06/02/2013 в 23:28 +0400, Vladimir Karpinsky пишет:
> Да, забыл спросить: "А чем это мне теперь грозит с какого-нибудь другого 
> боку?" Наверное, недаром UDP стоит по умолчанию...

Организация туннеля через TCP, особенно при канале плохого качества и с
большими задержками передачи пакетов - это плохая идея. 

См. "Why TCP Over TCP Is A Bad Idea",
http://sites.inka.de/sites/bigred/devel/tcp-tcp.html

Статья старая, к OpenVPN отношения не имеет, но и суть проблемы общая и
на уровне протокола.

-- 
С уважением,
Николай Фетисов

Re: [Comm] OpenVPN через спутник

[Nikolay A. Fetisov]

В Ср, 06/02/2013 в 22:36 +0400, Vladimir Karpinsky пишет:
> 06.02.2013 22:09, Nikolay A. Fetisov пишет:
> ...
> > В логах OpenVPN что по состоянию соединения пишется?
> 
> На сервере:
> Feb  6 22:22:25 plkv openvpn[22364]: VAL/11.22.33.44:1032 
> Authenticate/Decrypt packet error: packet HMAC authentication failed
> 

Пришёл битый пакет - был отброшен.

См.
http://www.packtpub.com/article/troubleshooting-openvpn-2-configurations ,
раздел  "Troubleshooting MTU and tun-mtu issues" .

....
> > И, наугад - а это не MTU ли случаем? Может, OpenVPN его просто
> > неправильно угадывает?
> 
> А как это выяснить?
> 

Попробовать отправить ping с большим размером пакета - в статье пример
есть.

В целом, смотреть на MTU интерфейса спутникового канала,
и сравнивать с MTU интерфейса tun. 

Согласно openvpn(8), "(the following options is )a good first try for
solving MTU-related connection problems:"

--tun-mtu 1500 --fragment 1300 --mssfix


Единственное, посмотрите на заметку в статье по поводу Windows - там
есть печальное. 


-- 
С уважением,
Николай Фетисов

Re: [Comm] OpenVPN через спутник

[Vladimir Karpinsky]

07.02.2013 0:02, Nikolay A. Fetisov пишет:
> В целом, смотреть на MTU интерфейса спутникового канала,
> и сравнивать с MTU интерфейса tun.
>
> Согласно openvpn(8), "(the following options is )a good first try for
> solving MTU-related connection problems:"
>
> --tun-mtu 1500 --fragment 1300 --mssfix
>
>
> Единственное, посмотрите на заметку в статье по поводу Windows - там
> есть печальное.

Причём не просто печальное, а очень печальное. Поскольку большая часть 
клиентов (и самый плохой клиент тоже) WindowsXP, то это, увы, не для меня. 
Пока посмотрю, как через TCP работать будет...

-- 
	С уважением,
		Владимир.

Re: [Comm] OpenVPN через спутник

[Vladimir Karpinsky]

06.02.2013 23:37, Vasily Tereshko пишет:
> По поводу "переводить всех" - а зачем ? Вам  что, открытых портов жалко?
> Пусть будут и UDP, и TCP.

А как это сделать?

-- 
	С уважением,
		Владимир.

Re: [Comm] OpenVPN через спутник

[Nikolay A. Fetisov]

В Чт, 07/02/2013 в 08:17 +0400, Vladimir Karpinsky пишет:
> 06.02.2013 23:37, Vasily Tereshko пишет:
> > По поводу "переводить всех" - а зачем ? Вам  что, открытых портов жалко?
> > Пусть будут и UDP, и TCP.
> 
> А как это сделать?
> 

Запустить рядом с первым  второй сервер. 

Примерно с той же конфигурацией - с заменой proto на tcp,
с указанием другого dev, со своими файлами статусов и логов,
ну и со своей раздаваемой клиентам сетью. 

Хотя делать это ради одного клиента - не знаю, я бы попробовал бы
всё-таки сначала поиграть с его настройками MTU. Исходя из того, что за
два года и две major версии ситуация с TAP-WIN32 могла и измениться.

-- 
С уважением,
Николай Фетисов

Re: [Comm] OpenVPN через спутник

[Vladimir Karpinsky]

07.02.2013 8:56, Nikolay A. Fetisov пишет:
> В Чт, 07/02/2013 в 08:17 +0400, Vladimir Karpinsky пишет:
>> 06.02.2013 23:37, Vasily Tereshko пишет:
>>> По поводу "переводить всех" - а зачем ? Вам  что, открытых портов жалко?
>>> Пусть будут и UDP, и TCP.
>>
>> А как это сделать?
>>
>
> Запустить рядом с первым  второй сервер.
>
> Примерно с той же конфигурацией - с заменой proto на tcp,
> с указанием другого dev, со своими файлами статусов и логов,
> ну и со своей раздаваемой клиентам сетью.

Я так и думал. Но мне важно, чтобы клиенты между собой общались, так что 
это совсем не мой случай.

> Хотя делать это ради одного клиента - не знаю, я бы попробовал бы
> всё-таки сначала поиграть с его настройками MTU. Исходя из того, что за
> два года и две major версии ситуация с TAP-WIN32 могла и измениться.

Погуглю...

-- 
	С уважением,
		Владимир.

Re: [Comm] OpenVPN через спутник

[Nikolay A. Fetisov]

В Чт, 07/02/2013 в 09:05 +0400, Vladimir Karpinsky пишет:
> 07.02.2013 8:56, Nikolay A. Fetisov пишет:
...
> > Запустить рядом с первым  второй сервер.
> ...
> 
> Я так и думал. Но мне важно, чтобы клиенты между собой общались, так что 
> это совсем не мой случай.

А какие проблемы? Добавить через push "route ... " на каждом из серверов
OpenVPN маршрут на соседнюю сеть у клиента, и разрешить этот трафик на
уровне настройки сетевых интерфейсов - опять же на сервере.

Между клиентами всё равно данные передаются через сервер - потерь в 
производительности не будет.

-- 
С уважением,
Николай Фетисов

Re: [Comm] OpenVPN через спутник

[Vladimir Karpinsky]

07.02.2013 0:02, Nikolay A. Fetisov пишет:
> В Ср, 06/02/2013 в 22:36 +0400, Vladimir Karpinsky пишет:
>> 06.02.2013 22:09, Nikolay A. Fetisov пишет:
>> ...
>>> В логах OpenVPN что по состоянию соединения пишется?
>>
>> На сервере:
>> Feb  6 22:22:25 plkv openvpn[22364]: VAL/11.22.33.44:1032
>> Authenticate/Decrypt packet error: packet HMAC authentication failed
>>
>
> Пришёл битый пакет - был отброшен.
>
> См.
> http://www.packtpub.com/article/troubleshooting-openvpn-2-configurations ,
> раздел  "Troubleshooting MTU and tun-mtu issues" .
>
> ....
>>> И, наугад - а это не MTU ли случаем? Может, OpenVPN его просто
>>> неправильно угадывает?
>>
>> А как это выяснить?
>>
>
> Попробовать отправить ping с большим размером пакета - в статье пример
> есть.

Спутник будет доступен только ближе к вечеру, поэтому пока тренируюсь на 
том, что есть. Что-то у меня не воспроизводится пример из статьи --- я не 
получаю ошибок при увеличении размера пакетов, но время отклика сначала 
резко увеличивается (при 1500), а потом опять уменьшается:

# ping 10.8.0.30 -s 1300
PING 10.8.0.30 (10.8.0.30) 1300(1328) bytes of data.
1308 bytes from 10.8.0.30: icmp_req=1 ttl=64 time=6.40 ms

# ping 10.8.0.30 -s 1472
PING 10.8.0.30 (10.8.0.30) 1472(1500) bytes of data.
1480 bytes from 10.8.0.30: icmp_req=1 ttl=64 time=6.06 ms

# ping 10.8.0.30 -s 1473
PING 10.8.0.30 (10.8.0.30) 1473(1501) bytes of data.
1481 bytes from 10.8.0.30: icmp_req=1 ttl=64 time=61.0 ms

# ping 10.8.0.30 -s 5000
PING 10.8.0.30 (10.8.0.30) 5000(5028) bytes of data.
5008 bytes from 10.8.0.30: icmp_req=1 ttl=64 time=61.0 ms

# ing 10.8.0.30 -s 8000
PING 10.8.0.30 (10.8.0.30) 8000(8028) bytes of data.
8008 bytes from 10.8.0.30: icmp_req=1 ttl=64 time=47.0 ms

# ping 10.8.0.30 -s 9000
PING 10.8.0.30 (10.8.0.30) 9000(9028) bytes of data.
9008 bytes from 10.8.0.30: icmp_req=1 ttl=64 time=16.9 ms


-- 
	С уважением,
		Владимир.

Re: [Comm] OpenVPN через спутник

[Nikolay A. Fetisov]

В Чт, 07/02/2013 в 10:13 +0400, Vladimir Karpinsky пишет:
> 07.02.2013 0:02, Nikolay A. Fetisov пишет:
> > В Ср, 06/02/2013 в 22:36 +0400, Vladimir Karpinsky пишет:
> >> 06.02.2013 22:09, Nikolay A. Fetisov пишет:
> >> ...
> >>> В логах OpenVPN что по состоянию соединения пишется?
> >>
> >> На сервере:
> >> Feb  6 22:22:25 plkv openvpn[22364]: VAL/11.22.33.44:1032
> >> Authenticate/Decrypt packet error: packet HMAC authentication failed
> >>
> >
> > Пришёл битый пакет - был отброшен.
> >...
> >
> > Попробовать отправить ping с большим размером пакета - в статье пример
> > есть.
> 
> Спутник будет доступен только ближе к вечеру, поэтому пока тренируюсь на 
> том, что есть. Что-то у меня не воспроизводится пример из статьи --- я не 
> получаю ошибок при увеличении размера пакетов, ....

А что Вы хотите воспроизвести, на нормально работающем соединении?

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

Как это чинить - в общих чертах понятно, добавив mssfix.
А вот как сломать работающее - не скажу.

-- 
С уважением,
Николай Фетисов

Re: [Comm] OpenVPN через спутник

[Nikolay A. Fetisov]

В Чт, 07/02/2013 в 15:26 +0400, Vladimir Karpinsky пишет:
> Конкретизирую вопрос: 
> 
> mtu-test выдал несимметричность mtu туда и обратно. Означает ли это,
> что ограничение mtu надо вводить только на стороне клиента, коль скоро
> дефолтное mtu на сервере удовлетворяет результату теста. Правильно ли
> я понимаю, что для этого достаточно в конфиге клиента прописать
> tun-mtu 1400
> mssfix
> ?

Адаптируя рекомендованное в руководстве, скорее
tun-mtu 1400
fragment 1300
mssfix


-- 
С уважением,
Николай Фетисов

Re: [Comm] OpenVPN через спутник

[Vladimir Karpinsky]

07.02.2013 20:33, Nikolay A. Fetisov пишет:
> Адаптируя рекомендованное в руководстве, скорее
> tun-mtu 1400
> fragment 1300
> mssfix

И судя по:
WARNING: 'tun-mtu' is used inconsistently, local='tun-mtu 1400', 
remote='tun-mtu 1500'

надо это делать и на клиенте, и на сервере?

-- 
	С уважением,
		Владимир.

Re: [Comm] OpenVPN через спутник

[Nikolay A. Fetisov]

В Пт, 08/02/2013 в 18:01 +0400, Vladimir Karpinsky пишет:
> 07.02.2013 20:33, Nikolay A. Fetisov пишет:
> > Адаптируя рекомендованное в руководстве, скорее
> > tun-mtu 1400
> > fragment 1300
> > mssfix
> 
> И судя по:
> WARNING: 'tun-mtu' is used inconsistently, local='tun-mtu 1400', 
> remote='tun-mtu 1500'
> 
> надо это делать и на клиенте, и на сервере?

Наверное, это зависит от того, он ворчит и не работает, или 
ворчит, но работает.


-- 
С уважением,
Николай Фетисов

Re: [Comm] OpenVPN через спутник

[Vladimir Karpinsky]

08.02.2013 21:07, Nikolay A. Fetisov пишет:
> В Пт, 08/02/2013 в 18:01 +0400, Vladimir Karpinsky пишет:
>> 07.02.2013 20:33, Nikolay A. Fetisov пишет:
>>> Адаптируя рекомендованное в руководстве, скорее
>>> tun-mtu 1400
>>> fragment 1300
>>> mssfix
>>
>> И судя по:
>> WARNING: 'tun-mtu' is used inconsistently, local='tun-mtu 1400',
>> remote='tun-mtu 1500'
>>
>> надо это делать и на клиенте, и на сервере?
>
> Наверное, это зависит от того, он ворчит и не работает, или
> ворчит, но работает.

Ворчит, но работает.

-- 
	С уважением,
		Владимир.

Re: [Comm] OpenVPN через спутник

[Vladimir Karpinsky]

08.02.2013 21:07, Nikolay A. Fetisov пишет:
> tun-mtu 1400
> fragment 1300
> mssfix

Прописал клиенту, сейчас обнаружил ещё один тип ворчания на сервере:

WARNING: 'mtu-dynamic' is present in remote config but missing in local 
config, remote='mtu-dynamic'

В конфиге клиента про mtu, кроме приведённого выше в этом же письме нет.

Интересно, что mtu от клиента действительно меняется:

Feb  9 15:31:59 plkv openvpn[2304]: 11.22.33.44:1082 WARNING: 'link-mtu' is 
used inconsistently, local='link-mtu 1542', remote='link-mtu 1446'
Feb  9 15:31:59 plkv openvpn[2304]: 11.22.33.44.82:1082 WARNING: 'tun-mtu' 
is used inconsistently, local='tun-mtu 1500', remote='tun-mtu 1400'

Не  надо ли добавить в конфиг ещё
mtu-extra 32
поскольку  "remote='link-mtu 1446'" больше того, что выдал mtu-test 
(remote->local=[1541,1437]).

Несмотря на эти ворчания туннель работает.

-- 
	С уважением,
		Владимир.

Re: [Comm] OpenVPN через спутник

[Vladimir Karpinsky]

08.02.2013 21:07, Nikolay A. Fetisov пишет:
> Адаптируя рекомендованное в руководстве, скорее
>> >tun-mtu 1400
>> >fragment 1300
>> >mssfix

Каждый день что-то новое: сегодня пока не закомментировал fragments получал 
на сервере:
openvpn[31203]: VAL/11.22.33.44:1074 Bad LZO decompression header byte: 0


-- 
	С уважением,
		Владимир.