[Elisium]

Апну старую тему.

Есть пул внешних адресов х.х.60.0/22, разделён на четыре блока по /24.

Есть нат на pf source-hash в х.х.63.0/24 пул внешних ипов. То есть используется ПОСЛЕДНИЙ блок из четырёх.

С недавних пор некоторые клиенты (буквально с пару штук, то есть те, которых это действительно волнует) заметили, что не могут ни играть в онлайн игры, ни использовать клиент-банк/итд.

Выяснилось, что эти клиенты видны в инете под адресом х.х.63.255.

Тоесть, х.х.63.255 это броадкаст адрес для нашего пула /22.

 

В связи с этим вопрос - можно ли както указать в pf source-hash НЕ ВЫДАВАТЬ определенные адреса из пула ?

Например, первый и последний из пула (0 и 255)??

Может есть какой либо обходной вариант ? Ибо пф пока всем устраивает и полтора ГБ трафика проруливает нормально.

[John_obn]

Есть нат на pf source-hash в х.х.63.0/24 пул внешних ипов. То есть используется ПОСЛЕДНИЙ блок из четырёх.

В связи с этим вопрос - можно ли както указать в pf source-hash НЕ ВЫДАВАТЬ определенные адреса из пула ?

Например, первый и последний из пула (0 и 255)??

Может есть какой либо обходной вариант ? Ибо пф пока всем устраивает и полтора ГБ трафика проруливает нормально.

В чем проблема с адресом 255? Как у вас навешена эта /24 на эту машину с натом? на какой то интерфейс или статиком в null ?

[Elisium]

В чем проблема с адресом 255? Как у вас навешена эта /24 на эту машину с натом? на какой то интерфейс или статиком в null ?

Адреса от х.х.63.1/32 до х.х.63.254/32 висят на Loopback интерфейсе машинки с НАТом.

На НАТ статиком от БГП заруливается блок х.х.63.0/24 и он же отдельно от нашего основного /22 анонсится с препендами аплинку (для балансировки).

п.с. Проблема именно в этом адресе в последнем блоке /24. На других НАТах проблем с 255м адресом в своих /24х блоках нет.

[John_obn]

Не надо навешивать эти адреса на лупбэк. Подозреваю в этом и есть проблема.

IMHO правильнее зароутить целиком подсеть на Null0. У нас в Quagga/Zebra сделано так:

ip route 1.1.1.0/24 Null0

У нас такая схема работает отлично.

Если на других роутерах и при вашей схеме все работает и нет проблем с .255 адресом, то проверьте правила фаерволлов. Но лучше попробуйте предложеный мной вариант.

[Dyr]

Elisium, мы до недавнего времени использовали конструкцию с таблицей, в которой перечислили все доступные ip-адреса. Так, думаю, и вам будет проще.

 

dst_nat1="93.92.199.0/24"
dst_nat2="93.92.199.252/29" 


table <dst_nat1> {$dst_nat1, !$dst_nat2} 

nat on $ext_if from <allow-nat> to any -> <dst_nat1> static-port sticky-address round-robin 

 

Потом, правда, что-то поломали при апгрейде сети и не стали разбираться, раскидали по разным серверам. :)

Изменено 19 мая, 2011 пользователем Dyr

[Elisium]

Elisium, мы до недавнего времени использовали конструкцию с таблицей, в которой перечислили все доступные ip-адреса. Так, думаю, и вам будет проще.

 

dst_nat1="93.92.199.0/24"
dst_nat2="93.92.199.252/29" 


table <dst_nat1> {$dst_nat1, !$dst_nat2} 

nat on $ext_if from <allow-nat> to any -> <dst_nat1> static-port sticky-address round-robin 

 

Потом, правда, что-то поломали при апгрейде сети и не стали разбираться, раскидали по разным серверам. :)

 

Спасибо, вариант интересный )

Просто, если я правильно помню, round-robin выдает адреса рандомно со всего пула РАЗНЫМ юзерам.

А source-hash один и тот же внешний адрес сопоставляет с одним и тем же серым адресом.

