ping: sendto: Permission denied

[evp]

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

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

[goletsa]

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

[stix]

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

скрипты в новой интерпретации ОБЯЗАНЫ иметь ключевые слова
в заголовках:

``PROVIDE'', ``BEFORE'',``KEYWORD'', ``REQUIRE''

примерно так:

# PROVIDE: что_обеспечивает
# REQUIRE: для_чего_требуется
# BEFORE: перед_кем_стартует
# KEYWORD: ключевое_слово

из верхних: PROVIDE - обязаловка, остальные ОПРЕДЕЛЯЮТ порядок старта,
это видно по REQUIRE, BEFORE и KEYWORD

Порядок выполнения НОВЫХ скриптов, с указанными заголовками, обеспечивает
утилита rcorder - она как бы сортирует список файлов по верхним заголовкам,
в этом порядке они и выполняются

2) если же у нас ОПРЕДЕЛЕНА переменная:  local_startup , тогда
будут выполняться старт-стоп скрипты не только в /etc/rc.d, но
и в тех директориях которые заданы в $local_startup - вот тут НЬЮАНС:

- скрипты в этих директориях могут быть в НОВОЙ нотации с заголовком PROVIDE,
они будут стартовать ПЕРВЫМИ
-  и кроме них могут быть скрипты в СТАРОЙ нотации (без PROVIDE),
они стартуют в лескикографическом порядке

Прим: REQUIRE и BEFORE можно использовать для задания своего порядка, ДАЖЕ
если наш скрипт НИЧЕГО не REQUIRE и тд и тп, ну просто rcorder сортирует
файлы в rc по такому принципу

Соответственно решение: либо в /usr/local/etc/rc.d - все СТАРЫЕ скрипты
поправить на НОВЫЙ лад (в этом случае вовсе можно в /etc/rc.d перенести),
либо наоборот на СТАРЫЙ лад.

[ser970]

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

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

[evp]

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

[ser970]

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

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

[evp]

кстати какая uname ?

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

Код:

# uname
FreeBSD

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

[evp]

он же выдается по днсп у тебя

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

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

[evp]

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

[stix]

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

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

[evp]

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

[stix]

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

[evp]

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

[elite]

используй pf

[evp]

используй pf

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

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