LINUX.ORG.RU
Форум — Admin  

Оpenvpn потери пакетов

 


0

1

Добрый день !
Возможно кто-нибудь сталкивался с подобной проблемой, подскажите. Дано:

Маршрутизируемая vpn сеть (10.10.10.0/24)
Несколько локальных сетей дополнительных офисов 192.168.х.0/24 (!=192.168.0.0/24)
Сеть 192.168.0.0/24 - сеть филиала, где находится СП - 192.168.0.100 и vpn шлюз - 192.168.0.1 == 10.10.10.1

Проблема в следующем, из одного доп.офиса, (подсеть 192.168.1.0/24) до 192.168.0.0/24 _именно_через_туннель_ (!) имеются потери пакетов (%25-%50)
Что касаемо остальных офисов 192.168.[2-9].0/24 потерь нет.
Что удивительно, mtr показывает потери только через vpn туннель (т.е до 10.10.10.1), через улицу же до внешней ip (222.222.222.222 == 10.10.10.1) потерь нет.
Конфигурации серверов везде одинаковые. Я бы предположил что потери идут на уровне провайдера, но тогда почему через улицу потерь нет ?
Я в тупике, прощу помощи. Конфигурации приложу.


Спасибо


Ответ на: комментарий от zgen 
dev tun
port 9876
remote 222.222.222.222
proto udp
link-mtu 1300
client
dh /etc/openvpn/dh1024.pem
ca /etc/openvpn/ca.crt
key /etc/openvpn/do1.key
cert /etc/openvpn/do1.crt
log /var/log/openvpn.log
status /var/log/openvpn-status.log
user nobody
group nogroup
persist-key
persist-tun
verb 4
mute 5
comp-lzo
cipher AES-256-CBC
auth MD5
keysize 256



port 9876
proto udp
dev tun
link-mtu 1300
ca /etc/openvpn/keys/ca.crt
key /etc/openvpn/keys/srv.key
dh /etc/openvpn/keys/dh1024.pem
cert /etc/openvpn/keys/srv.crt
log /var/log/openvpn.log
status /var/log/openvpn-status.log
server 10.10.10.0 255.255.255.0
push "route 192.168.0.0 255.255.255.0"
route 192.168.1.0 255.255.255.0
client-config-dir /etc/openvpn/ccd/
keepalive 10 120
user nobody
group nogroup
persist-key
persist-tun
verb 4
mute 5
comp-lzo
client-to-client
cipher AES-256-CBC
auth MD5
keysize 256


Лог с сервера при соединении /var/log/openvpn.log: 
Wed Mar 13 22:32:16 2013 us=612673 MULTI: Learn: 192.168.1.14 -> do1/111.111.111.111:9876
Wed Mar 13 22:35:31 2013 us=613623 do1/111.111.111.111:9876 TLS: tls_process: killed expiring key
Wed Mar 13 22:36:41 2013 us=473568 do1/111.111.111.111:9876 VERIFY OK: depth=1, /C=RU/ST=CA/L=city/O=srv/CN=srv_CA/name=admin/emailAddress=admin@example.com
Wed Mar 13 22:36:41 2013 us=473936 do1/111.111.111.111:9876 VERIFY OK: depth=0, /C=RU/ST=CA/L=do1/O=srv/CN=do1/name=do1/emailAddress=admin@example.com
Wed Mar 13 22:36:51 2013 us=430432 do1/111.111.111.111:9876 Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Wed Mar 13 22:36:51 2013 us=430524 do1/111.111.111.111:9876 Data Channel Encrypt: Using 128 bit message hash 'MD5' for HMAC authentication
Wed Mar 13 22:36:51 2013 us=430554 do1/111.111.111.111:9876 Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Wed Mar 13 22:36:51 2013 us=430578 do1/111.111.111.111:9876 NOTE: --mute triggered...


