FreeBSD

[stvol 4]

Установил я СТГ все отлично все считает.Но возникла проблемка при авторизации повышаются пинги.

Например пингую сервер пакетами по 1500 показывает меньше 1 млсек авторизую и уже по 24 мс (если по 500 то 8 мс)Интерупт 0.4%

Это нормально? Это так нат работает? Или я что-то перемудрил в фаерволе? Раньше подобное было на другой машинке.И при нагрузке пинги взлетали очень сильно.Но теперь надо разобрался так как не в железе похоже дело.

Пните в правильном направлении буду благодарен.

[Kucher2 122]

http://local.com.ua/forum/topic/23451-пора-менять-железку/

http://local.com.ua/forum/topic/24355-freebsd-torrents/

[stvol 4]

Та не кажись не в этом дело.Я тестировал на тарифе 512кбит сейчас переключил в 2 мбита. И задержки стали по 6мс.Похоже это шейпер так отрабатывает.Увеличиваем скорость в 4 раза и задержки в 4 раза уменьшаются.Но вопрос остается открытым так у всех? Или мне нужно разбиратся с фаерволом.

[imroot 19]

скажу по собственному опыту:

не правельно приготовлен фаервол.

Как правильно?

ответ:

ipfw pipe 1 config bw 2124Kbit/s mask src-ip 0x000000ff
ipfw pipe 2 config bw 2124Kbit/s mask dst-ip 0x000000ff
ipfw add 399 divert 8668 ip4 from any to any via fxp0
ipfw add 398 allow ip from any to any via lo0
ipfw add 1 pipe 1 ip from 192.168.1.20 to any out
ipfw add 400 pipe 2 ip from any to 192.168.1.20 in
ipfw add 10000 allow ip from any to 192.168.1.20
ipfw add 10001 allow ip from 192.168.1.20 to any

