Биллинговая система Nodeny

Сразу после загрузки системы (FreeBSD 8.0-RELEASE-p3) при попытке пинга внешнего ресурса имеем вот такое:

# ipfw show
00050  53   4725 allow tcp from any to me dst-port 22
00051  43   7068 allow tcp from me 22 to any
00100   0      0 allow ip from any to any via lo0
00105 690 214283 allow ip from any to any via rl0
00110  65   4896 nat 1 ip from any to any via nfe0
00120   0      0 deny ip from any to any
65535   0      0 deny ip from any to any
# ping 217.69.128.43
PING 217.69.128.43 (217.69.128.43): 56 data bytes
ping: sendto: Permission denied
ping: sendto: Permission denied
ping: sendto: Permission denied
^C
--- 217.69.128.43 ping statistics ---
3 packets transmitted, 0 packets received, 100.0% packet loss

Однако после рестарта ipfw все нормализуется:

# /etc/rc.d/ipfw restart
net.inet.ip.fw.enable: 1 -> 0
Flushed all rules.
00050 allow tcp from any to me dst-port 22
00051 allow tcp from me 22 to any
00100 allow ip from any to any via lo0
00105 allow ip from any to any via rl0
ipfw nat 1 config if nfe0 same_ports reset
00110 nat 1 ip from any to any via nfe0
00120 deny ip from any to any
Firewall rules loaded.
# ipfw show
00050   8   528 allow tcp from any to me dst-port 22
00051   5   556 allow tcp from me 22 to any
00100   0     0 allow ip from any to any via lo0
00105 240 76918 allow ip from any to any via rl0
00110  23  1316 nat 1 ip from any to any via nfe0
00120   0     0 deny ip from any to any
65535   0     0 deny ip from any to any
# ping 217.69.128.43
PING 217.69.128.43 (217.69.128.43): 56 data bytes
64 bytes from 217.69.128.43: icmp_seq=0 ttl=116 time=63.717 ms
64 bytes from 217.69.128.43: icmp_seq=1 ttl=116 time=63.448 ms
64 bytes from 217.69.128.43: icmp_seq=2 ttl=116 time=63.548 ms
64 bytes from 217.69.128.43: icmp_seq=3 ttl=116 time=63.570 ms
^C
--- 217.69.128.43 ping statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 63.448/63.571/63.717/0.096 ms
#

В чем может быть проблема? Как я понимаю, сообщение ping: sendto: Permission denied генерирует фаерволл. Но после его рестарта, как я вижу, набор правил не меняется, а тем не менее трафик уже не блокируется.

Ядро скомпилировано с опциями:
options         IPFIREWALL
options         IPDIVERT
options         IPFIREWALL_FORWARD
options         DUMMYNET
options         ROUTETABLES=16
options         IPFIREWALL_NAT
options         LIBALIAS

File:rc.firewall


File:rc.conf      

почему from any to any?

Все, что проходит через внешний интерфейс заворачиваем в NAT. А что тут такого? Правила то рабочие. Непонятно только почему они начинают работать только после перезапуска ipfw.

Вот, что еще удалось выяснить:

# ipfw show
00050   53   4725 allow tcp from any to me dst-port 22
00051   44   7032 allow tcp from me 22 to any
00100    0      0 allow ip from any to any via lo0
00105 1814 452908 allow ip from any to any via rl0
00110   64   8019 nat 1 ip from any to any via nfe0
00120    0      0 deny ip from any to any
65535    0      0 deny ip from any to any
# ping 217.69.128.43
PING 217.69.128.43 (217.69.128.43): 56 data bytes
ping: sendto: Permission denied
ping: sendto: Permission denied
^C
--- 217.69.128.43 ping statistics ---
2 packets transmitted, 0 packets received, 100.0% packet loss
# ipfw nat 1 show config

Тут, по идее, мы должны увидеть конфигурацию nat 1, но ее почему-то нет.

# /etc/rc.d/ipfw restart
net.inet.ip.fw.enable: 1 -> 0
Flushed all rules.
00050 allow tcp from any to me dst-port 22
00051 allow tcp from me 22 to any
00100 allow ip from any to any via lo0
00105 allow ip from any to any via rl0
ipfw nat 1 config if nfe0 same_ports reset
00110 nat 1 ip from any to any via nfe0
00120 deny ip from any to any
Firewall rules loaded.
# ipfw nat 1 show config
ipfw nat 1 config if nfe0 same_ports reset
#

