pfctl -ef после каждой перезагрузки

[name-13]

openbsd 4.5 со всеми патчами из errata

Проблема: после каждого ребута необходимо вручную цепляться
по ssh и долбить pfctl -ef /etc/pf.conf, иначе NAT не работает,
и пакеты между интерфейсами не роутятся.

Никто не сталкивался с подобным? По настройкам все прописано
корректно вроде как... И сам по себе pf работает как надо
(NAT/роутинг и тп). Уж, по крайней мере, pf приказано стартовать,
и права на pf.conf корректные, и ошибок в конфиге нет... Читал
где-то, что пересборка ядра с отключением ipv6 рушит работу pf,
но это не мой случай (ipv6 я не трогал). Подробности ниже. Спасибо.

ядро пересобрано:

# diff ./GENERIC ./MYCONF
13c13
< include               "../../../conf/GENERIC"
---
> include               "../../../conf/MYCONF"
34c34
< #option               NTFS            # Experimental NTFS support
---
> option                NTFS            # Experimental NTFS support

# diff ../../../conf/GENERIC ../../../conf/MYCONF; echo $?
0


конфиги и проч.:

# ls -l /etc/pf.conf
-rw-------  1 root  wheel  1989 Sep 30 23:29 /etc/pf.conf

# cat /etc/rc.conf | grep pf
ospfd_flags=NO          # for normal use: ""
ospf6d_flags=NO         # for normal use: ""
pf=NO                   # Packet filter / NAT
pf_rules=/etc/pf.conf           # Packet filter rules file
pflogd_flags=                   # add more flags, ie. "-s 256"

# cat /etc/rc.conf.local | grep pf
pf=YES

# pfctl -nf /etc/pf.conf; echo $?
0

после ручного старта pfctl -ef /etc/pf.conf все работает...

[Igor Grabin]

On Thu, Oct 01, 2009 at 03:41:06PM +0400, name wrote:
> Проблема: после каждого ребута необходимо вручную цепляться
> по ssh и долбить pfctl -ef /etc/pf.conf, иначе NAT не работает,
> и пакеты между интерфейсами не роутятся.
к гадалке не ходи, у тебя изначально pf.conf не подгружается. обычно
это происходит из-за того, что dns ещё не работает, туннели ещё не все
поднялись, и так далее.

как это ловить:

не щёлкать клювом во время загрузки и посмотреть, почему pfctl
отказался схавать pf.conf на тот момент.

либо, перечитать его вдумчиво, осматриваясь на тему dns имён (во время
старта на момент pfctl почти всегда named ещё не одуплён), всяких
tun'ов (которых ещё тупо нет на момент pfctl) и так далее.

possible solutions:

pfctl -ef в хвосте rc.local. неэлегантно.
курить pf.conf до просветления, почему на недодуплённой системе pfctl
может посчитать, что там syntax error'ы

--
Igor "CacoDem0n" Grabin, http://violent.death.kiev.ua/

[Dinar Talypov]

On Thu, 01 Oct 2009 15:41:06 +0400
name <draft@...> wrote:


>
> # ls -l /etc/pf.conf
> -rw-------  1 root  wheel  1989 Sep 30 23:29 /etc/pf.conf
>
> # cat /etc/rc.conf | grep pf
> ospfd_flags=NO          # for normal use: ""
> ospf6d_flags=NO         # for normal use: ""
> pf=NO                   # Packet filter / NAT
     ^^ тут дожно быть YES
> pf_rules=/etc/pf.conf           # Packet filter rules file
> pflogd_flags=                   # add more flags, ie. "-s 256"
>
> # cat /etc/rc.conf.local | grep pf
> pf=YES
а rc.conf.local для другого служит
>
--
Динар Талыпов

[Igor Grabin]

On Thu, Oct 01, 2009 at 04:28:00PM +0400, Dinar Talypov wrote:

> > # ls -l /etc/pf.conf
> > -rw-------  1 root  wheel  1989 Sep 30 23:29 /etc/pf.conf
> > # cat /etc/rc.conf | grep pf
> > ospfd_flags=NO          # for normal use: ""
> > ospf6d_flags=NO         # for normal use: ""
> > pf=NO                   # Packet filter / NAT
>      ^^ тут дожно быть YES
> > pf_rules=/etc/pf.conf           # Packet filter rules file
> > pflogd_flags=                   # add more flags, ie. "-s 256"
> > # cat /etc/rc.conf.local | grep pf
> > pf=YES
> а rc.conf.local для другого служит

