Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

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

    Russian
    4
    9
    5.3k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • S
      schmel
      last edited by

      Приветствую, филиалы соединены через 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 интерфейс вообще не шейпировался? Или может дело не в этом?

      1 Reply Last reply Reply Quote 0
      • D
        dvserg
        last edited by

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

        SquidGuardDoc EN  RU Tutorial
        Localization ru_PFSense

        1 Reply Last reply Reply Quote 0
        • S
          schmel
          last edited by

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

          1 Reply Last reply Reply Quote 0
          • D
            dr.gopher
            last edited by

            @schmel:

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

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

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

            FAQ PfSense 2.0

            И не забываем про Adblock дабы не видеть баннеров.

            И многое другое на www.thin.kiev.ua

            1 Reply Last reply Reply Quote 0
            • S
              schmel
              last edited by

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

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

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

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

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

              1 Reply Last reply Reply Quote 0
              • G
                gr0mW
                last edited by

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

                1 Reply Last reply Reply Quote 0
                • S
                  schmel
                  last edited by

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

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

                  1 Reply Last reply Reply Quote 0
                  • G
                    gr0mW
                    last edited by

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

                    1 Reply Last reply Reply Quote 0
                    • S
                      schmel
                      last edited by

                      @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 интерфейса все равно будет действовать шейпер, в какой бы интерфейс и в какие бы подсети не отправлялись пакеты?

                      1 Reply Last reply Reply Quote 0
                      • First post
                        Last post
                      Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.