Вместо ipfw's nata: ipfw add 10000 divert 8668 ip from ${intnet}:${mask} to any ipfw add divert 8668 ip from any to ${extip} /sbin/natd -a ${extip} запустил pf's: nat on ! $int_if from $int_net to any -> $ext_ip На машине, стоящей за этим натом (5.4-STABLE) прекратил работать nfs/amd При возврате назад на natd - все заработало Где крутить? -- Maxim Tuliuk WWW: http://primats.org.ua/~mt/ ICQ: 21134222 The bike is absolute freedom of moving =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
On Sun, Sep 18, 2005 at 06:36:57PM +0300, Maxim Tuliuk wrote:
Вместо ipfw's nata: ipfw add 10000 divert 8668 ip from ${intnet}:${mask} to any ipfw add divert 8668 ip from any to ${extip} /sbin/natd -a ${extip} запустил pf's: nat on ! $int_if from $int_net to any -> $ext_ip
На машине, стоящей за этим натом (5.4-STABLE) прекратил работать nfs/amd При возврате назад на natd - все заработало Где крутить?
Скорее всего в сторону аналога ключика от natd '-m'. -same_ports | -m Try to keep the same port number when altering outgoing pack- ets. With this option, protocols such as RPC will have a better chance of working. If it is not possible to maintain the port number, it will be silently changed as per normal. То бишь искать метод реализации через pf сохранения портов в таблице трансляции. -- ZA-RIPE||ZA1-UANIC =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
Regards,
On Sun, Sep 18, 2005 at 06:36:57PM +0300, Maxim Tuliuk wrote:
Вместо ipfw's nata: ipfw add 10000 divert 8668 ip from ${intnet}:${mask} to any ipfw add divert 8668 ip from any to ${extip} /sbin/natd -a ${extip} запустил pf's: nat on ! $int_if from $int_net to any -> $ext_ip
На машине, стоящей за этим натом (5.4-STABLE) прекратил работать nfs/amd При возврате назад на natd - все заработало Где крутить?
Скорее всего в сторону аналога ключика от natd '-m'.
-same_ports | -m Try to keep the same port number when altering outgoing pack- ets. With this option, protocols such as RPC will have a better chance of working. If it is not possible to maintain the port number, it will be silently changed as per normal.
То бишь искать метод реализации через pf сохранения портов в таблице трансляции.
А именно: nat on $ext_if from !($ext_if) -> ($ext_if:0) что касается аналога -same_ports | -m: смотреть в сторону pass in/out on/off, rdr по вкусу. ; мда, и наличиствует ли у тебя scrub in? -- AP-RIPE aka apelsin =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
On Mon, Sep 19, 2005 at 20:39 +0300, Sergey Prisyazhny wrote:
При возврате назад на natd - все заработало Где крутить?
Скорее всего в сторону аналога ключика от natd '-m'.
-same_ports | -m Try to keep the same port number when altering outgoing pack- ets. With this option, protocols such as RPC will have a better chance of working. If it is not possible to maintain the port number, it will be silently changed as per normal.
То бишь искать метод реализации через pf сохранения портов в таблице трансляции.
А именно: nat on $ext_if from !($ext_if) -> ($ext_if:0) что касается аналога -same_ports | -m: смотреть в сторону pass in/out on/off, rdr по вкусу.
; мда, и наличиствует ли у тебя scrub in?
root 9868 3,4 0,4 1496 488 ?? Rs 30сер05 371:10,73 /sbin/natd -a {ext_ip} нету у меня никаких ключей А чем мне "scrub in" поможет? -- Maxim Tuliuk WWW: http://primats.org.ua/~mt/ ICQ: 21134222 The bike is absolute freedom of moving =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
Вместо ipfw's nata: ipfw add 10000 divert 8668 ip from ${intnet}:${mask} to any ipfw add divert 8668 ip from any to ${extip} /sbin/natd -a ${extip} запустил pf's: nat on ! $int_if from $int_net to any -> $ext_ip а что по этому поводу думает
On Sun, Sep 18, 2005 at 06:36:57PM +0300, Maxim Tuliuk wrote: pfctl -s a ?
На машине, стоящей за этим натом (5.4-STABLE) прекратил работать nfs/amd
Этто чтоо, вот у меня с последними (где-то с начала сентября) ядрами тазик клинит на детекте usb намертво :(, если usbd запускается, а поддержки usb в ядре нету и модуль не загружен - вешается сразу после загрузки модуля :(. В USB порту ничего нету.
При возврате назад на natd - все заработало Где крутить? Может поможет: set timeout { interval 5, frag 20 } set timeout { tcp.first 120, tcp.opening 30, tcp.established 600 } set timeout { tcp.closing 60, tcp.finwait 45, tcp.closed 90 } #set timeout { tcp.first 20, tcp.opening 20, tcp.established 900 } #set timeout { tcp.closing 10, tcp.finwait 10, tcp.closed 5 } #set timeout { adaptive.start 6000, adaptive.end 60000 } set limit { states 120000, frags 4000 } set loginterface none set optimization conservative scrub in all (ваще-то это чтоб занатить ~3K tcp connections)
natd - очень сложно-навороченная вещь, заточенная под дофига приложений. pf её может только в совсем простых случаях заменить и стоит с ним возиться там, где очень критично пакеты из userland в ядро и обратно не гонять, то есть CPU мало, а пакетов много. -- Best regards, Paul Arakelyan. =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
Простите, я немного пропустил начало треда, но мне странно - у меня именно PF и все, включая NFS работает без проблем. покажите мне правило, которое пропускает NFS через pf. On Wed, 21 Sep 2005, Paul Arakelyan wrote:
Вместо ipfw's nata: ipfw add 10000 divert 8668 ip from ${intnet}:${mask} to any ipfw add divert 8668 ip from any to ${extip} /sbin/natd -a ${extip} запустил pf's: nat on ! $int_if from $int_net to any -> $ext_ip а что по этому поводу думает
On Sun, Sep 18, 2005 at 06:36:57PM +0300, Maxim Tuliuk wrote: pfctl -s a ?
На машине, стоящей за этим натом (5.4-STABLE) прекратил работать nfs/amd
natd - очень сложно-навороченная вещь, заточенная под дофига приложений. pf её может только в совсем простых случаях заменить и стоит с ним возиться там, где очень критично пакеты из userland в ядро и обратно не гонять, то есть CPU мало, а пакетов много.
Категорически не согласен с данным утверждением. Разглядывая исходники natd и исходники NAT имени PF - я пришел к совершенно противоположным выводам. Главное - не забывать, что PF в отличие от IPFW - насквозь statefull. -- With best regards, Gregory Edigarov =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
TRANSLATION RULES: nat on ! rl1 inet from $int_net to any -> $ext_ip FILTER RULES: INFO: Status: Disabled for 4 days 14:27:56 Debug: Urgent Hostid: 0x70475390 State Table Total Rate current entries 0 searches 69997618 176.0/s inserts 250109 0.6/s removals 250109 0.6/s Counters match 49339016 124.1/s bad-offset 0 0.0/s fragment 0 0.0/s short 134 0.0/s normalize 0 0.0/s memory 0 0.0/s TIMEOUTS: tcp.first 120s tcp.opening 30s tcp.established 86400s tcp.closing 900s tcp.finwait 45s tcp.closed 90s udp.first 60s udp.single 30s udp.multiple 60s icmp.first 20s icmp.error 10s other.first 60s other.single 30s other.multiple 60s frag 30s interval 10s adaptive.start 0 states adaptive.end 0 states src.track 0s LIMITS: states hard limit 10000 src-nodes hard limit 0 frags hard limit 5000 OS FINGERPRINTS: 293 fingerprints loaded On Wed, Sep 21, 2005 at 22:45 +0300, Paul Arakelyan wrote:
Вместо ipfw's nata: ipfw add 10000 divert 8668 ip from ${intnet}:${mask} to any ipfw add divert 8668 ip from any to ${extip} /sbin/natd -a ${extip} запустил pf's: nat on ! $int_if from $int_net to any -> $ext_ip а что по этому поводу думает
On Sun, Sep 18, 2005 at 06:36:57PM +0300, Maxim Tuliuk wrote: pfctl -s a ?
На машине, стоящей за этим натом (5.4-STABLE) прекратил работать nfs/amd
Этто чтоо, вот у меня с последними (где-то с начала сентября) ядрами тазик клинит на детекте usb намертво :(, если usbd запускается, а поддержки usb в ядре нету и модуль не загружен - вешается сразу после загрузки модуля :(. В USB порту ничего нету.
При возврате назад на natd - все заработало Где крутить? Может поможет: set timeout { interval 5, frag 20 } set timeout { tcp.first 120, tcp.opening 30, tcp.established 600 } set timeout { tcp.closing 60, tcp.finwait 45, tcp.closed 90 } #set timeout { tcp.first 20, tcp.opening 20, tcp.established 900 } #set timeout { tcp.closing 10, tcp.finwait 10, tcp.closed 5 } #set timeout { adaptive.start 6000, adaptive.end 60000 } set limit { states 120000, frags 4000 } set loginterface none set optimization conservative scrub in all (ваще-то это чтоб занатить ~3K tcp connections)
natd - очень сложно-навороченная вещь, заточенная под дофига приложений. pf её может только в совсем простых случаях заменить и стоит с ним возиться там, где очень критично пакеты из userland в ядро и обратно не гонять, то есть CPU мало, а пакетов много.
-- Best regards, Paul Arakelyan. =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
-- Maxim Tuliuk WWW: http://primats.org.ua/~mt/ ICQ: 21134222 The bike is absolute freedom of moving =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
В pf.conf есть только ОДНО правило: nat on ! $int_if from $int_net to any -> $ext_ip On Thu, Sep 22, 2005 at 11:01 +0300, Gregory Edigarov wrote:
Простите,
я немного пропустил начало треда, но мне странно - у меня именно PF и все, включая NFS работает без проблем. покажите мне правило, которое пропускает NFS через pf.
On Wed, 21 Sep 2005, Paul Arakelyan wrote:
Вместо ipfw's nata: ipfw add 10000 divert 8668 ip from ${intnet}:${mask} to any ipfw add divert 8668 ip from any to ${extip} /sbin/natd -a ${extip} запустил pf's: nat on ! $int_if from $int_net to any -> $ext_ip а что по этому поводу думает
On Sun, Sep 18, 2005 at 06:36:57PM +0300, Maxim Tuliuk wrote: pfctl -s a ?
На машине, стоящей за этим натом (5.4-STABLE) прекратил работать nfs/amd
natd - очень сложно-навороченная вещь, заточенная под дофига приложений. pf её может только в совсем простых случаях заменить и стоит с ним возиться там, где очень критично пакеты из userland в ядро и обратно не гонять, то есть CPU мало, а пакетов много.
Категорически не согласен с данным утверждением. Разглядывая исходники natd и исходники NAT имени PF - я пришел к совершенно противоположным выводам. Главное - не забывать, что PF в отличие от IPFW - насквозь statefull.
-- With best regards, Gregory Edigarov
=================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
-- Maxim Tuliuk WWW: http://primats.org.ua/~mt/ ICQ: 21134222 The bike is absolute freedom of moving =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
On Thu, 22 Sep 2005, Maxim Tuliuk wrote:
В pf.conf есть только ОДНО правило: nat on ! $int_if from $int_net to any -> $ext_ip
Тогда понятно... Либо попробуйте конструкцию "nat pass on....", либо добавьте правила фильтрации, обязательно в statefull варианте.
On Thu, Sep 22, 2005 at 11:01 +0300, Gregory Edigarov wrote:
Простите,
я немного пропустил начало треда, но мне странно - у меня именно PF и все, включая NFS работает без проблем. покажите мне правило, которое пропускает NFS через pf.
On Wed, 21 Sep 2005, Paul Arakelyan wrote:
Вместо ipfw's nata: ipfw add 10000 divert 8668 ip from ${intnet}:${mask} to any ipfw add divert 8668 ip from any to ${extip} /sbin/natd -a ${extip} запустил pf's: nat on ! $int_if from $int_net to any -> $ext_ip а что по этому поводу думает
On Sun, Sep 18, 2005 at 06:36:57PM +0300, Maxim Tuliuk wrote: pfctl -s a ?
На машине, стоящей за этим натом (5.4-STABLE) прекратил работать nfs/amd
natd - очень сложно-навороченная вещь, заточенная под дофига приложений. pf её может только в совсем простых случаях заменить и стоит с ним возиться там, где очень критично пакеты из userland в ядро и обратно не гонять, то есть CPU мало, а пакетов много.
Категорически не согласен с данным утверждением. Разглядывая исходники natd и исходники NAT имени PF - я пришел к совершенно противоположным выводам. Главное - не забывать, что PF в отличие от IPFW - насквозь statefull.
-- With best regards, Gregory Edigarov
=================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
-- Maxim Tuliuk WWW: http://primats.org.ua/~mt/ ICQ: 21134222
The bike is absolute freedom of moving =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
With best regards, Gregory Edigarov =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
On Thu, Sep 22, 2005 at 11:01:43AM +0300, Gregory Edigarov wrote:
Простите,
я немного пропустил начало треда, но мне странно - у меня именно PF и все, включая NFS работает без проблем. покажите мне правило, которое пропускает NFS через pf.
возиться там, где очень критично пакеты из userland в ядро и обратно не гонять, то есть CPU мало, а пакетов много.
Категорически не согласен с данным утверждением. Разглядывая исходники natd и исходники NAT имени PF - я пришел к совершенно противоположным выводам. Главное - не забывать, что PF в отличие от IPFW - насквозь statefull. Но тьфу-тьфу его(pf) не затачивали под конкретную кучу приложений - тот же ftp толком не проедет. Ну и вариант типа ssh client->(freebsd router/pf nat)->somesshd при ребуте freebsd router получали обрыв ssh sessions, а с natd и ppp nat - вроде как ок...
-- Best regards, Paul Arakelyan. =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
On Thu, 22 Sep 2005, Paul Arakelyan wrote:
On Thu, Sep 22, 2005 at 11:01:43AM +0300, Gregory Edigarov wrote:
Простите,
я немного пропустил начало треда, но мне странно - у меня именно PF и все, включая NFS работает без проблем. покажите мне правило, которое пропускает NFS через pf.
возиться там, где очень критично пакеты из userland в ядро и обратно не гонять, то есть CPU мало, а пакетов много.
Категорически не согласен с данным утверждением. Разглядывая исходники natd и исходники NAT имени PF - я пришел к совершенно противоположным выводам. Главное - не забывать, что PF в отличие от IPFW - насквозь statefull. Но тьфу-тьфу его(pf) не затачивали под конкретную кучу приложений - тот же ftp толком не проедет. Ну и вариант типа ssh client->(freebsd router/pf nat)->somesshd при ребуте freebsd router получали обрыв ssh sessions, а с natd и ppp nat - вроде как ок...
Для ftp - есть ftp-proxy. по поводу обрыва сессий - это не такое уж большое горе, и к тому-же - я видел обрывы ssh и с natd. Что еще есть на поругать pf? нет, мне честно интересно, я без издевательств. -- With best regards, Gregory Edigarov =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
On Fri, Sep 23, 2005 at 04:11:19PM +0300, Gregory Edigarov wrote:
Что еще есть на поругать pf? нет, мне честно интересно, я без издевательств. "из личного опыта" - при вагоне (несколько тысяч) tcp-sessions с кучей packets/s очень странно оно себя ведёт - вроде и загрузка процессора меньше (значительно), а с natd packet rate удавалось достичь больше (если процессора хватало). Ну и разные "передёргивания" типа изменение адреса на интерфейсе (многократное) с pf приводит к большей вероятности крэшнуть систему - хотя тут уж явно не pf виноват.
-- Best regards, Paul Arakelyan. =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
On Mon, 26 Sep 2005, Paul Arakelyan wrote:
On Fri, Sep 23, 2005 at 04:11:19PM +0300, Gregory Edigarov wrote:
Что еще есть на поругать pf? нет, мне честно интересно, я без издевательств. "из личного опыта" - при вагоне (несколько тысяч) tcp-sessions с кучей packets/s очень странно оно себя ведёт - вроде и загрузка процессора меньше (значительно), а с natd packet rate удавалось достичь больше (если процессора хватало). Ну и разные "передёргивания" типа изменение адреса на интерфейсе (многократное) с pf приводит к большей вероятности крэшнуть систему - хотя тут уж явно не pf виноват.
Хм, а у меня все работает под PF быстро и хорошо. ~ 50 правил(нат, очереди, фильтрация) + таблицы. насчет packet rate - не скажу, но по ощущениям - в разы быстрее. Я проверил тут - без keep state есть таки некоторый performance degrade, думаю, потому, что в случае non-statefull filtering оно делает last matching wins, в отличие от IPFW. но в случае statefull - у меня работает очень хорошо. -- With best regards, Gregory Edigarov =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
Gregory Edigarov wrote:
On Mon, 26 Sep 2005, Paul Arakelyan wrote:
On Fri, Sep 23, 2005 at 04:11:19PM +0300, Gregory Edigarov wrote:
Что еще есть на поругать pf? нет, мне честно интересно, я без издевательств. "из личного опыта" - при вагоне (несколько тысяч) tcp-sessions с кучей packets/s очень странно оно себя ведёт - вроде и загрузка процессора меньше (значительно), а с natd packet rate удавалось достичь больше (если процессора хватало). Ну и разные "передёргивания" типа изменение адреса на интерфейсе (многократное) с pf приводит к большей вероятности крэшнуть систему - хотя тут уж явно не pf виноват.
Хм, а у меня все работает под PF быстро и хорошо. ~ 50 правил(нат, очереди, фильтрация) + таблицы. насчет packet rate - не скажу, но по ощущениям - в разы быстрее. Я проверил тут - без keep state есть таки некоторый performance degrade, думаю, потому, что в случае non-statefull filtering оно делает last matching wins, в отличие от IPFW.
Что мешает писать правила так, чтобы было first matching wins (с помощью quick ) ? -- Mykola Dzham, LEFT-(UANIC|RIPE) JID: levsha@jabber.kiev.ua =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
On Tue, 27 Sep 2005, Mykola Dzham wrote:
Gregory Edigarov wrote:
On Mon, 26 Sep 2005, Paul Arakelyan wrote:
On Fri, Sep 23, 2005 at 04:11:19PM +0300, Gregory Edigarov wrote:
Что еще есть на поругать pf? нет, мне честно интересно, я без издевательств. "из личного опыта" - при вагоне (несколько тысяч) tcp-sessions с кучей packets/s очень странно оно себя ведёт - вроде и загрузка процессора меньше (значительно), а с natd packet rate удавалось достичь больше (если процессора хватало). Ну и разные "передёргивания" типа изменение адреса на интерфейсе (многократное) с pf приводит к большей вероятности крэшнуть систему - хотя тут уж явно не pf виноват.
Хм, а у меня все работает под PF быстро и хорошо. ~ 50 правил(нат, очереди, фильтрация) + таблицы. насчет packet rate - не скажу, но по ощущениям - в разы быстрее. Я проверил тут - без keep state есть таки некоторый performance degrade, думаю, потому, что в случае non-statefull filtering оно делает last matching wins, в отличие от IPFW.
Что мешает писать правила так, чтобы было first matching wins (с помощью quick ) ?
Не знаю... мне ничего не мешает, просто набор правил уже есть достаточно давно, и рассчитан он изначально был именно на statefull filtering. а то была просто проверка, насколько упадет скорость работы если переписать мой набор правил так, чтобы оно не использовало состояния... оказалось, что это, во-первых, совсем неудобно (сразу разбухли до ~70 правил), во вторых, без quick - работает несколько тормознуто, а под quick нужна, в моих случаях, совершенно другая логика. И совсем незачем на меня наезжать. "У меня все работает." (С) -- With best regards, Gregory Edigarov =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
participants (6)
-
Andrey Zarechansky -
Gregory Edigarov -
Maxim Tuliuk -
Mykola Dzham -
Paul Arakelyan -
Sergey Prisyazhny