Не хочется доставлять много радости любителям игры в CS, не то так и весь свободный пул перебанят (((

[Elisium]

Не надо навешивать эти адреса на лупбэк. Подозреваю в этом и есть проблема.

IMHO правильнее зароутить целиком подсеть на Null0. У нас в Quagga/Zebra сделано так:

ip route 1.1.1.0/24 Null0

У нас такая схема работает отлично.

Если на других роутерах и при вашей схеме все работает и нет проблем с .255 адресом, то проверьте правила фаерволлов. Но лучше попробуйте предложеный мной вариант.

 

Если НЕ навешать эти адреса куда-нибуть на ифейс, то при данной схеме возникает нехилый арп-шторм.

Тут гдето даже темка была про это.

п.с. Вся подсеть и так зарулена в Null0 в Квагге.

п.п.с. Вдобавок, плюс такой схемы, что внешние ипы, выданые через бинат, видно изнутри сети (пинги/доступ итд).

[John_obn]

Откуда должен взяться arp шторм?

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

по поводу p.p.s. - ни разу никому из наших абонентов это не пригодилось. нам тоже.

[Elisium]

Вот в ЭТОЙ же теме:

вылез кстати очень интересный глюк при использовании pf в качестве штуковины делающей nat на пул адресов: в сети сразу появилось куча широковещательного arp трафика от брасов в котором снифером были увидены постоянные попытки брасов найти несуществующие адреса из пулов. Кто как кстати выкручивается в такой ситуации? можно все эти адреса приколотить к какому нибудь интерфейсу -- по идее можно к внешнему интерфейсу браса, но тут сразу взрастёт нагрузка на постоянно дёргаемый драйвер сетевухи, есть идея привернуть эти адреса к lo0

на производительности особо не сказалось, если не считать нагрузку от торентщиков <b>которые смогли в такой позе через нат у друг друга качать</b>.

[vlad11]

вылез кстати очень интересный глюк при использовании pf в качестве штуковины делающей nat на пул адресов: в сети сразу появилось куча широковещательного arp трафика от брасов в котором снифером были увидены постоянные попытки брасов найти несуществующие адреса из пулов. Кто как кстати выкручивается в такой ситуации? можно все эти адреса приколотить к какому нибудь интерфейсу -- по идее можно к внешнему интерфейсу браса, но тут сразу взрастёт нагрузка на постоянно дёргаемый драйвер сетевухи, есть идея привернуть эти адреса к lo0

 

Этот блок адресов должен быть прикручен на lo0 головного роутера.

А на брасах должна быть поднята ospf (BRAS <--> router) с этим блоком.

Чтоб вновь выданные адреса быстрее роутились и не создавали паразитный поток arp запросов.

[DiM_TauRus]

В чем проблема с адресом 255? Как у вас навешена эта /24 на эту машину с натом? на какой то интерфейс или статиком в null ?

Адреса от х.х.63.1/32 до х.х.63.254/32 висят на Loopback интерфейсе машинки с НАТом.

На НАТ статиком от БГП заруливается блок х.х.63.0/24 и он же отдельно от нашего основного /22 анонсится с препендами аплинку (для балансировки).

п.с. Проблема именно в этом адресе в последнем блоке /24. На других НАТах проблем с 255м адресом в своих /24х блоках нет.

 

Есля я правильно понял, то пул альясов прописанных на Loopback заканчивается х.х.63.254/32 ? и проблемный х.х.63.255/32 там просто не присутствует ?

Изменено 28 мая, 2011 пользователем DiM_TauRus

[zlolotus]

я сравнивал, на своей задаче получилось хуже, нетграф тоже процессора кушать хочет.

"В кавказской школе. Учитель: Грузины лучше, чем армяне. Голос: Чем? Учитель: ЧЕМ АРМЯНЕ ГОВОРЮ!!!"

XeonVs, так и не ясно из поста, что в результате лучше. ng_nat он хотя бы параллелится...

 

ngnat больше ресурсов потребляет чем ipfw nat

[roysbike]

Коллеги помогите. Есть сеть /26 . Алиасом на внеш. интерфейсе. Хочу попробывать перейти на ipfw nat kernel вместо PF nat.

 

binat on ix0 from 172.30.254.1 to any -> 87.245.x.x
binat on ix0 from 172.30.254.2 to any -> 87.245.x.x
binat on ix0 from 172.30.254.3 to any -> 87.245.x.x
binat on ix0 from 172.30.254.4 to any -> 87.245.x.x
binat on ix0 from 172.30.254.5 to any -> 87.245.x.x

Можете показать пример как эту конструкцию применить на ipfw nat kernel?

[Azamat]

Вот не динамический нат на пул белых адресов. Сейчас там подсеть /24 на 1 белый. Но можно и сделать чтобы вплоть до каждого отельного на белый.

 

вот выдержка из файла в автозагрузке (в таблице 40 ip адреса для НАТ instances, в таблице 30 "серые" подсети , которые натятся):

 

таблица 30 заполняется примерно таким образом:

${fwcmd} table 30 add 192.168.59.0/24 81

${fwcmd} table 30 add 192.168.46.0/24 82

 

т.е. подсеть 59.0/24 будет натиться через 81 инстанс ipfw nat со своим назначенным IP адресом из след. таблицы 40

 

таблица 40 заполняется скриптом

# IP POOL at table 40

START_PREFIX="/sbin/ipfw table 40 add xxx.xxx.xxx"

 

NUMBER=0

while [ $NUMBER -lt 123 ]; do

NUMBER=$(($NUMBER+1))

$START_PREFIX.$NUMBER $NUMBER

done

 

 

 

# NAT

#

NUMBER2=0

while [ $NUMBER2 -lt 100 ]; do

NUMBER2=$(($NUMBER2+1))

/sbin/ipfw nat $NUMBER2 config ip xxx.xxx.xxx.$NUMBER2 reset same_ports deny_in

done

 

${fwcmd} add 20100 nat tablearg ip from table\(30\) to any out via ${ext_if}

${fwcmd} add 20200 nat tablearg ip from any to table\(40\) in via ${ext_if}

[roysbike]

Разобрался вроде. Спасибо за пример!

Изменено 19 марта, 2013 пользователем roysbike

[roysbike]

Вот не динамический нат на пул белых адресов. Сейчас там подсеть /24 на 1 белый. Но можно и сделать чтобы вплоть до каждого отельного на белый.

 

вот выдержка из файла в автозагрузке (в таблице 40 ip адреса для НАТ instances, в таблице 30 "серые" подсети , которые натятся):

 

таблица 30 заполняется примерно таким образом:

${fwcmd} table 30 add 192.168.59.0/24 81

${fwcmd} table 30 add 192.168.46.0/24 82

 

т.е. подсеть 59.0/24 будет натиться через 81 инстанс ipfw nat со своим назначенным IP адресом из след. таблицы 40

 

таблица 40 заполняется скриптом

# IP POOL at table 40

START_PREFIX="/sbin/ipfw table 40 add xxx.xxx.xxx"

 

NUMBER=0

while [ $NUMBER -lt 123 ]; do

NUMBER=$(($NUMBER+1))

$START_PREFIX.$NUMBER $NUMBER

done

 

 

 

# NAT

#

NUMBER2=0

while [ $NUMBER2 -lt 100 ]; do

NUMBER2=$(($NUMBER2+1))

/sbin/ipfw nat $NUMBER2 config ip xxx.xxx.xxx.$NUMBER2 reset same_ports deny_in

done

 

${fwcmd} add 20100 nat tablearg ip from table\(30\) to any out via ${ext_if}

${fwcmd} add 20200 nat tablearg ip from any to table\(40\) in via ${ext_if}

 

с этим примером все понятно. А как дать клиенту белый IP? Например alias на бордере 1.1.1.1 и завернуть его на 192.168.2.1/32 с помощью ipfw nat? на PF nat это делалось вот таким образом

 

PF NAT
binat on ix0 from 192.168.2.1 to any -> 1.1.1.1
binat on ix0 from 192.168.2.2 to any -> 1.1.1.2
и тд

 

UDP:

Разобрался вроде

 

#SNAT
${fwcmd} nat show config
${fwcmd} nat 1 config log same_ports redirect_addr $local_ip $ext_ip
${fwcmd} add 2 nat 1 ip from $local_ip to any via em0
${fwcmd} add 3 nat 1 ip from any to $ext_ip via em0

Верно ли я делаю? Пакеты с внешнего интерфейса попадают на локальный IP

Изменено 20 марта, 2013 пользователем roysbike

[roysbike]

Azamat

Подскажите , вы же используете ipfw nat . Вы тюнили систему? Можете показать loader.conf?

 

Вот что у меня

loader.conf

kern.maxfiles="25000"
net.inet.tcp.syncache.hashsize=1024
net.inet.tcp.syncache.bucketlimit=100
net.inet.tcp.tcbhashsize=4096
kern.ipc.nsfbufs=10240
net.isr.dispatch=direct
hw.intr_storm_threshold=9000

 

 

Sysctl

net.inet.ip.fw.verbose=0
net.inet.icmp.icmplim=5000
net.link.ether.inet.log_arp_movements=0
net.inet.icmp.icmplim_output=0
kern.ipc.maxsockbuf=83886080
kern.random.sys.harvest.ethernet=0
kern.random.sys.harvest.point_to_point=0
kern.random.sys.harvest.interrupt=0
net.inet.ip.redirect=0
net.inet.raw.maxdgram=16384
net.inet.raw.recvspace=16384
dev.ix.0.rx_processing_limit=4096
dev.ix.1.rx_processing_limit=4096

[Azamat]

у меня boot.loader такой: (в нем что-то значимое, что-то нет - но, вклад каждой строки в работу не исследовал)

 

kern.hz=1000

net.inet.tcp.tcbhashsize=4096

hw.ix.rxd=4096

hw.ix.txd=4096

hw.em.rxd=4096

hw.em.txd=4096

net.inet.tcp.syncache.bucketlimit="100"

net.inet.tcp.syncache.hashsize="1024"

net.inet.tcp.tcbhashsize="50000"

hw.ix.rx_process_limit=4096

hw.ix.max_interrupt_rate=40000

kern.ipc.nmbclusters=2621440

kern.ipc.maxsockbuf=16777216

net.inet.tcp.drop_synfin=1

net.inet.tcp.recvbuf_max=16777216

net.inet.tcp.recvspace=16384

net.inet.tcp.sendbuf_max=16777216

net.inet.tcp.sendspace=16384

net.isr.dispatch="direct"

net.isr.maxthreads=4

net.isr.numthreads=4

net.isr.bindthreads=1

net.route.netisr_maxqlen=1024

net.isr.defaultqlimit=10240

net.isr.maxqlimit=10240