From: Patrick McHardy <kaber@trash.net>
To: Jan Engelhardt <jengelh@medozas.de>
Cc: netfilter-devel@vger.kernel.org
Subject: Re: nf-next: TEE only
Date: Wed, 14 Apr 2010 13:24:51 +0200 [thread overview]
Message-ID: <4BC5A603.5090403@trash.net> (raw)
In-Reply-To: <alpine.LSU.2.01.1004141310120.13840@obet.zrqbmnf.qr>
Jan Engelhardt wrote:
> On Wednesday 2010-04-14 12:57, Patrick McHardy wrote:
>
>> Jan Engelhardt wrote:
>>> in this round:
>>> - use IP6SKB_REROUTED in v6 code
>>> - pick_net function: use skb->dev or skb->dst->dev when available
>>> (or completely fall back to init_net in case there's something
>>> going on)
>> So what about oif routing which I asked for two times?
>
> Guess it must have fallen off somewhere between the resends. We can
> still add it as a patch on top.
Please add it before I apply it. Should be a fairly trivial change.
>> I guess you'd usually have a host for logging or IDS somewhere on a
>> private network and TEE packets there. So specifying oif and gateway
>> seems most useful to me.
>
> The oif is already determined by the route to the gateway(logging
> host). I'd also fear that people abuse TEE as a ROUTE replacement
> when they see an --oif.
That's something different. The oif forces use of a specific output
device, independant of the routing tables. F.i.:
# ip l l dummy0
4: dummy0: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
link/ether 96:7f:5e:d2:d6:c9 brd ff:ff:ff:ff:ff:ff
# ip a s dummy0
4: dummy0: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
li# ip a s dummy0
4: dummy0: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
link/ether 96:7f:5e:d2:d6:c9 brd ff:ff:ff:ff:ff:ff
inet6 fe80::947f:5eff:fed2:d6c9/64 scope link
valid_lft forever preferred_lft forever
# ip r | grep dummy0
#
# ping 10.0.0.1 -I dummy0
IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.0.100 > 10.0.0.1: ICMP echo request, id 25874, seq 1, length 64
IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.0.100 > 10.0.0.1: ICMP echo request, id 25874, seq 2, length 64
This is quite useful since your logging host doesn't have to be
reachable through normal routing.
next prev parent reply other threads:[~2010-04-14 11:24 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-13 23:21 nf-next: TEE only Jan Engelhardt
2010-04-13 23:21 ` [PATCH 1/4] netfilter: xtables: inclusion of xt_TEE Jan Engelhardt
2010-04-14 5:52 ` Eric Dumazet
2010-04-14 10:00 ` Jan Engelhardt
2010-04-14 10:56 ` Patrick McHardy
2010-04-13 23:21 ` [PATCH 2/4] netfilter: xtables2: make ip_tables reentrant Jan Engelhardt
2010-04-13 23:21 ` [PATCH 3/4] netfilter: xt_TEE: have cloned packet travel through Xtables too Jan Engelhardt
2010-04-13 23:21 ` [PATCH 4/4] netfilter: xtables: remove old comments about reentrancy Jan Engelhardt
2010-04-14 10:57 ` nf-next: TEE only Patrick McHardy
2010-04-14 11:15 ` Jan Engelhardt
2010-04-14 11:24 ` Patrick McHardy [this message]
2010-04-14 11:32 ` Jan Engelhardt
2010-04-15 11:41 ` Jan Engelhardt
2010-04-15 11:56 ` Patrick McHardy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4BC5A603.5090403@trash.net \
--to=kaber@trash.net \
--cc=jengelh@medozas.de \
--cc=netfilter-devel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).