А после перезагрузки ipfw появилась конфигурация nat 1. И, конечно:

# ping 217.69.128.43
PING 217.69.128.43 (217.69.128.43): 56 data bytes
64 bytes from 217.69.128.43: icmp_seq=2 ttl=116 time=63.537 ms
64 bytes from 217.69.128.43: icmp_seq=3 ttl=116 time=63.639 ms
64 bytes from 217.69.128.43: icmp_seq=4 ttl=116 time=63.667 ms
^C
--- 217.69.128.43 ping statistics ---
5 packets transmitted, 3 packets received, 40.0% packet loss
round-trip min/avg/max/stddev = 63.537/63.614/63.667/0.056 ms
#

Получается, что при первоначальной загрузке не читается конфигурация ната? Почему так?

firewall_nat_enable="YES" > /etc/rc.conf

allow icmp from any to any

К сожалению, не сработало. ipfw nat 1 show config - по-прежнему пуст. :) Можно и так, конечно. Но задача вроде как в другом - заставить работать nat при старте системы, а не только после перезагрузки правил ipfw.

Есть еще идеи?

Прописать в Фаэрволе
00001  allow any to any  в общем открыть все.
И пересобрать ядро.
У самого такое было, на фре 7.2

Что значит "пересобрать"? С теми же опциями, или что-то изменить надо? Дело в том, что оно было пересобрано за несколько часов до моего поста.

бред
сказано же нат не стратует.

поковырял чуть исходники
днсп
используй скрипт после поднятия апи

Пересобрал ядро, все по-прежнему.

Использовать скрипт для рестарта ipfw как-то некошерно, хотелось бы, чтобы работало штатно. А что там такого в исходниках, что вы советуете рестартовать скриптом?

а может попробовать юзать другой нат? не через ipfw ?

сделай еще rxcsum ifconfig rl0 -rxcsum -tso

да не надо рестартовать фаер

всего то

ipfw nat 1 config if nfe0 same_ports reset


но тут есть маленький нюанс
католько передернится апи надо перезапускать 

ipfw nat 1 config if nfe0 same_ports reset

Я понимаю это. Вот тут http://www.lissyara.su/articles/freebsd/tuning/ipfw_nat/#extra_info (http://www.lissyara.su/articles/freebsd/tuning/ipfw_nat/#extra_info) написано: Но у меня nat как бы работает... В любом случае, отключение этих опций не помогло, а за попытку помочь - спасибо.

Это, конечно, помогает. Спасибо. Но, хотелось бы понять почему при старте системы эта команда не отрабатывается в rc.firewall, хотя другие правила добавляются. Вроде бы так не предусмотрено создателями :) Буду дальше искать косяк. Если будут у кого идеи, заранее благодарен.

Появилась мысль, что в момент старта системы, когда обрабатываются правила rc.firewall, внешний интерфейс еще не успевает сконфигурироваться по DHCP. Проверил так: задал ему статический адрес, перезагрузил систему. Вуаля, все работает, NAT свой конфиг прочитал. :)

В связи с этим мой вопрос переформулируется: как можно приостановить загрузку правил rc.firewall до того момента когда внешний интерфейс будет полностью сконфигурирован?

Не проще запустить r.firewall еще раз например при запуке локальных пакетов или из rc.local?

попробуй dhcp клиент запускать в самом начале списка rc.conf
а firewall в самом конце
они же в алфавитном порядке очереди выполняются.

смотри в исходниках - там есть все обяснения.
можно конечно и поправть - но ... 1 дорого будет  2 при обновлениии?
должны быть патчи ищи или пиши разработчикам.

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

А что есть "передернится апи"?

изменится
он же выдается по днсп у тебя.
кстати какая uname ?

Дык. Вроде бы в первом посте указал. Не проблема - счас повторю.
:)

А вообще-то : FreeBSD 8.0-RELEASE-p3

