Pfsense большой пинг



  • Приветствую, филиалы соединены через OpenVPN на Pfsense 2.0 x86.
    Pfsense так же является шлюзом для сотрудников. На нем поднят шейпер c CBQ со своими правилами (режущим p2p), icmp, http, dns, SMB - выставлен наивысший приоритет.
    Возможно под эти правила попадает и OpenVPN.
    Когда шлюзы перезагрузили, то трафик по началу идет без задержек, как только народ начинает пользоваться ресурсами сети - бац, пинги под 1500мс и жуткие тормоза сетевых приложений. Скорость между филиалами около 80Мб\с (внутренняя в сети провайдера). При этом пинг на внешние ресурсы интернета идет нормально (все в пределах 30-70мс)

    Ответ от 192.168.2.11: число байт=32 время=4мс TTL=126
    Ответ от 192.168.2.11: число байт=32 время=4мс TTL=126
    Ответ от 192.168.2.11: число байт=32 время=2мс TTL=126
    Ответ от 192.168.2.11: число байт=32 время=3мс TTL=126
    Ответ от 192.168.2.11: число байт=32 время=4мс TTL=126
    Ответ от 192.168.2.11: число байт=32 время=4мс TTL=126
    Ответ от 192.168.2.11: число байт=32 время=4мс TTL=126
    Ответ от 192.168.2.11: число байт=32 время=4мс TTL=126
    
    Статистика Ping для 192.168.2.11:
        Пакетов: отправлено = 43, получено = 43, потеряно = 0
        (0% потерь)
    Приблизительное время приема-передачи в мс:
        Минимальное = 2мсек, Максимальное = 96 мсек, Среднее = 7 мсек
    Control-C
    ^C
    C:\Users\schmel.GBU>ping -t 192.168.2.11
    
    Обмен пакетами с 192.168.2.11 по с 32 байтами данных:
    Ответ от 192.168.2.11: число байт=32 время=841мс TTL=126
    Ответ от 192.168.2.11: число байт=32 время=766мс TTL=126
    Ответ от 192.168.2.11: число байт=32 время=998мс TTL=126
    Ответ от 192.168.2.11: число байт=32 время=87мс TTL=126
    Ответ от 192.168.2.11: число байт=32 время=685мс TTL=126
    
    Статистика Ping для 192.168.2.11:
        Пакетов: отправлено = 15, получено = 14, потеряно = 1
    
    

    Из за чего может быть такой большой пинг в OpenVPN сети?
    Возможно ли сделать так, чтобы OpenVPN интерфейс вообще не шейпировался? Или может дело не в этом?



  • Думаю можно, протокол TCP/UDP порт 1194 .



  • ок, попробую. Есть ли какая нибудь программа для тестирования скорости канала между 2мя хостами? (Ну кроме как файлы перекидывать друг с друга)



  • @schmel:

    Есть ли какая нибудь программа для тестирования скорости канала между 2мя хостами?

    Bandwidth test tool for Windows
    www.mikrotik.com/download/btest.exe

    Дока
    http://www.youtube.com/watch?feature=player_embedded&v=pWAIeaBl4vE



  • это под микротик инструкция, но все равно спасибо.

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

    Потестил, добавил правило во floating на порт 1194 - в трубу с самой большой пропускной способностью.
    Но все равно ничего не поменялось, попробовал удалить шейпер, скорость поднялась, но не намного. По UDP протоколу связаться не удалось, хотя порты все открыты.
    Стоит ли шейпировать WAN интерфейс? Ведь все равно если на LAN выставлено ограничение qInternet - то выше него не прыгнут.

    Вот скриншоты:
    https://www.dropbox.com/sh/eztrvnmj5uc4zx5/M-d2FAzI4-

    Может все дело в OpenVPN



  • Если включено lzo – попробуйте отключить



  • Если включено lzo – попробуйте отключить

    Попробовал, udp трафик пошел, но после 10 сек, соединение обрывается и теряется связь с клиентом OpenVPN. После 10-15 сек. связь восстанавливается.
    Скорость примерно на том же уровне ~10-11Мб\с через openvpn клиента.
    Проверил напрямую без шлюза (на серверах прописал статические ip от провайдера) - udp трафик пошел без обрыва, хотя иногда приложение "вылетало" под Windows Server 2008R2. Скорость не намного выше, может на пару мегабит. Значит дело именно в шейпере.
    Перечитал вики, но ничего толком не нашел на этот счет. Если создается шейпер, то он действует на интерфейс как я понял, и максимум что можно сделать - это дать трубу побольше, но все равно будет резаться. Можно попробовать сделать OpenVPN не через tun, а настраивать мостом (tap), либо что-то еще. Может появится еще один интерфейс на который можно не ставить шейпер. Но я этого еще не делал,
    есть ли у кого опыт в этой настройке?



  • У Вас симметричный канал? А то у меня на ассиметричном канале клиенты подключаються как 10 мбит. И какое железо на шлюзах (какая загрузка проца при передаче).Возможно мощности не хватает. Попробуйте шифрование BF-CBC 128 bit а так же без шифрования.
    Для интереса можете почитать http://www.etegro.ru/articles/encrypted-gigabit
    Ну и https://community.openvpn.net/openvpn/wiki/Gigabit_Networks_Linux



  • @gr0mW:

    У Вас симметричный канал? А то у меня на ассиметричном канале клиенты подключаються как 10 мбит. И какое железо на шлюзах (какая загрузка проца при передаче).Возможно мощности не хватает.

    Спасибо за ссылки - прочту.
    Канал до прова ассиметричный (25 мб\с - входящий, 80 исходящий.) Железки - одна VM ESXi с Intel Xeon 5520, 1Гб RAM., а вторая - Intel Celeron 1.5 Ггц, 1Gb DDR (это сервер OpenVPN). Вообще это checkpoint http://forum.pfsense.org/index.php/topic,51361.0.html  на который накатили pfsense, раньше тоже VM была с Intel Xeon 5520, 1Гб RAM, но там тоже такая же проблема была.
    Нагрузку нормально держит: Вот top при перекачке трафика:

    last pid: 36973;  load averages:  0.18,  0.06,  0.02  up 0+01:12:38    17:05:31
    86 processes:  2 running, 71 sleeping, 13 waiting
    
    Mem: 35M Active, 16M Inact, 50M Wired, 1000K Cache, 48M Buf, 886M Free
    Swap: 
    
      PID USERNAME PRI NICE   SIZE    RES STATE    TIME   WCPU COMMAND
       10 root     171 ki31     0K     8K RUN     68:40 93.99% idle
        0 root     -16    0     0K    88K sched    1:56  0.00% {swapper}
        0 root     -68    0     0K    88K -        0:20  0.00% {em3 taskq}
        0 root     -68    0     0K    88K -        0:14  0.00% {em0 taskq}
    60719 root      45    0  6140K  4488K select   0:11  0.00% openvpn
       11 root     -64    -     0K   104K WAIT     0:07  0.00% {irq14: ata0}
    48363 root      76    0 54784K 21244K accept   0:04  0.00% php
       11 root     -32    -     0K   104K WAIT     0:04  0.00% {swi4: clock}
    48224 root      47    0 53760K 18940K piperd   0:04  0.00% php
       13 root     -16    -     0K     8K -        0:03  0.00% yarrow
        0 root     -68    0     0K    88K -        0:03  0.00% {em1 taskq}
        4 root      -8    -     0K     8K -        0:03  0.00% g_down
       11 root     -68    -     0K   104K WAIT     0:02  0.00% {irq16: em0 uhci0}
    18109 root      44    0  4948K  2400K select   0:02  0.00% syslogd
        0 root     -68    0     0K    88K -        0:01  0.00% {dummynet}
    

    Тут скорее всего и правда дело в шейпинге.
    Еще такой вопрос: OpenVPN настроен в режиме tun. В интерфейсах можно сделать assign ovpn1 - тогда появится интерфейс OPT4. Вот на него можно выставить отдельную полосу, но как только он появляется openvpn падает. Так зачем он нужен - для tap соединений?

    **UPD:**Впринципе решилось. Настроил HBCQ в качестве шейпера (раньше CBQ использовал), трубке p2p поставил upperlimit 60%. Трафик кое-как да побежал, пинги на уровне, правда и торренты теперь открыты, но хоть скорость внутри VPN будет более - менее. Будет ли правильным шаг - отказ от tun и заменой на tap интерфейсы? Или может как-то в правилах можно прописать, чтобы отдельные подсети не шейпились, ведь получается, что даже использовав tap интерфейс, на пользователей с LAN интерфейса все равно будет действовать шейпер, в какой бы интерфейс и в какие бы подсети не отправлялись пакеты?


Locked