да ну?
и для чего, тогда?

я уже чёрте-сколько времени в rc.conf только смотрю, а всё своё
концентратом сбрасываю в rc.conf.local

самое весёлое в том, что от перемены места дислокации pf=YES результат
в нашем случае нихрена не поменяется.

--
Igor "CacoDem0n" Grabin, http://violent.death.kiev.ua/

[Stans Sataa]

Dinar Talypov пишет:

> On Thu, 01 Oct 2009 15:41:06 +0400
> name <draft@...> wrote:
>
>
>  
>> # ls -l /etc/pf.conf
>> -rw-------  1 root  wheel  1989 Sep 30 23:29 /etc/pf.conf
>>
>> # cat /etc/rc.conf | grep pf
>> ospfd_flags=NO          # for normal use: ""
>> ospf6d_flags=NO         # for normal use: ""
>> pf=NO                   # Packet filter / NAT
>>    
>      ^^ тут дожно быть YES
>  

^^^ не должно, т.к. rc.conf не редактируется.
>> pf_rules=/etc/pf.conf           # Packet filter rules file
>> pflogd_flags=                   # add more flags, ie. "-s 256"
>>
>> # cat /etc/rc.conf.local | grep pf
>> pf=YES
>>    
> а rc.conf.local для другого служит
>  
Все верно прописано в rc.conf.local.

Можно посмотреть набор правил pf.conf?

--
Best regards,                     icq : 53530661
 Stans                            xmpp: sinsane@...
         

[name-13]

думаю, Динара могли смутить следующие строки man rc.conf:

     It is advisable to leave the /etc/rc.conf file untouched, and instead
     create and edit a new /etc/rc.conf.local file.  Variables set in this
     file will override variables previously set in /etc/rc.conf.

вот только "variables set in this...", как показывает практика, не
означает, что в .локал можно сувать только переменные -
булевые ес/ноу тоже... по кр. мере, ни разу не страдал от того, что
включаю через rc.conf.local YES/NO

Igor Grabin wrote:

> On Thu, Oct 01, 2009 at 04:28:00PM +0400, Dinar Talypov wrote:
>  
>>> # ls -l /etc/pf.conf
>>> -rw-------  1 root  wheel  1989 Sep 30 23:29 /etc/pf.conf
>>> # cat /etc/rc.conf | grep pf
>>> ospfd_flags=NO          # for normal use: ""
>>> ospf6d_flags=NO         # for normal use: ""
>>> pf=NO                   # Packet filter / NAT
>>>      
>>      ^^ тут дожно быть YES
>>    
>>> pf_rules=/etc/pf.conf           # Packet filter rules file
>>> pflogd_flags=                   # add more flags, ie. "-s 256"
>>> # cat /etc/rc.conf.local | grep pf
>>> pf=YES
>>>      
>> а rc.conf.local для другого служит
>>    
> да ну?
> и для чего, тогда?
>
> я уже чёрте-сколько времени в rc.conf только смотрю, а всё своё
> концентратом сбрасываю в rc.conf.local
>
> самое весёлое в том, что от перемены места дислокации pf=YES результат
> в нашем случае нихрена не поменяется

[name-13]

Igor Grabin wrote:

> On Thu, Oct 01, 2009 at 03:41:06PM +0400, name wrote:
>  
>> Проблема: после каждого ребута необходимо вручную цепляться
>> по ssh и долбить pfctl -ef /etc/pf.conf, иначе NAT не работает,
>> и пакеты между интерфейсами не роутятся.
>>    
> к гадалке не ходи, у тебя изначально pf.conf не подгружается. обычно
> это происходит из-за того, что dns ещё не работает, туннели ещё не все
> поднялись, и так далее.
>
> как это ловить:
>
> не щёлкать клювом во время загрузки и посмотреть, почему pfctl
> отказался схавать pf.conf на тот момент.
>  