Лог с клиента /var/log/openvpn.log
Wed Mar 13 16:36:29 2013 us=107885 14 variation(s) on previous 5 message(s) suppressed by --mute                                                                                     
Wed Mar 13 16:36:29 2013 us=107962 Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key                                                                           
Wed Mar 13 16:36:29 2013 us=107998 Data Channel Encrypt: Using 128 bit message hash 'MD5' for HMAC authentication                                                                    
Wed Mar 13 16:36:29 2013 us=108030 Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key                                                                           
Wed Mar 13 16:36:29 2013 us=108060 Data Channel Decrypt: Using 128 bit message hash 'MD5' for HMAC authentication                                                                    
Wed Mar 13 16:36:29 2013 us=108164 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA                                                                       
Wed Mar 13 16:36:29 2013 us=108247 [srv] Peer Connection Initiated with [AF_INET]222.222.222.222:9876                                                                        
Wed Mar 13 16:36:30 2013 us=293778 SENT CONTROL [srv]: 'PUSH_REQUEST' (status=1)                                                                                           
Wed Mar 13 16:36:30 2013 us=337261 PUSH: Received control message: 'PUSH_REPLY,route 10.10.10.0 255.255.255.0,topology net30,ping 10,ping-restart 120
,route 192.168.0.0 255.255.255.0,ifconfig 10.10.10.13 10.10.10.14'                                                                                                                   
Wed Mar 13 16:36:30 2013 us=337430 OPTIONS IMPORT: timers and/or timeouts modified                                                                                                   
Wed Mar 13 16:36:30 2013 us=337459 OPTIONS IMPORT: --ifconfig/up options modified                                                                                                    
Wed Mar 13 16:36:30 2013 us=337484 OPTIONS IMPORT: route options modified                                                                                                            
Wed Mar 13 16:36:30 2013 us=337801 ROUTE: default_gateway=UNDEF                                                                                                                      
Wed Mar 13 16:36:30 2013 us=340076 TUN/TAP device tun0 opened                                                                                                                        
Wed Mar 13 16:36:30 2013 us=340127 TUN/TAP TX queue length set to 100                                                                                                                
Wed Mar 13 16:36:30 2013 us=340203 /sbin/ifconfig tun0 10.10.10.13 pointopoint 10.10.10.14 mtu 1246                                                                                  
Wed Mar 13 16:36:30 2013 us=344493 /sbin/route add -net 192.168.0.0 netmask 255.255.255.0 gw 10.10.10.14                                                                             
Wed Mar 13 16:36:30 2013 us=346614 /sbin/route add -net 10.10.10.0 netmask 255.255.255.0 gw 10.10.10.14                                                                              
                                                                                                                                                                                                      
Wed Mar 13 16:36:30 2013 us=350834 Initialization Sequence Completed                                                                                                                 
Wed Mar 13 16:36:57 2013 us=470296 Replay-window backtrack occurred [1]                                                                                                              
Wed Mar 13 16:38:45 2013 us=412902 Replay-window backtrack occurred [2]                                                                                                              
Wed Mar 13 16:38:52 2013 us=399103 Replay-window backtrack occurred [3]                                                                                                              
Wed Mar 13 17:36:29 2013 us=315546 TLS: soft reset sec=-1 bytes=13833747/0 pkts=52365/0                                                                                              
Wed Mar 13 17:36:40 2013 us=64059 VERIFY OK: depth=1, /C=RU/ST=CA/L=city/O=srv/CN=srv_CA/name=admin/emailAddress=admin@example.com
                                                                                                                                                                        
Wed Mar 13 17:36:40 2013 us=64736 VERIFY OK: depth=0, /C=RU/ST=CA/L=city/O=srv/CN=srv/name=admin/emailAddress=admin@example.com
Wed Mar 13 17:36:54 2013 us=223993 Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Wed Mar 13 17:36:54 2013 us=224071 Data Channel Encrypt: Using 128 bit message hash 'MD5' for HMAC authentication
Wed Mar 13 17:36:54 2013 us=224105 NOTE: --mute triggered...


Что еще можно выложить ?

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

Я бы предположил что потери идут на уровне провайдера, но тогда почему через улицу потерь нет ?

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

af5 ★★★★★
()
Ответ на: комментарий от edyard

Выше ^^ правильная рекомендация. Если она не поможет:

Посмотрите, нет ли у вас проблем с роутингом или firewall'ом на обоих концах туннеля, посмотрите системные логи на предмет подозрительных записей.

zgen ★★★★★
()
Ответ на: комментарий от af5

Ну вариантов оперативно это попробовать нет.
Да и думаю, что udp при столь сильной потере пакетов работает лучше, нежели tcp.
Соединение с интернетом по adsl, попробую сменить модем, если ситуация не измениться, провайдера.
Просто нужно быть точно уверенным, что проблема не на нашей стороне.

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

Да и думаю, что udp при столь сильной потере пакетов работает лучше, нежели tcp

Это понятно, просто это такой тестовый workaround - замаскировать трафик под обычный https. А вот udp https не бывает, так что может и не прокатить.

af5 ★★★★★
()
Ответ на: комментарий от blind_oracle

может в одном из роутеров cpu на 100% загружен?

от этого тоже могут быть потери

victorb ★★
()

Подтверждаю, что провайдеры не любят udp.

У меня один провайдер как-то хитро рубит udp. Или по достижению определённого объёма или ещё как, но постоянно udp порт по которому идёт тунельный трафик начинает очень сильно резаться, но не наглухо, а так, что проходят около 10% пакетов. Если запускать тунель на другом порту, то всё хорошо работает сутки другие, а потом опять начинаются потери. Идти ругаться с провайдером мне не охото, поэтому раз в сутки скрипт назначает для тунеля новый порт.