если я правильно понял, то при изменении внешнего ip придется заного рестартовать ipfw? Вот засада! Хоть по контракту этот IP статический, прописывание его на if дает эффект ненадолго, максимум минут на 40-45. Видимо, пров не получая DHCP request в определенное время (1/2 лизинга) считает меня отсутствующим в сети и рвет сессию. Соответственно, по истечении этого некоторого времени пропадают пинги даже на шлюз.

Следовательно, я не могу использовать статический адрес на интерфейсе. И, следовательно вам, вынужден использовать костыли в виде скриптов. Жаль, что так. Но, все равно, спасибо!

Кстаи, как определить программно, что "передернулся апи"? То бишь изменился внешний IP?

тот который выдается по dhcp ?
или тот который натит

А в моем случае это один и тот же интерфейс - натить надо на dhcp-интерфейсе. Собственно из-за этого и вся проблема. За то время, что получаются настройки dhcp, успевают  отработать правила rc.firewall. Соответственно nat не читает свой конфиг.

пни провайдера, что это за хрень такая.

Мне кажется, что пинать за это надо не прова, а авторов ipfw_nat (или юзеров типа меня, которые могут не заметить некоторые очевидные из man-а настройки), ибо на винде таких проблем не было замечено (правда пару лет назад и в несколько других условиях, но основные кондиции те же самые - нат на динамически конфигурируемом интерфейсе). Да и не очень-то запинаешь национального оператора связи :( Мы взяли этот канал как резервный, но, разумеется, возникло желание его утилизировать и пустить часть трафика через него. Теперь вижу, что даже в качестве резервного его проблематично пользовать.

используй pf

Спасибо за совет. Работая с виндой я привык, что программы идущие в комплекте с операционной системой и даже программы не входящие в таковой комплект, но подписанные корпорацией microsoft, работают с пол-пинка. Если они не работают, то это означает только одно - мое неумение читать и понимать хелп. Я полагал, что эта философия распространяется и на FreeBSD и выбрал наиболее подходящее для меня решение NAT. Среди его преимуществ - один конфиг и для фаерволла и для NAT, что кому-то может показаться несущественным, но для меня, не привыкшего рыться в конфигах, это существенное преимущество. Кроме того реализация в одном модуле ipfw+nat само собой есть преимущество, ну и многочисленные тесты в нете о превосходстве ipfw_nat над natd и pf не оставляют выбора.

Я немного упрям и буду пытаться разрешить эту траблу, хотя наиболее легкий выход из всего этого - установка Win2008Server, тем более что никакого другого функционала кроме маршрутизации (статической) и ната от этого сервера не требуется (не требуется установка сателлитов NoDeny, нет никаких особых условий для маршрутизации).

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

Но все равно спасибо - тема очень оказалась интересна :)

а ссилочкой подельшся?

Ссылочкой на что? На Гугль?

Не жалко :) Лови (http://www.google.ru/search?num=50&hl=ru&lr=&newwindow=1&rlz=1I7SKPB_ru&q=%D0%BF%D0%BE%D1%80%D1%8F%D0%B4%D0%BE%D0%BA+%D0%B7%D0%B0%D0%BF%D1%83%D1%81%D0%BA%D0%B0+freebsd&aq=f&aqi=&aql=&oq=&gs_rfai=)

в dhclient.conf есть параметр script "script-name", если я не ошибаюсь, то запускает скрипт после обновления данных

принать надо себя в первую очередь - за не умением думать и пользоватся маном

по сути гдето так ( сори пробовать не начем)



в dhclient.conf  строку
script "/etc/dhclient-script";

touch /etc/dhclient-script
chmod +x /etc/dhclient-script

там простенький скрипт можно испольщовать эти переменые

$interface
$new_ip_address
$old_ip_address
$new_subnet_mask
$old_subnet_mask

да и порытся можно еще найти кучу всего
питать далее ? сам уже дальше осилишь?

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

как раз и стоит проверка. что вполне нормально.

Спасибо, рылся я на эту тему в гугле, видел подобные скрипты, но подумал подойти к решению с другой стороны. Типа так: задать внешнему фейсу статический фейковый адрес, после загрузки ipfw скрипт  выполняет "dhclient nfe0" и "ifconfig -alias фейковый_адрес". Вот как-то так. Буду пробовать. Интересно, сработает или нет?

Сделал как описал в предыдущем посте. Все работает. Всем спасибо за помощь.