диагностика openvpn
Dmitry E. Oboukhov
пинг между ними 5-10мс.
если установить ssh (или любое другое) соединение, то работает
устойчиво без лагов и сбоев.
между этими двумя хостами установил openvpn-канал. Так вот, если
пинговать через этот канал, то пинги идут длительностью 1000-5000мс, и
иногда потери в 10-30%. Иногда потерь нет.
Врубил логи в openvpn, никаких ошибок не пишет даже при уровне verb
равном 6. Пишет кучу сообщений "прочитал устройство/записал
устройство" с такой же частотой как и ping пишет информацию о своих
пакетах (то есть запись в секунду-пять). В итоге из лога причину
такого поведения не извлек.
Когда-то я задавал уже смежный с этой проблемой вопрос, но потом
проблема "сама рассосалась" а теперь вот опять всплыло...
как можно подиагностировать в чем проблема?
--
... mpd is off
. ''`. Dmitry E. Oboukhov
: :’ : email: un...@debian.org jabber://UN...@uvw.ru
`. `~’ GPGKey: 1024D / F8E26537 2006-11-21
`- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537
Dmitry E. Oboukhov
s> On 10/11/2010 10:18 PM, Dmitry E. Oboukhov wrote:
>> как можно подиагностировать в чем проблема?
s> tcpdump/wireshark
при потерях в пинге tcpdump иногда выдает вот такие сообщения:
22:36:05.966925 IP work.dhome.lan > gatework.dhome.lan: ICMP echo reply, id 14147, seq 4, length 64
22:36:06.923752 IP gatework.dhome.lan > work.dhome.lan: ICMP echo request, id 14147, seq 5, length 64
22:36:07.914952 arp who-has work.dhome.lan tell gatework.dhome.lan
22:36:07.931295 arp reply work.dhome.lan is-at ca:2f:64:3b:e4:c9 (oui Unknown)
22:36:07.931945 IP gatework.dhome.lan > work.dhome.lan: ICMP echo request, id 14147, seq 6, length 64
а так в целом весь дамп состоит из таких строк:
22:36:02.916939 IP gatework.dhome.lan > work.dhome.lan: ICMP echo request, id 14147, seq 1, length 64
22:36:02.954985 IP work.dhome.lan > gatework.dhome.lan: ICMP echo reply, id 14147, seq 1, length 64
22:36:03.918567 IP gatework.dhome.lan > work.dhome.lan: ICMP echo request, id 14147, seq 2, length 64
22:36:03.992537 IP work.dhome.lan > gatework.dhome.lan: ICMP echo reply, id 14147, seq 2, length 64
s> Вообще потеря пакетов на openvpn это что-то очень странное.
вот я погуглил и не нашел пока ни у кого аналогичных траблов.
sergio
> как можно подиагностировать в чем проблема?
tcpdump/wireshark
Вообще потеря пакетов на openvpn это что-то очень странное.
--
sergio.
--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/4CB357CE...@sergio.spb.ru
Nicholas
> Когда-то я задавал уже смежный с этой проблемой вопрос, но потом
> проблема "сама рассосалась" а теперь вот опять всплыло...
Заметил, что иногда бывают проблемы на определенных портах, помогает
переход с port 80 на 8080 и обратно.
--
Sincerely,
Nicholas
--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/i8vm17$p44$1...@dough.gmane.org
sergio
> при потерях в пинге tcpdump иногда выдает вот такие сообщения:
...
> arp who-has work.dhome.lan tell gatework.dhome.lan
> arp reply work.dhome.lan is-at ca:2f:64:3b:e4:c9 (oui Unknown)
...
У меня тоже такое есть.
А снаружи ничего подозрительного?
Попробуй поиграть с proto и dev.
--
sergio.
--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Dmitry E. Oboukhov
>> при потерях в пинге tcpdump иногда выдает вот такие сообщения:
>> arp who-has work.dhome.lan tell gatework.dhome.lan
>> arp reply work.dhome.lan is-at ca:2f:64:3b:e4:c9 (oui Unknown)
s> У меня тоже такое есть.
s> А снаружи ничего подозрительного?
s> Попробуй поиграть с proto и dev.
я переключался на протокол tcp, результат хуже. то есть вместо
1000-5000 пинги идут 2000-10000, да и потерь больше.
а вот с dev что можно поиграть?
у меня работает через tap0, настроить через tun у меня как-то не очень
какбы получилось
Artem Chuprina
> s> ...
> >> arp who-has work.dhome.lan tell gatework.dhome.lan
> >> arp reply work.dhome.lan is-at ca:2f:64:3b:e4:c9 (oui Unknown)
> s> ...
> s> У меня тоже такое есть.
>
> s> А снаружи ничего подозрительного?
>
> s> Попробуй поиграть с proto и dev.
>
> я переключался на протокол tcp, результат хуже. то есть вместо
> 1000-5000 пинги идут 2000-10000, да и потерь больше.
>
> а вот с dev что можно поиграть?
>
> у меня работает через tap0, настроить через tun у меня как-то не очень
> какбы получилось
Он у тебя бриджом настроен и арпы эти - внутри туннеля? А у arp-запросов
маленькие таймауты, они ж рассчитаны на хардверный ethernet... Может, в этом
проблема? А дальше, если кэш ARP проэкспайрился, ядро перед отправкой
IP-пакета шлет новый запрос. Если он стаймаутился, пакет дропается, со
следующим пакетом процедура повторяется.
Ну да, бридж ты через tun не настроишь.
--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/87aamkh5tc.wl%r...@ran.pp.ru
Oleg Motienko
On 11.10.2010 18:18, Dmitry E. Oboukhov wrote:Заметил, что иногда бывают проблемы на определенных портах, помогает переход с port 80 на 8080 и обратно.
Когда-то я задавал уже смежный с этой проблемой вопрос, но потом
проблема "сама рассосалась" а теперь вот опять всплыло...
Шейпер у провайдера, давят торенты?
Nicholas
Нет, с торрентами проблем никогда небыло.
Мне объясняли так: ддосят далекие сети на каких-то портах - эти порты
прижимают, временно, пока не разберутся.
Это, кстати, можно проверить - пакету можно точно задать маршрут и
посмотреть по какому маршруту что происходит.
http://www.opennet.ru/docs/RUS/ip_network/glava_4.html#_4_2
"Альтернативой одношаговому подходу является указание в пакете всей
последовательности маршрутизаторов, которые пакет должен пройти на своем
пути. Такой подход называется маршрутизацией от источника - Source
Routing. В этом случае выбор маршрута производится конечным узлом или
первым маршрутизатором на пути пакета, а все остальные маршрутизаторы
только отрабатывают выбранный маршрут, осуществляя коммутацию пакетов,
то есть передачу их с одного порта на другой. Алгоритм Source Routing
применяется в сетях IP только для отладки, когда маршрут задается в поле
Резерв (IP OPTIONS) пакета."
--
Sincerely,
Nicholas
--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/i9dje9$js7$1...@dough.gmane.org
Mikhail A Antonov
> и еще, есть ли утилиты (а-ля пинг) которые могли бы проиллюстрировать
> провайдеру наличие этой проблемы?
hping3 если я тебя правильно понял
--
Best regards,
Mikhail.
-
xmpp: ant...@stopicq.ru
www: http://www.antmix.pp.ru/
Dmitry E. Oboukhov
>>>> проблема "сама рассосалась" а теперь вот опять всплыло...
>>>>
>>>
>>> Заметил, что иногда бывают проблемы на определенных портах, помогает
>>> переход с port 80 на 8080 и обратно.
>>>
>>>
>> Шейпер у провайдера, давят торенты?
N> Нет, с торрентами проблем никогда небыло.
переключился на порт с номером на 500 меньше и проблема сильно
отличается: лаги другие, пинги другие. Однако присутствует.
Выключил апач, переключился на порт 80 и все проблемы "рассосались",
проблема только в том что порты 80, 443, 22 итп мне нужны для того для
чего они изначально предназначаются :)
вот теперь затеял переписку с провайдером на тему снять ограничения
для выбранного IP.
только тут как бы теперь другая проблема: неясно какой провайдер тут
вредит. и как это выяснить?
и еще, есть ли утилиты (а-ля пинг) которые могли бы проиллюстрировать
провайдеру наличие этой проблемы?
sergio
> Выключил апач, переключился на порт 80 и все проблемы "рассосались",
> проблема только в том что порты 80, 443, 22 итп мне нужны для того для
> чего они изначально предназначаются :)
и посмотреть как оно.
> вот теперь затеял переписку с провайдером на тему снять ограничения
> для выбранного IP.
А что за провайдер?
--
sergio.
--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Dmitry E. Oboukhov
>> проблема только в том что порты 80, 443, 22 итп мне нужны для того для
>> чего они изначально предназначаются :)
s> и посмотреть как оно.
>> вот теперь затеял переписку с провайдером на тему снять ограничения
>> для выбранного IP.
s> А что за провайдер?
провайдер уже ответил на запрос: подтвердили, что дескать да, есть у
них какая-то система ограничения траффика на "левые" с их точки зрения
порты. ну и для моего аккаунта они ее отключили (кругом винда же,
спамят ддосят итп, вот они бедные и вынуждены крутиться)
самое интересное что я долго пытался понять/подиагностировать что не
так с openvpn, а проблема внешняя :)
а провайдер - lanport.ru
Nicholas
> Выключил апач, переключился на порт 80 и все проблемы "рассосались",
> проблема только в том что порты 80, 443, 22 итп мне нужны для того для
> чего они изначально предназначаются :)
Добавить 1 ip это 1$ в месяц Ж) (у linode com например), небольшая цена
что бы избавиться от проблем в корне.
>
> только тут как бы теперь другая проблема: неясно какой провайдер тут
> вредит. и как это выяснить?
mtr - удобная программа что бы смотреть обычные пинги.
Большой список программ, полезных для анализа сети:
bwm-ng (объем трафика по интерфейсам с момента запуска)
iptraf (интерактивная, консольная, Network Statistics Utility )
ipac-ng
dig / nslookup / ns / host
netstat -iv (-n) (траффик)
netstat -r (route) netstat -s
iftop - ip потоки наглядно (!)
ntop - программа просмотра состояния и статистики передачи данных по сети
iptstate - трекинг сессий для iptables;
dnstop - (libpcap) кто и какие DNS запросы осуществляет в данный момент.
ip route flush cache /// echo 1 > /proc/sys/net/ipv4/route/flush /// ip
rule list
iptables -t mangle -nv -L
/ arp -a / arping ///
pset(8) - IP sets are a framework inside the Linux 2.4.x and 2.6.x
kernel which can be administered by the ipset(8) utility.
sysctl -a|grep conntr // conntrack -L >file /// conntrack -F сбросит
все записи /// conntrack -D -s ip удалить все записи по ip-шнику
opreport (oprofile) (opannotate / opreport -l /iptables ...)
netperf /// NetPiPe
iperf -s (server) /// Клиент iperf -c server_host (iperf - Internet
Protocol bandwidth measuring tool)
nttcp - Задача - в тестовых целях гонять трафик между
ethereal (Wireshark)
trafd (Trafd is a suite of tools to collect and visualize network
traffic statistics)
Другие похожие -like системы мониторинга трафика: Net, jnet, sn,
tcptrack, netwatch.
flowdumper /// tcpdump -i eth2
ipgrab / Ethereal
TCP_STREAM test
ip link list /// iwconfig /// tc qdisc show /// netstat -nl /// tcpdump
-n -i eth0
scli 192.168.1.1 "community-name" (show system) - snmp
feh -R <секунды> <урл> (мониторить url)
sendip
pktgen
nmap ... -sS (SYN-сканирование) -sU (UDP-сканирование) -sV (определить
запущенный на порту сервис)
unicornscan для распределенного сканирования портов /// firewalk
hping
hping3
--
Sincerely,
Nicholas
--
To UNSUBSCRIBE, email to debian-russ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/i9fboj$7ur$1...@dough.gmane.org