Здравствуйте, возможно ли средствами IPFW организовать подобие FORWARD chain v linux? как? а то есть такая конструкция: ipfw add divert natd all from 192.168.5.220 to any out xmit tun0 ipfw add divert natd all from any to any in recv tun0 ipfw add 1000 allow all from any to any т.е. выход в инет открыт через nat только одной машине теперь эту конструкцию надо обойти. можно, конечно, сделать ipfw add skipto 1100 all from not 192.168.5.220.. но тогда я пропущу allow all from any to any, а оно здесь, как я понимаю неоходимо. есть ли еще какие-то методы решить задачу? -- 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
Явно описать правило разрешающее то что тебе нужно до этой конструкции. Нет? -- AO618-RIPE
-----Original Message----- From: owner-uanog-outgoing@uanog.kiev.ua [mailto:owner-uanog-outgoing@uanog.kiev.ua] On Behalf Of Gregory Edigarov Sent: Friday, April 30, 2004 2:51 PM To: uanog@uanog.kiev.ua Subject: [uanog] ipfw q.
Здравствуйте,
возможно ли средствами IPFW организовать подобие FORWARD chain v linux?
как?
а то есть такая конструкция: ipfw add divert natd all from 192.168.5.220 to any out xmit tun0 ipfw add divert natd all from any to any in recv tun0 ipfw add 1000 allow all from any to any
т.е. выход в инет открыт через nat только одной машине теперь эту конструкцию надо обойти. можно, конечно, сделать ipfw add skipto 1100 all from not 192.168.5.220.. но тогда я пропущу allow all from any to any, а оно здесь, как я понимаю неоходимо. есть ли еще какие-то методы решить задачу? -- 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
=================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
On Fri, 30 Apr 2004, andyo wrote:
Явно описать правило разрешающее то что тебе нужно до этой конструкции. Нет?
подробнее можно? есть сетка 192.168.5.0/24 с нее надо через natd выпустить 1 тачку во внешний мир. все остальные идут лесом на разные прокси. как такое нарисовать на iptables - я знаю. знаю решение для IPFilter. хочется через ipfw. -- 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
Fri, Apr 30, 2004 at 15:51:24, greg wrote about "[uanog] ipfw q.":
возможно ли средствами IPFW организовать подобие FORWARD chain v linux? А своими словами? ipfw fwd - не то?
как?
а то есть такая конструкция: ipfw add divert natd all from 192.168.5.220 to any out xmit tun0 ipfw add divert natd all from any to any in recv tun0 ipfw add 1000 allow all from any to any
т.е. выход в инет открыт через nat только одной машине теперь эту конструкцию надо обойти. можно, конечно, сделать ipfw add skipto 1100 all from not 192.168.5.220.. но тогда я пропущу allow all from any to any, а оно здесь, как я понимаю неоходимо. есть ли еще какие-то методы решить задачу?
Для уточнения задачи - почему не add skipto 1000 ...? -netch- =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
On Fri, 30 Apr 2004, Valentin Nechayev wrote:
ipfw add divert natd all from 192.168.5.220 to any out xmit tun0 ipfw add divert natd all from any to any in recv tun0 ipfw add 1000 allow all from any to any
Для уточнения задачи - почему не add skipto 1000 ...? Будет allow all from any to any, а этого допускать нельзя -- 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, Apr 30, 2004 at 04:31:37PM +0300, Gregory Edigarov wrote:
On Fri, 30 Apr 2004, Valentin Nechayev wrote:
ipfw add divert natd all from 192.168.5.220 to any out xmit tun0 ipfw add divert natd all from any to any in recv tun0 ipfw add 1000 allow all from any to any
Для уточнения задачи - почему не add skipto 1000 ...? Будет allow all from any to any, а этого допускать нельзя ну нарисуй skipto X где после X начинаются правила твоего firewall'а, а не nat'а. логика пройстейшая же.
-- With best regards, Alexandr Kanevskiy. ISP Inter-Don. CTO AK2240-RIPE, AK2-6BONE =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
On Fri, 30 Apr 2004, Alexandr D. Kanevskiy wrote:
ipfw add 1000 allow all from any to any Для уточнения задачи - почему не add skipto 1000 ...? Будет allow all from any to any, а этого допускать нельзя ну нарисуй skipto X где после X начинаются правила твоего firewall'а, а не nat'а. логика пройстейшая же. Я же показывал skipto 1100, но так оно вообще не работает. (без allow all from any to any). -- 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
Fri, Apr 30, 2004 at 16:31:37, greg wrote about "[uanog] Re: ipfw q.":
Для уточнения задачи - почему не add skipto 1000 ...? Будет allow all from any to any, а этого допускать нельзя
Бр-р-р... похоже, наступили праздники - то ли ты не то говоришь, то ли я не так понимаю. Во всех тредах - ничего не понял. Можешь нарисовать правила что пропускать, что не пропускать, в виде алгоритма или блок-схемы? Или хотя бы в виде конструкции с логическими связками? Типа "пропускать XXX если не YYY, при этом натить ZZZ если QQQ"? -netch- =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
On Fri, 30 Apr 2004, Valentin Nechayev wrote:
Fri, Apr 30, 2004 at 16:31:37, greg wrote about "[uanog] Re: ipfw q.":
Для уточнения задачи - почему не add skipto 1000 ...? Будет allow all from any to any, а этого допускать нельзя
Бр-р-р... похоже, наступили праздники - то ли ты не то говоришь, то ли я не так понимаю. Во всех тредах - ничего не понял. Можешь нарисовать правила что пропускать, что не пропускать, в виде алгоритма или блок-схемы? Или хотя бы в виде конструкции с логическими связками? Типа "пропускать XXX если не YYY, при этом натить ZZZ если QQQ"? я запостил сюда полный скрипт. посмотри его.
-- 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, 30 Apr 2004, Valentin Nechayev wrote:
Для уточнения задачи - почему не add skipto 1000 ...? Будет allow all from any to any, а этого допускать нельзя
Бр-р-р... похоже, наступили праздники - то ли ты не то говоришь, то ли я не так понимаю. Во всех тредах - ничего не понял. Можешь нарисовать правила что пропускать, что не пропускать, в виде алгоритма или блок-схемы? Или хотя бы в виде конструкции с логическими связками? Типа "пропускать XXX если не YYY, при этом натить ZZZ если QQQ"?
ладно. пропустить через нат 192.168.5.220 пропустить через нат 192.168.7.70 если он идет с интерфейса ppp* для остальных ната нету. пропускать их на локальные сервисы, включающие в себя socks, squid, и кучу всякой дряни. -- 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
Fri, Apr 30, 2004 at 18:14:37, greg wrote about "[uanog] Re: ipfw q.":
ладно. пропустить через нат 192.168.5.220 пропустить через нат 192.168.7.70 если он идет с интерфейса ppp* для остальных ната нету. пропускать их на локальные сервисы, включающие в себя socks, squid, и кучу всякой дряни.
Ну тогда где-то так: ipfw add 1000 divert natd ip from 192.168.5.220 out xmit $extif ipfw add 1100 divert natd ip from 192.168.7.70 out recv 'ppp*' xmit $extif ipfw add 1200 divert natd ip from any to $nataddr in recv $extif ipfw add 1300 unreach filter-prohib ip from any to any out recv any xmit $extif Здесь $extif - внешний интерфейс, $nataddr - адрес в который natd натит. -netch- =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
On Fri, 30 Apr 2004, Valentin Nechayev wrote:
Ну тогда где-то так:
ipfw add 1000 divert natd ip from 192.168.5.220 out xmit $extif ipfw add 1100 divert natd ip from 192.168.7.70 out recv 'ppp*' xmit $extif ipfw add 1200 divert natd ip from any to $nataddr in recv $extif ipfw add 1300 unreach filter-prohib ip from any to any out recv any xmit $extif
Здесь $extif - внешний интерфейс, $nataddr - адрес в который natd натит.
спасибо, после праздников проверю. -- 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
Hi! On Fri, Apr 30, 2004 at 03:51:24PM +0300, Gregory Edigarov writes:
возможно ли средствами IPFW организовать подобие FORWARD chain v linux?
как?
а то есть такая конструкция: ipfw add divert natd all from 192.168.5.220 to any out xmit tun0 ipfw add divert natd all from any to any in recv tun0 ipfw add 1000 allow all from any to any
т.е. выход в инет открыт через nat только одной машине теперь эту конструкцию надо обойти. можно, конечно, сделать ipfw add skipto 1100 all from not 192.168.5.220.. но тогда я пропущу allow all from any to any, а оно здесь, как я понимаю неоходимо. есть ли еще какие-то методы решить задачу?
Можно перекрывать на внутреннем интерфейсе все, кроме разрешенного. У тебя tun0, как я понял, внешний. Пусть внутренний будет fxp0. Тогда добавь ipfw add allow all from any to me in recv fxp0 ipfw add allow all from 192.168.5.220 to any in recv fxp0 ipfw add deny all from any to any in recv fxp0 Но IMHO правильнее всего натить отдельным IP, чтобы отличать собственный трафик от транзитного, по-разному из фильтровать, и чтобы собственный трафик не пропускать через natd. -- Lucky carrier, Паша. =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
On Fri, 30 Apr 2004, Pavel Gulchouck wrote:
Можно перекрывать на внутреннем интерфейсе все, кроме разрешенного. У тебя tun0, как я понял, внешний. Пусть внутренний будет fxp0. Тогда добавь
ipfw add allow all from any to me in recv fxp0 ipfw add allow all from 192.168.5.220 to any in recv fxp0 ipfw add deny all from any to any in recv fxp0 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ я не могу так делать. на этой же тачке до фига других сервисов крутится для серой сетки.
Но IMHO правильнее всего натить отдельным IP, чтобы отличать собственный трафик от транзитного, по-разному из фильтровать, и чтобы собственный трафик не пропускать через natd.
да, согласен, что так наиболее правильно. но у этой тачки нету других IP. -- 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, Apr 30, 2004 at 04:48:19PM +0300, Gregory Edigarov writes:
Можно перекрывать на внутреннем интерфейсе все, кроме разрешенного. У тебя tun0, как я понял, внешний. Пусть внутренний будет fxp0. Тогда добавь
ipfw add allow all from any to me in recv fxp0 ipfw add allow all from 192.168.5.220 to any in recv fxp0 ipfw add deny all from any to any in recv fxp0 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ я не могу так делать. на этой же тачке до фига других сервисов крутится для серой сетки.
Это правило закрывает forward из внутренней сетки вовне для всех, кроме явно разрешенного в предыдущем правиле IP. Как раз то, что в iptables попадает в FORWARD, потому что аналог INPUT отработан в первом правиле (которое тоже можно заменить на более подробное описание, что нужно разрешить, а что запретить). То есть, правила allow/deny, которые тебе нужны, пусть отрабатываются на внутреннем интерфейсе, а nat будет работать, когда пакеты проходят через внешний интерфейс. -- Lucky carrier, Паша. =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
On Fri, 30 Apr 2004, Pavel Gulchouck wrote:
ipfw add allow all from any to me in recv fxp0 ipfw add allow all from 192.168.5.220 to any in recv fxp0 ipfw add deny all from any to any in recv fxp0 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ я не могу так делать. на этой же тачке до фига других сервисов крутится для серой сетки.
Это правило закрывает forward из внутренней сетки вовне для всех, кроме явно разрешенного в предыдущем правиле IP. Как раз то, что в iptables попадает в FORWARD, потому что аналог INPUT отработан в первом правиле (которое тоже можно заменить на более подробное описание, что нужно разрешить, а что запретить).
То есть, правила allow/deny, которые тебе нужны, пусть отрабатываются на внутреннем интерфейсе, а nat будет работать, когда пакеты проходят через внешний интерфейс. понятно, но даже с учетом этого - не будет это работать. покажу весь скрипт, может я чего-то не понимаю. сетка - локалка, доступ через VPN и squid. 1 или 2 машины - должны иметь доступ через nat. что можно сделать? 5.xx - localka, 7.xx vpn.
#!/bin/sh ipfw -f flush ipfw add 100 check-state ipfw add 200 allow all from any to any via lo0 ipfw add 300 deny all from 10.0.0.0/8 to any in via tun0 ipfw add 400 deny all from 172.16.0.0/12 to any in via tun0 ipfw add 500 deny all from 192.168.0.0/16 to any in via tun0 ipfw add 600 divert natd all from 192.168.5.220 to any out xmit tun0 ipfw add 700 divert natd all from any to any in recv tun0 ipfw add 800 allow all from any to any ipfw add 900 allow icmp from any to any ipfw add 1000 deny all from any to any frag ipfw add 1100 deny all from 192.168.5.0/24 to any xmit tun0 ipfw add 1200 deny all from 192.168.7.0/24 to any xmit tun0 ipfw add 1300 allow gre from 192.168.5.0/24 to me ipfw add 1400 allow gre from me to any ipfw add 1500 allow udp from me to any keep-state ipfw add 1600 allow tcp from me to any keep-state ipfw add 1700 allow tcp from any to any established ipfw add 1800 allow tcp from any to me 25 setup ipfw add 1900 allow tcp from any to me ssh setup ipfw add 2000 allow tcp from 192.168.7.0/24 to me 3128 setup ipfw add 2100 allow tcp from 192.168.7.0/24 to me 2080 setup via ppp\* ipfw add 2200 allow tcp from 192.168.7.0/24 to me pop3 setup via ppp\* ipfw add 2300 allow tcp from any to me http setup via tun0 ipfw add 2400 allow tcp from 192.168.7.0/24 to me setup via ppp\* ipfw add 2500 allow tcp from 192.168.5.0/24 to me pptp setup ipfw add 2600 allow tcp from 192.168.5.0/24 to me ftp\\-data-ftp setup via sk0 ipfw add 2700 allow udp from 192.168.7.0/24 to me 53 ipfw add 2800 allow udp from 192.168.5.0/24 to me 53 ipfw add 2900 allow tcp from any to me 53 setup ipfw add 3000 deny log all from any to any -- 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
Fri, Apr 30, 2004 at 16:56:44, gul wrote about "[uanog] Re: ipfw q.":
ipfw add allow all from any to me in recv fxp0 ipfw add allow all from 192.168.5.220 to any in recv fxp0 ipfw add deny all from any to any in recv fxp0 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ я не могу так делать. на этой же тачке до фига других сервисов крутится для серой сетки.
Это правило закрывает forward из внутренней сетки вовне для всех, кроме явно разрешенного в предыдущем правиле IP. Как раз то, что в iptables попадает в FORWARD, потому что аналог INPUT отработан в первом правиле (которое тоже можно заменить на более подробное описание, что нужно разрешить, а что запретить).
Проще всего форвард в ipfw определяется конструкцией "out recv any" (но не наоборот, потому что на фазе in ещё неизвестно куда пакет пойдёт). Сделав `ipfw add NNN skipto MMM ip from any to any out recv any' - получим аналог цепочки forward начинающийся с правила номер MMM. -netch- =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
Hi! On Fri, Apr 30, 2004 at 08:27:23PM +0300, Valentin Nechayev writes:
ipfw add allow all from any to me in recv fxp0 ipfw add allow all from 192.168.5.220 to any in recv fxp0 ipfw add deny all from any to any in recv fxp0 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ я не могу так делать. на этой же тачке до фига других сервисов крутится для серой сетки.
Это правило закрывает forward из внутренней сетки вовне для всех, кроме явно разрешенного в предыдущем правиле IP. Как раз то, что в iptables попадает в FORWARD, потому что аналог INPUT отработан в первом правиле (которое тоже можно заменить на более подробное описание, что нужно разрешить, а что запретить).
Проще всего форвард в ipfw определяется конструкцией "out recv any" (но не наоборот, потому что на фазе in ещё неизвестно куда пакет пойдёт).
А разве пакеты, прошедшие через natd, попадут под это правило? Они ведь AFAIU локально сгенерированными получаются.
Сделав `ipfw add NNN skipto MMM ip from any to any out recv any' - получим аналог цепочки forward начинающийся с правила номер MMM.
-- Lucky carrier, Паша. =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
Tue, May 11, 2004 at 11:34:17, gul wrote about "[uanog] Re: ipfw q.":
Проще всего форвард в ipfw определяется конструкцией "out recv any" (но не наоборот, потому что на фазе in ещё неизвестно куда пакет пойдёт). А разве пакеты, прошедшие через natd, попадут под это правило? Они ведь AFAIU локально сгенерированными получаются. Раутинг пересчитывается для них наново, а вот признак форварда и входной интерфейс сохраняются в учёте.
-netch- =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
Hi! On Tue, May 11, 2004 at 11:38:47AM +0300, Valentin Nechayev writes:
Проще всего форвард в ipfw определяется конструкцией "out recv any" (но не наоборот, потому что на фазе in ещё неизвестно куда пакет пойдёт). А разве пакеты, прошедшие через natd, попадут под это правило? Они ведь AFAIU локально сгенерированными получаются. Раутинг пересчитывается для них наново, а вот признак форварда и входной интерфейс сохраняются в учёте.
Hmm... А как мне сгенерить пакет и указать для него source iface? Как это делает natd? Я думал, что там через raw socket пакеты формируются, но это ведь layer3, и там source iface указать негде. Или все сложнее, чем просто один пакет уходит по divert на natd с концами, а другой формируется от natd как бы заново? -- Lucky carrier, Паша. =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
Tue, May 11, 2004 at 12:02:59, gul wrote about "[uanog] Re: ipfw q.":
А разве пакеты, прошедшие через natd, попадут под это правило? Они ведь AFAIU локально сгенерированными получаются. Раутинг пересчитывается для них наново, а вот признак форварда и входной интерфейс сохраняются в учёте. Hmm... А как мне сгенерить пакет и указать для него source iface? Как это делает natd? Я думал, что там через raw socket пакеты формируются, но это ведь layer3, и там source iface указать негде. Или все сложнее, чем просто один пакет уходит по divert на natd с концами, а другой формируется от natd как бы заново?
man divert: Diverted packets may be read unaltered via read(2), recv(2), or recvfrom(2). In the latter case, the address returned will have its port set to some tag supplied by the packet diverter, (usually the ipfw rule number) and the IP address set to the (first) address of the interface on which the packet was received (if the packet was incoming) or INADDR_ANY (if the packet was outgoing). The interface name (if defined for the packet) will be placed in the 8 bytes following the address, if it fits. Writing to a divert socket is similar to writing to a raw IP socket; the packet is injected ``as is'' into the normal kernel IP packet processing and minimal error checking is done. Packets are written as either incom- ing or outgoing: if write(2) or send(2) is used to deliver the packet, or if sendto(2) is used with a destination IP address of INADDR_ANY, then the packet is treated as if it were outgoing, i.e., destined for a non- local address. Otherwise, the packet is assumed to be incoming and full packet routing is done. In the latter case, the IP address specified must match the address of some local interface, or an interface name must be found after the IP address. If an interface name is found, that interface will be used and the value of the IP address will be ignored (other than the fact that it is not INADDR_ANY). This is to indicate on which interface the packet ``arrived''. Normally, packets read as incoming should be written as incoming; simi- larly for outgoing packets. When reading and then writing back packets, passing the same socket address supplied by recvfrom(2) unmodified to sendto(2) simplifies things (see below). -netch- =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
participants (5)
-
Alexandr D. Kanevskiy -
andyo -
Gregory Edigarov -
Pavel Gulchouck -
Valentin Nechayev