да все б хорошо.. только сервер без консоли стоит :-[
> либо, перечитать его вдумчиво, осматриваясь на тему dns имён (во время
> старта на момент pfctl почти всегда named ещё не одуплён), всяких
> tun'ов (которых ещё тупо нет на момент pfctl) и так далее.
>  
вот это уже практически в точку...
в правилах фигурирует как туннель, так и днс-форвардеры и
доменные имена, так что практически наверняка, что
проблема в том, что еще не поднят инет (через туннель - адсл)

спасибо за наводку!
> possible solutions:
>  
подойдем с другого бока... как _изящно_ разрулить проблему?
не изящных вариантов много - в том числе, стартовать пф после
поднятия инета.. ("pf=NO" + "pfctl -e") но это как бы... уж точно не
есть правильно

как вариант, отказаться от днс-имен в правилах, при этом не будет рушить
pfctl из-за невозможности их резолвнуть, но в свою очередь это создает
другие неудобства... да и потом, от tun-а в правилах уже точно не
отказаться...
(который тоже поднимается существенно позже)...........
> pfctl -ef в хвосте rc.local. неэлегантно.
> курить pf.conf до просветления, почему на недодуплённой системе pfctl
>  
я правильно понял, что pfctl отказывается принимать правила не столько
потому,
что не может, допустим, резолвнуть имя, сколько из-за того, что на этом
месте натыкается
на получающуюся ошибку в синтаксисе???
> может посчитать, что там syntax error'ы

[Igor Grabin]

On Thu, Oct 01, 2009 at 05:21:56PM +0400, name wrote:
> подойдем с другого бока... как _изящно_ разрулить проблему?
> не изящных вариантов много - в том числе, стартовать пф после
> поднятия инета.. ("pf=NO" + "pfctl -e") но это как бы... уж точно не
> есть правильно
дёшево, сердито и практично - pfctl -ef/etc/pf.conf в
/etc/ppp/ppp.linkup

тему с dns именами я обычно разруливал посредством написания правил на
таблицы, а заполнение самих таблиц - уже отдельным скриптом и потом.

как-то вот так.

> я правильно понял, что pfctl отказывается принимать правила не столько
> потому,
> что не может, допустим, резолвнуть имя, сколько из-за того, что на этом
> месте натыкается
> на получающуюся ошибку в синтаксисе???
ыыы... одно жёстко следует за другим. или есть креатив по части того,
как эти события можно отвязать друг от друга? :-)

--
Igor "CacoDem0n" Grabin, http://violent.death.kiev.ua/

[name-13]

Igor Grabin wrote:

> On Thu, Oct 01, 2009 at 05:21:56PM +0400, name wrote:
>  
>> подойдем с другого бока... как _изящно_ разрулить проблему?
>> не изящных вариантов много - в том числе, стартовать пф после
>> поднятия инета.. ("pf=NO" + "pfctl -e") но это как бы... уж точно не
>> есть правильно
>>    
> дёшево, сердито и практично - pfctl -ef/etc/pf.conf в
> /etc/ppp/ppp.linkup
>
> тему с dns именами я обычно разруливал посредством написания правил на
> таблицы, а заполнение самих таблиц - уже отдельным скриптом и потом.
>
> как-то вот так.
>
>  
>> я правильно понял, что pfctl отказывается принимать правила не столько
>> потому,
>> что не может, допустим, резолвнуть имя, сколько из-за того, что на этом
>> месте натыкается
>> на получающуюся ошибку в синтаксисе???
>>    
> ыыы... одно жёстко следует за другим. или есть креатив по части того,
> как эти события можно отвязать друг от друга? :-)
>  

ммм, ну вот iptables вроде как правило, имена в котором не может
резолвнуть, просто пропускает... pf, насколько я помню, при обращении
вручную тоже как-то на синтаксис не жаловался, если не мог что-то найти...
вроде как просто пропускал правило...

может, я не сталкивался просто...


в общем, все ясно. спасибо за участие.

[Ilya A. Kovalenko]

{... skipped ... }

1. а "-e"-то зачем ?!

   Если в rc.conf* получается pf=YES, то PF и так должен быть заенаблен.

   Если же он не разрешен после загрузки, нужно разбираться с /etc/rc*
   на предмет того что убито (например включение rc.conf.local в
   /etc/rc.conf)