mky ★★★★★
()
Ответ на: комментарий от mky

но не наглухо, а так, что проходят около 10% пакетов

Пров вряд ли режет. Ну просто нету таких настроек в промышленном сетевом оборудовании для «хитрого дропа». Ставить серваки с несколькими 10G картами для этого - сомнительная идея. На firewall от paloalto, fortinet и других тож такого нету. Даю 99,9% что пров непричем. Проверь, не забит ли с какой из сторон канал? может у тебя глючит сетевое оборудование или в нем есть специальные «фичи частичного дропа»? Например, частичный дроп пинга на ASA - это нормально. Сколько головняка отымел из-за этого.

andrew667 ★★★★★
()
Ответ на: комментарий от andrew667

Даю 99,9% что пров непричем.

Три девятки это круто :-)) Я знаю, что такое поведение как у меня реализовать сложно. Но я долго проверял, что режется только udp, и именно тот порт, по которому работает тунель. Ощущение, что провайдер по каким-то признакам признаёт порт «плохим» и весь трафик этого порта загоняет в шейпер с очень низкой полосой.

Когда по тунелю начинались большие потери пакетов, простое переключение тунеля на другой порт исправляет ситуацию, при этом по udp-порту, где был тунель, трафик так и остаётся с потерями, что проверял с помощью nc и tcpdump. 10% это взял так с потолка. Там поведение такое, что может секунд 30-60 вобще ничего по этому udp-порту не проходить, а потом несколько секунд все пакеты ходят. При этом по другим udp-портам пакеты ходят без потерь.

Больше всего похоже, что провайдер обрабатывая статистику выявляет udp-порты с которых идёт раздача торрентов и заворачивает их все (от всех абонентов) в один шейпер. Когда пакетов много шейпер и будет их дропать, торрентам не так критичны потери пакетов, поэтому абоненты особо не возмущаются. И такое в принципе реализуется без серверов с 10G сетёвками. Но может сделано что-то другое.

mky ★★★★★
()
Ответ на: комментарий от andrew667

Средний. Если верить том, что дано здесь http://yamobi.ru/posts/ekaterinburg_internet.html то на январь 2012 у него было 55 тыс. подключений.

Интерестно, что моя квартира подключена к этому же провайдеру, из дома по аналогичному тунелю я сливаю резервные копии. И в этом случае проблем не было. Возможно, что такое поведение udp сделано только для тарифов юрлиц.

mky ★★★★★
()
Ответ на: комментарий от mky

Механизм такой - если на твой аккаунт по радиусу передается соответствующий параметр, то тебя можно завернуть на нужную трассу, где ресурсы могут быть блокированы/частично блокированы сетевым экраном. На каждой из трасс можно применять свои фильтры. Но в любом случае делать частичный дроп - слабоумие. Если пров мелкий, то может будут мутить такую гадость пакетным фильтром на серваке, на который заворачивается трафик. По таким фокусам я не особый тебе помощник. Еще есть какие-то особые хитрые прокси, которые используются мобильными операторами. Попробуй порыть в этом направлении, если у тебя выдается айпишник из диапазона для LAN.

andrew667 ★★★★★
()
Последнее исправление: andrew667 (всего исправлений: 1)
Ответ на: комментарий от mky

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

andrew667 ★★★★★
()
Ответ на: комментарий от af5

Плюсую этого камрада.
Еще можно не 443, а какой-нибудь левый порт из верхних, но tcp обязательно. С udp частенько бывают проблемы.

pekmop1024 ★★★★★
()
Ответ на: комментарий от mky

Разумное предположение. У меня была схожая ситуация - в один прекрасный день через одного провайдера упала скорость pptp. Поменял на openvpn - скорость вернулась к тарифной.

anonymous
()
Ответ на: комментарий от zgen

Сделал так, потери сильно уменьшились

-t mangle -A OUTPUT -p udp --dport 9876 -j TOS --set-tos Minimize-Delay

Оставил заявку у провайдера, через час перезвонили, инженер говорит якобы у нас «нет баланса скорости» на порту (прием/отдача), чет там пошаманил, потери вообще исчезли.
Вот так :)

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

чет там пошаманил, потери вообще исчезли.

А если удалить вот это:

-t mangle -A OUTPUT -p udp --dport 9876 -j TOS --set-tos Minimize-Delay

потери вернутся?

zgen ★★★★★
()
Ответ на: комментарий от zgen

Сегодня специально проверял. Потери опять появляются %15-18, но в меньшей степени, было %25-%50.

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