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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.