вот ровный пинг тебе обеспечен, dsl`ем раздаёш?

[Kucher2 122]

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

скажу по собственному опыту:

не правельно приготовлен фаервол.

Как правильно?

ответ:

imroot, ой ли Ваш вариант правильный, особенно учитывая использование divert на старенький natd и кучу pipe на каждого юзера.

Я не говорю что это не будет работать, но уж если появился ipfw nat...

 

Теперь 2 момента:

1. Почему у Вас в примере 0x000000ff, а не 0xffffffff ? Имеет значеие? Проверяли?

2. Для Вашего примера - есть ли принципиальная разница между "to any out" и "to any via ${int_if}" ?

[natiss 16]

 

Теперь 2 момента:

1. Почему у Вас в примере 0x000000ff, а не 0xffffffff ? Имеет значеие? Проверяли?

2. Для Вашего примера - есть ли принципиальная разница между "to any out" и "to any via ${int_if}" ?

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

[stvol 4]

Да Дслем раздаю.

Ну у меня тоже кошмарные но на моем количестве абонов не очень то и ресурсоемко.А вот задержки напрягают.

У меня тоже увы по пайпу на человека.Но глянье плз где трабл.

 

 

0555 pipe 640 ip from any to 192.168.0.34

00571 pipe 800 ip from any to 192.168.0.65

07542 divert 8668 ip from 192.168.0.34 to any

07700 divert 8778 ip from 192.168.0.65 to any

10000 fwd 172.17.17.1 ip from 172.17.17.2 to any

10010 fwd 174.17.17.1 ip from 174.17.17.2 to any

10020 divert 8778 ip from any to 174.17.17.2

10030 divert 8668 ip from any to 172.17.17.2

65535 allow ip from any to any

 

172..1 и 174...1 роутеры а 172..2 и 174..2 сетевые.

[natiss 16]

Да Дслем раздаю.

Ну у меня тоже кошмарные но на моем количестве абонов не очень то и ресурсоемко.А вот задержки напрягают.

У меня тоже увы по пайпу на человека.Но глянье плз где трабл.

 

 

0555 pipe 640 ip from any to 192.168.0.34

00571 pipe 800 ip from any to 192.168.0.65

07542 divert 8668 ip from 192.168.0.34 to any

07700 divert 8778 ip from 192.168.0.65 to any

10000 fwd 172.17.17.1 ip from 172.17.17.2 to any

10010 fwd 174.17.17.1 ip from 174.17.17.2 to any

10020 divert 8778 ip from any to 174.17.17.2

10030 divert 8668 ip from any to 172.17.17.2

65535 allow ip from any to any

 

172..1 и 174...1 роутеры а 172..2 и 174..2 сетевые.

 

такой конфиг писали в прошлом тысячелетии когда было две 128 к выделенки

к сожалению в интернете еще много примеров этого кошмара

pipe {ip} -> pipe tablearg

from any to {ip } -> from any to table // out xmit {iface}

аналогично in recv {iface}

natd вообще убираем

вместо него

ipnat

map {iface2} {gray-net} -> 172.17...

..

sysctl net.inet.ip.fw.one_pass=1

 

дегенертские форвард заменить на setfib

 

и будет счастье!

[stvol 4]

Спасибо большое.Но это все осваивать.... и осваивать.Нужно чтоб хоть как-то бегало да и абонов у меня больше сотни врядли будет.

Подскажите тогда чей конфиг лучше? мой или Imroota.Если его то буду переделывать.

[Kucher2 122]

0555 pipe 640 ip from any to 192.168.0.34
00571 pipe 800 ip from any to 192.168.0.65
07542 divert 8668 ip from 192.168.0.34 to any
07700 divert 8778 ip from 192.168.0.65 to any
10000 fwd 172.17.17.1 ip from 172.17.17.2 to any
10010 fwd 174.17.17.1 ip from 174.17.17.2 to any
10020 divert 8778 ip from any to 174.17.17.2
10030 divert 8668 ip from any to 172.17.17.2
65535 allow ip from any to any

Зачем у вас четыре диверта, позвольте узнать?

Трафик на natd заворачивается на внешнем ИФ:

ipfw add 10 divert natd ip from any to any via ${ext_if}

И всё.

divert идёт в самом начале, потом идёт уже pipe и т.д.

 

Если у Вас FreeBSD 7 и выше - советую освоить ipfw nat, он быстрее и проще. Ну и таблицы. Там примерно так:

 

ipfw nat 1 config log ip ${nat_ip} same ports

ipfw add 100 nat 1 ip from table\(1\) to any via ${ext_if}

 

А в таблицу 1 - загоняете всю свою подсеть, например

ipfw add table 1 add 192.168.0.0/24

 

И правила для всей подсети будут занимать всего 2 строки:

 

ipfw 200 add allow ip from table\(1\) to any via ${int_if}
ipfw 210 add allow ip from any to table\(1\) via ${int_if}

 

В итоге имеем всего 2 правила хоть на сотню клиентов, хоть на одного.

 

Просто когда хотите пускать в Инет по ip - в таблицу не подсеть заносится, а ip юзера.

Заносится через скрипт OnConnect, удаляется - через OnDisconnect.

[natiss 16]

 

 

Просто когда хотите пускать в Инет по ip - в таблицу не подсеть заносится, а ip юзера.

Заносится через скрипт OnConnect, удаляется - через OnDisconnect.

жаль нельяз в таблицу внести полноценыный src/dst например 2 или 3 айпи

а то, если надо разделить канал между 2-мя и более айпи не подряд, вся идиллия рушится

 

а насчет форвардов, я думаю дело в том, что тут есть 2 канала, которые надо балансировать, вот при петре первом это делали убирая маршрут к 0/0 и добавляя вот так дегенератские фвд на шлюзы.

сейчас в фрибсд есть альтернативный механизм setfib.

[Kucher2 122]

Меня сильно интересует 2 вопроса.

 

1. Есть ли принципиальная разница между вариантами и как правильнее:

from 192.168.1.20 to any out

и

from 192.168.1.20 to any via ${int_if}

 

2. Есть ли принципиальная разница между вариантами и как правильнее:

ipfw pipe 1 config bw 2124Kbit/s mask src-ip 0x000000ff

и

ipfw pipe 1 config bw 2124Kbit/s mask src-ip 0xffffffff

[adeep 212]

Меня сильно интересует 2 вопроса.

 

1. Есть ли принципиальная разница между вариантами и как правильнее:

from 192.168.1.20 to any out

и

from 192.168.1.20 to any via ${int_if}

под первое правило попадают пакеты с адреса 192.168.1.20 и выходящие с роутера на любом интерфейсе

под второе правило попадают теже самые пакеты, но выходящие только с определенного интерфейса. разницу ощущаете?

С точки зрения производительности - добавляется еще одна проверка на интерфейс.

 

UPD: во втором случае более правильно писать out xmit - это четко определяет что вы ищете выходящие пакеты на передающем интерфейсе таком-то.

согласно ману:

            The via keyword causes the interface to always be checked.  If
            recv or xmit is used instead of via, then only the receive or
            transmit interface (respectively) is checked.  By specifying
            both, it is possible to match packets based on both receive and
            transmit interface, e.g.:

                  ipfw add deny ip from any to any out recv ed0 xmit ed1

            The recv interface can be tested on either incoming or outgoing
            packets, while the xmit interface can only be tested on outgoing
            packets.  So out is required (and in is invalid) whenever xmit is
            used.

 

2. Есть ли принципиальная разница между вариантами и как правильнее:

ipfw pipe 1 config bw 2124Kbit/s mask src-ip 0x000000ff

и

ipfw pipe 1 config bw 2124Kbit/s mask src-ip 0xffffffff

да, в маске по которой создаются динамические pipe.

На производительность это не влияет.

[adeep 212]

Установил я СТГ все отлично все считает.Но возникла проблемка при авторизации повышаются пинги.

Например пингую сервер пакетами по 1500 показывает меньше 1 млсек авторизую и уже по 24 мс (если по 500 то 8 мс)Интерупт 0.4%

Это нормально? Это так нат работает? Или я что-то перемудрил в фаерволе? Раньше подобное было на другой машинке.И при нагрузке пинги взлетали очень сильно.Но теперь надо разобрался так как не в железе похоже дело.

Пните в правильном направлении буду благодарен.

Я тут посмотрел что никто так ответа не дал на исходный вопрос. Попробую пояснить.

 

Тариф 512кбит/с означает что в трубе пакет размером 512кбит будет передаваться 1 секунду.

 

Теперь считаем: пакет в 1500 байт = 12000бит

Теперь делим размер нашего пакета на скорость и получаем время прохождения: 12000 / 512000 ~ 23,5мс.

 

ЧТД.

[laffytaffy 84]

 

Я тут посмотрел что никто так ответа не дал на исходный вопрос. Попробую пояснить.

 

Тариф 512кбит/с означает что в трубе пакет размером 512кбит будет передаваться 1 секунду.

 

Теперь считаем: пакет в 1500 байт = 12000бит

Теперь делим размер нашего пакета на скорость и получаем время прохождения: 12000 / 512000 ~ 23,5мс.

 

ЧТД.

 

т.е. создается пайп для всего трафика и для локального тоже судя по всему, отсюда и задержки...

[adeep 212]

т.е. создается пайп для всего трафика и для локального тоже судя по всему, отсюда и задержки...

топикстартер не уточнил конфигурации FW. Но судя по совпавшему результату так оно и есть

[Kucher2 122]

Kucher2 (04 Декабрь 2010 - 21:00) писал:

Меня сильно интересует 2 вопроса.

 

1. Есть ли принципиальная разница между вариантами и как правильнее:

from 192.168.1.20 to any out

 

и

from 192.168.1.20 to any via ${int_if}

 

 

под первое правило попадают пакеты с адреса 192.168.1.20 и выходящие с роутера на любом интерфейсе

под второе правило попадают теже самые пакеты, но выходящие только с определенного интерфейса. разницу ощущаете?

С точки зрения производительности - добавляется еще одна проверка на интерфейс.

 

UPD: во втором случае более правильно писать out xmit - это четко определяет что вы ищете выходящие пакеты на передающем интерфейсе таком-то.

согласно ману:

The via keyword causes the interface to always be checked. If

recv or xmit is used instead of via, then only the receive or

transmit interface (respectively) is checked. By specifying

both, it is possible to match packets based on both receive and

transmit interface, e.g.:

 

ipfw add deny ip from any to any out recv ed0 xmit ed1

 

The recv interface can be tested on either incoming or outgoing

packets, while the xmit interface can only be tested on outgoing

packets. So out is required (and in is invalid) whenever xmit is

used.

Т.е.

from 192.168.1.20 to any out

таки некорректен?

А

from 192.168.1.20 to any out xmit via ${int_if}

наиболее производителен с точки зрения поставленной задачи, так?

[natiss 16]

 

Т.е.

from 192.168.1.20 to any out

таки некорректен?

А

from 192.168.1.20 to any out xmit via ${int_if}

наиболее производителен с точки зрения поставленной задачи, так?

производительный файрволл строится по принципу чем больше пакетов match тем выше правило, к этому надо стремится

приемы оптимизации - последовательная обработка сначала трафика на внешнем ифейсе, потом на внутреннем

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

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

[adeep 212]

нат должен делать айпифилтер или пф, во всяком случае таково мое убеждение.

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

 

вы похоже еще не выросли за пределы одноядерных машин. для вас - это хорошее решение. но как только вам понадобится поставить роутер помощнее ( а любое современное железо содержит больше одного ядра) можете с ipf/pf прощаться сразу.

[Mobil 66]

нат должен делать айпифилтер или пф, во всяком случае таково мое убеждение.

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

 

вы похоже еще не выросли за пределы одноядерных машин. для вас - это хорошее решение. но как только вам понадобится поставить роутер помощнее ( а любое современное железо содержит больше одного ядра) можете с ipf/pf прощаться сразу.

 

Это почему так сразу ??? pf натил очень долго га 2х ядерном Интеле и никаких с этим проблем у него не было...

[Kucher2 122]

natiss - ну, у меня видимо был частный случай.

Схема была как раз такая, как Вы и предлагаете - pf + NAT.

В итоге всё закончилось потерей пакетов.

При переходе на IPFW NAT это ушло, хотя высокие пинги я по прежнему иногда наблюдал.

К сожалению пока не могу поймать этот момент, но надеюсь на то что это придёт и я пойму "какого чёрта".

 

За напоминаение о схеме обработки сначала большего трафика, затем меньшего - спасибо.

[stvol 4]

Установил я СТГ все отлично все считает.Но возникла проблемка при авторизации повышаются пинги.

Например пингую сервер пакетами по 1500 показывает меньше 1 млсек авторизую и уже по 24 мс (если по 500 то 8 мс)Интерупт 0.4%

Это нормально? Это так нат работает? Или я что-то перемудрил в фаерволе? Раньше подобное было на другой машинке.И при нагрузке пинги взлетали очень сильно.Но теперь надо разобрался так как не в железе похоже дело.

Пните в правильном направлении буду благодарен.

Я тут посмотрел что никто так ответа не дал на исходный вопрос. Попробую пояснить.

 

Тариф 512кбит/с означает что в трубе пакет размером 512кбит будет передаваться 1 секунду.

 

Теперь считаем: пакет в 1500 байт = 12000бит

Теперь делим размер нашего пакета на скорость и получаем время прохождения: 12000 / 512000 ~ 23,5мс.

 

ЧТД.

 

Спасибо!Очень благодарен за ответ.То что надо.

[natiss 16]

нат должен делать айпифилтер или пф, во всяком случае таково мое убеждение.

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

 

вы похоже еще не выросли за пределы одноядерных машин. для вас - это хорошее решение. но как только вам понадобится поставить роутер помощнее ( а любое современное железо содержит больше одного ядра) можете с ipf/pf прощаться сразу.

вы предлагаете натд?

давайте так, сколько может пронатить айпинат на ядре 3 ггц?

а для производительных решений я позиционировал многоядерный npf

[natiss 16]

natiss - ну, у меня видимо был частный случай.

Схема была как раз такая, как Вы и предлагаете - pf + NAT.

В итоге всё закончилось потерей пакетов.

При переходе на IPFW NAT это ушло, хотя высокие пинги я по прежнему иногда наблюдал.

К сожалению пока не могу поймать этот момент, но надеюсь на то что это придёт и я пойму "какого чёрта".

 

За напоминаение о схеме обработки сначала большего трафика, затем меньшего - спасибо.

а какой у Вас pps натится? ipfw nat очень коварная штука

столкнетесь с тем, что ipfw show nat ответит socket not allowed или как-то так, не помню уже...

у pf еще такой плюс - как возможность натить сразу целым блоком айпи по хэшу

так что либо ждем появленяи в freebsd npf. либо ставим netbsd 5.1 - это тоже bsd

[Kucher2 122]

а какой у Вас pps натится? ipfw nat очень коварная штука

http://local.com.ua/forum/topic/23451-%d0%bf%d0%be%d1%80%d0%b0-%d0%bc%d0%b5%d0%bd%d1%8f%d1%82%d1%8c-%d0%b6%d0%b5%d0%bb%d0%b5%d0%b7%d0%ba%d1%83/page__view__findpost__p__187726

Не знаю, не верю я всяким портированным приблудам типа pf.

Тариф 512кбит/с означает что в трубе пакет размером 512кбит будет передаваться 1 секунду.

Эм...

Вот пинг без шейпа (канал около 100Мбит/с)

ping ya.ru -t -l 1000

Обмен пакетами с ya.ru [87.250.251.3] с 1000 байтами данных:
Ответ от 87.250.251.3: число байт=1000 время=40мс TTL=55
Ответ от 87.250.251.3: число байт=1000 время=40мс TTL=55
Ответ от 87.250.251.3: число байт=1000 время=40мс TTL=55
Ответ от 87.250.251.3: число байт=1000 время=39мс TTL=55
Ответ от 87.250.251.3: число байт=1000 время=38мс TTL=55
Ответ от 87.250.251.3: число байт=1000 время=38мс TTL=55
Ответ от 87.250.251.3: число байт=1000 время=38мс TTL=55
Ответ от 87.250.251.3: число байт=1000 время=40мс TTL=55
Ответ от 87.250.251.3: число байт=1000 время=39мс TTL=55

 

Это пинг с шейпом на 256Кбит/с:

ping ya.ru -t -l 1000

Обмен пакетами с ya.ru [87.250.251.3] с 1000 байтами данных:
Ответ от 87.250.251.3: число байт=1000 время=76мс TTL=55
Ответ от 87.250.251.3: число байт=1000 время=76мс TTL=55
Ответ от 87.250.251.3: число байт=1000 время=74мс TTL=55
Ответ от 87.250.251.3: число байт=1000 время=74мс TTL=55
Ответ от 87.250.251.3: число байт=1000 время=76мс TTL=55
Ответ от 87.250.251.3: число байт=1000 время=73мс TTL=55
Ответ от 87.250.251.3: число байт=1000 время=74мс TTL=55
Ответ от 87.250.251.3: число байт=1000 время=75мс TTL=55
Ответ от 87.250.251.3: число байт=1000 время=76мс TTL=55

 

Вот.

 

При этом если пинговать стандартным размером пакета - пинг падает до 38-40мс, потому что пакеты почти не не дропаются шейпом, по идее.