From: Patrick McHardy <kaber@trash.net>
To: Jan Engelhardt <jengelh@medozas.de>
Cc: netfilter-devel@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [PATCH 3/5] netfilter: xtables: inclusion of xt_TEE
Date: Thu, 01 Apr 2010 12:34:00 +0200 [thread overview]
Message-ID: <4BB47698.6070102@trash.net> (raw)
In-Reply-To: <1270031934-15940-4-git-send-email-jengelh@medozas.de>
Jan Engelhardt wrote:
> +static bool
> +tee_tg_route4(struct sk_buff *skb, const struct xt_tee_tginfo *info)
> +{
> + const struct iphdr *iph = ip_hdr(skb);
> + struct rtable *rt;
> + struct flowi fl;
> + int err;
> +
> + memset(&fl, 0, sizeof(fl));
> + fl.iif = skb->skb_iif;
I'm not sure you really should set iif here. We usually (tunnels, REJECT
etc) packets generated locally as new packets.
> + fl.mark = skb->mark;
The same applies to mark.
> + fl.nl_u.ip4_u.daddr = info->gw.ip;
> + fl.nl_u.ip4_u.tos = RT_TOS(iph->tos);
> + fl.nl_u.ip4_u.scope = RT_SCOPE_UNIVERSE;
> +
> + /* Trying to route the packet using the standard routing table. */
> + err = ip_route_output_key(dev_net(skb->dev), &rt, &fl);
> + if (err != 0)
> + return false;
> +
> + dst_release(skb_dst(skb));
> + skb_dst_set(skb, &rt->u.dst);
> + skb->dev = rt->u.dst.dev;
> + skb->protocol = htons(ETH_P_IP);
> + IPCB(skb)->flags |= IPSKB_REROUTED;
> + return true;
> +}
> +
> +/*
> + * To detect and deter routed packet loopback when using the --tee option, we
> + * take a page out of the raw.patch book: on the copied skb, we set up a fake
> + * ->nfct entry, pointing to the local &route_tee_track. We skip routing
> + * packets when we see they already have that ->nfct.
So without conntrack, people may create loops? If that's the case,
I'd suggest to simply forbid TEE'ing packets to loopback. That
doesn't seem to be very useful anyways.
> + */
> +static unsigned int
> +tee_tg4(struct sk_buff *skb, const struct xt_target_param *par)
> +{
> + const struct xt_tee_tginfo *info = par->targinfo;
> + struct iphdr *iph;
> +
> +#ifdef WITH_CONNTRACK
> + if (skb->nfct == &tee_track.ct_general)
> + /*
> + * Loopback - a packet we already routed, is to be
> + * routed another time. Avoid that, now.
> + */
> + return NF_DROP;
> +#endif
> + /*
> + * Copy the skb, and route the copy. Will later return %XT_CONTINUE for
> + * the original skb, which should continue on its way as if nothing has
> + * happened. The copy should be independently delivered to the TEE
> + * --gateway.
> + */
> + skb = skb_copy(skb, GFP_ATOMIC);
> + if (skb == NULL)
> + return XT_CONTINUE;
> + /*
> + * If we are in PREROUTING/INPUT, the checksum must be recalculated
> + * since the length could have changed as a result of defragmentation.
> + *
> + * We also decrease the TTL to mitigate potential TEE loops
> + * between two hosts.
> + *
> + * Set %IP_DF so that the original source is notified of a potentially
> + * decreased MTU on the clone route. IPv6 does this too.
> + */
> + iph = ip_hdr(skb);
> + iph->frag_off |= htons(IP_DF);
> + if (par->hooknum == NF_INET_PRE_ROUTING ||
> + par->hooknum == NF_INET_LOCAL_IN)
> + --iph->ttl;
> + ip_send_check(iph);
Shouldn't this only be done in PRE_ROUTING/INPUT as stated above?
> +
> +#ifdef WITH_CONNTRACK
> + nf_conntrack_put(skb->nfct);
> + skb->nfct = &tee_track.ct_general;
> + skb->nfctinfo = IP_CT_NEW;
> + nf_conntrack_get(skb->nfct);
> +#endif
> + /*
> + * Xtables is not reentrant currently, so a choice has to be made:
> + * 1. return absolute verdict for the original and let the cloned
> + * packet travel through the chains
> + * 2. let the original continue travelling and not pass the clone
> + * to Xtables.
> + * #2 is chosen. Normally, we would use ip_local_out for the clone.
> + * Because iph->check is already correct and we don't pass it to
> + * Xtables anyway, a shortcut to dst_output [forwards to ip_output] can
> + * be taken. %IPSKB_REROUTED needs to be set so that ip_output does not
> + * invoke POSTROUTING on the cloned packet.
> + */
> + IPCB(skb)->flags |= IPSKB_REROUTED;
> + if (tee_tg_route4(skb, info))
> + ip_output(skb);
> +
> + return XT_CONTINUE;
> +}
> +
next prev parent reply other threads:[~2010-04-01 10:34 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-31 10:38 nf-next: TEE and nesting Jan Engelhardt
2010-03-31 10:38 ` [PATCH 1/5] netfilter: ipv6: move POSTROUTING invocation before fragmentation Jan Engelhardt
2010-04-01 10:23 ` Patrick McHardy
2010-03-31 10:38 ` [PATCH 2/5] net: ipv6: add IPSKB_REROUTED exclusion to NF_HOOK/POSTROUTING invocation Jan Engelhardt
2010-04-01 8:34 ` David Miller
2010-03-31 10:38 ` [PATCH 3/5] netfilter: xtables: inclusion of xt_TEE Jan Engelhardt
2010-04-01 10:34 ` Patrick McHardy [this message]
2010-04-01 11:39 ` Jan Engelhardt
2010-04-01 11:54 ` Patrick McHardy
2010-03-31 10:38 ` [PATCH 4/5] netfilter: xtables2: make ip_tables reentrant Jan Engelhardt
2010-03-31 10:38 ` [PATCH 5/5] netfilter: xt_TEE: have cloned packet travel through Xtables too Jan Engelhardt
2010-04-01 10:37 ` Patrick McHardy
2010-04-01 11:03 ` Jan Engelhardt
2010-04-01 11:09 ` Patrick McHardy
2010-04-01 13:15 ` Jan Engelhardt
2010-04-01 13:22 ` Patrick McHardy
2010-04-01 13:44 ` Jan Engelhardt
2010-04-01 13:48 ` Patrick McHardy
2010-04-01 13:59 ` Jan Engelhardt
2010-04-01 14:03 ` Patrick McHardy
2010-04-02 18:15 ` Jan Engelhardt
2010-04-06 16:14 ` Jan Engelhardt
2010-04-06 16:37 ` Patrick McHardy
2010-04-07 13:26 ` Jan Engelhardt
-- strict thread matches above, loose matches on Subject: below --
2010-03-31 10:31 nf-next: TEE and nesting Jan Engelhardt
2010-03-31 10:31 ` [PATCH 3/5] netfilter: xtables: inclusion of xt_TEE Jan Engelhardt
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=4BB47698.6070102@trash.net \
--to=kaber@trash.net \
--cc=jengelh@medozas.de \
--cc=netdev@vger.kernel.org \
--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).