2. Покажите pfctl -sr на момент после загрузки, если он пустой, это
   еще пунктик в пользу пункта 1.
   При ошибке в pf.conf должен загружаться рулесет пропускающий
   только ssh и еще кое-какие мелочи.


3. ППКС per Igor Grabin
     +
   я ловил такое (ошибку pf.conf) на момент когда сетевые карты не
   успели определиться со скоростью (10/100/1000), а у меня не было
   явного объявления bandwidth в правиле altq

4. Вы уверены что /etc/rc отработал до конца ? Я как-то ловил запуск
   программы в foreground (без "&") в rc.local. Правда тогда у меня
   (а точнее у брата по разуму), в итоге не запускался cron.

  Иными словами - отлаживайте и трассируйте стартовые скрипты, проблема
где-то в них или в момент их выполнения.

[Grigoriy Orlov]

 Я никогда не использую в PF DNS имена. Всегда есть риск, что что-то не
разрезолвится, даже если DNS доступен.  Я делаю макросы типа
host_domain_com="IP" и использую их в правилах. Согласен что это не удобно,
зато надежно.
  Есть мысль сделать парсилку конфига, которая будет резолвить
имена и вставлять вместо них IP. Вот такой обработанный конфиг уже
выкладывать в /etc/pf.conf. Для меня это удобно, так как конфиги к разным
фаерволам я все равно генерирую mak'ом и исходные темплейты храню в cvs.
Сделать такой обработчик не сложно, но может быть кто-то подскажет уже
готовую утилиту.

        /gluk

[Andrey Lyubimets]

name пишет:

> Igor Grabin wrote:
>> On Thu, Oct 01, 2009 at 03:41:06PM +0400, name wrote:
>>  
>>> Проблема: после каждого ребута необходимо вручную цепляться
>>> по ssh и долбить pfctl -ef /etc/pf.conf, иначе NAT не работает,
>>> и пакеты между интерфейсами не роутятся.
>>>    
>> к гадалке не ходи, у тебя изначально pf.conf не подгружается. обычно
>> это происходит из-за того, что dns ещё не работает, туннели ещё не все
>> поднялись, и так далее.
>>
>> как это ловить:
>>
>> не щёлкать клювом во время загрузки и посмотреть, почему pfctl
>> отказался схавать pf.conf на тот момент.
>>  
> да все б хорошо.. только сервер без консоли стоит :-[

последняя строчка в rc.local
pfctl -f /etc/conf/pf.conf > /var/log/pf.start.log 2>&1

>> либо, перечитать его вдумчиво, осматриваясь на тему dns имён (во время
>> старта на момент pfctl почти всегда named ещё не одуплён), всяких
>> tun'ов (которых ещё тупо нет на момент pfctl) и так далее.
>>  
> вот это уже практически в точку...
> в правилах фигурирует как туннель, так и днс-форвардеры и
> доменные имена, так что практически наверняка, что
> проблема в том, что еще не поднят инет (через туннель - адсл)
>
> спасибо за наводку!
>> possible solutions:
>>  
> подойдем с другого бока... как _изящно_ разрулить проблему?
> не изящных вариантов много - в том числе, стартовать пф после
> поднятия инета.. ("pf=NO" + "pfctl -e") но это как бы... уж точно не
> есть правильно
>
> как вариант, отказаться от днс-имен в правилах, при этом не будет рушить
> pfctl из-за невозможности их резолвнуть, но в свою очередь это создает
> другие неудобства... да и потом, от tun-а в правилах уже точно не
> отказаться...
> (который тоже поднимается существенно позже)...........
>> pfctl -ef в хвосте rc.local. неэлегантно.
>> курить pf.conf до просветления, почему на недодуплённой системе pfctl
>>  
> я правильно понял, что pfctl отказывается принимать правила не столько
> потому,
> что не может, допустим, резолвнуть имя, сколько из-за того, что на этом
> месте натыкается
> на получающуюся ошибку в синтаксисе???

да, совершенно верно
у меня pf не стартовал из-за конструкции tun0:0 - не мог получить адрес
>> может посчитать, что там syntax error'ы
>
>


--
С уважением, Любимец Андрей Алексеевич

[name-13]

Andrey Lyubimets wrote:

> name пишет:
>> Igor Grabin wrote:
>>> On Thu, Oct 01, 2009 at 03:41:06PM +0400, name wrote:
>>>  
>>>> Проблема: после каждого ребута необходимо вручную цепляться
>>>> по ssh и долбить pfctl -ef /etc/pf.conf, иначе NAT не работает,
>>>> и пакеты между интерфейсами не роутятся.
>>>>    
>>> к гадалке не ходи, у тебя изначально pf.conf не подгружается. обычно
>>> это происходит из-за того, что dns ещё не работает, туннели ещё не все
>>> поднялись, и так далее.
>>>
>>> как это ловить:
>>>
>>> не щёлкать клювом во время загрузки и посмотреть, почему pfctl
>>> отказался схавать pf.conf на тот момент.
>>>  
>> да все б хорошо.. только сервер без консоли стоит :-[
> последняя строчка в rc.local
> pfctl -f /etc/conf/pf.conf > /var/log/pf.start.log 2>&1

ну, тогда уж не в rc.local. а где-то в cat /etc/rc | grep -n pfctl
а то ведь из rc.local он наверняка отработает нормально...

>>> либо, перечитать его вдумчиво, осматриваясь на тему dns имён (во время
>>> старта на момент pfctl почти всегда named ещё не одуплён), всяких
>>> tun'ов (которых ещё тупо нет на момент pfctl) и так далее.
>>>  
>> вот это уже практически в точку...
>> в правилах фигурирует как туннель, так и днс-форвардеры и
>> доменные имена, так что практически наверняка, что
>> проблема в том, что еще не поднят инет (через туннель - адсл)
>>
>> спасибо за наводку!
>>> possible solutions:
>>>  
>> подойдем с другого бока... как _изящно_ разрулить проблему?
>> не изящных вариантов много - в том числе, стартовать пф после
>> поднятия инета.. ("pf=NO" + "pfctl -e") но это как бы... уж точно не
>> есть правильно
>>
>> как вариант, отказаться от днс-имен в правилах, при этом не будет рушить
>> pfctl из-за невозможности их резолвнуть, но в свою очередь это создает
>> другие неудобства... да и потом, от tun-а в правилах уже точно не
>> отказаться...
>> (который тоже поднимается существенно позже)...........
>>> pfctl -ef в хвосте rc.local. неэлегантно.
>>> курить pf.conf до просветления, почему на недодуплённой системе pfctl
>>>  
>> я правильно понял, что pfctl отказывается принимать правила не столько
>> потому,
>> что не может, допустим, резолвнуть имя, сколько из-за того, что на этом
>> месте натыкается
>> на получающуюся ошибку в синтаксисе???
> да, совершенно верно
> у меня pf не стартовал из-за конструкции tun0:0 - не мог получить адрес
>>> может посчитать, что там syntax error'ы
>>
>>
>
>

[Andrey Lyubimets]

name пишет:

>
> Andrey Lyubimets wrote:
>> name пишет:
>>> Igor Grabin wrote:
>>>> On Thu, Oct 01, 2009 at 03:41:06PM +0400, name wrote:
>>>>  
>>>>> Проблема: после каждого ребута необходимо вручную цепляться
>>>>> по ssh и долбить pfctl -ef /etc/pf.conf, иначе NAT не работает,
>>>>> и пакеты между интерфейсами не роутятся.
>>>>>    
>>>> к гадалке не ходи, у тебя изначально pf.conf не подгружается. обычно
>>>> это происходит из-за того, что dns ещё не работает, туннели ещё не все
>>>> поднялись, и так далее.
>>>>
>>>> как это ловить:
>>>>
>>>> не щёлкать клювом во время загрузки и посмотреть, почему pfctl
>>>> отказался схавать pf.conf на тот момент.
>>>>  
>>> да все б хорошо.. только сервер без консоли стоит :-[
>> последняя строчка в rc.local
>> pfctl -f /etc/conf/pf.conf > /var/log/pf.start.log 2>&1
> ну, тогда уж не в rc.local. а где-то в cat /etc/rc | grep -n pfctl
> а то ведь из rc.local он наверняка отработает нормально...

у меня не отрабатывал, именно так и ловил

--
С уважением, Любимец Андрей Алексеевич