From: Andy Furniss <adf.lists@gmail.com>
To: lartc@vger.kernel.org
Subject: Re: Help setting up home router
Date: Fri, 09 Jan 2015 11:20:20 +0000 [thread overview]
Message-ID: <54AFB974.20404@gmail.com> (raw)
In-Reply-To: <CAMrm09rXi68Rw1h+SGdU=Ja-BsMhXPKZ5dcY15DgPbUH0-_wEg@mail.gmail.com>
Gonçalo Luiz wrote:
> Hi,
>
> I've been reading all the material I could get my hands on, but
> there is a small detail I seem unable to get my head around. Let me
> show you my setup first
>
> 1 linux PC (router) with two physical NICs: eth0 (inner facing) and
> eth1 (outer facing) many clients behind a switch to where eth0
> connects to three network namespaces in the router, whose veths
> bridge with eth0 in br0 one OpenVPN VPN running on the router,
> through which I'm sending some traffic originating from a few source
> IPs. Let's call it tun0
>
> what I want to do: apply traffic control to the outer facing,
> controlling *all* the outgoing traffic. For simplicity let's assume
> I want to apply the rules based solely on the source IP
>
> my first instinct was to configure the qdiscs on eth1 egress. Seems
> to me that this is the only way I can also apply the control to
> packets originating in the router as they go straight away to the
> exit interface (eth1).
>
> The problem I'm facing is that the traffic that goes through tun0
> presents itself to eth1, obviously, already compressed and without
> the real source IP information (can come from any of the clients or
> network namespaces on the router) and therefore I cannot infer what
> class should assign to it. In practice, VPN turns all it's traffic
> opaque and I cannot treat it differently depending on the client
> originating it.
>
> my second instinct was to shape tun0 ingress (through an IFB) along
> with eth0 egress by redirecting both to an IFB and shapping it
> there. Sadly this leaves traffic originating in the router itself
> out.
>
> lastly I've tried to add an iptables mark to the packets that are
> going through tun0 before they go through the compressing process
> but it seems to be lost when they come out of the other side of it.
> If they were not perhaps I could apply traffic control based on
> iptables marks instead of source IPs if I marked all the packets as
> soon as they land on the router or are originated in the router.
>
> Any ideas? I fell this must be possible but am running out of ideas.
Untested and probably not thought through very well!
Maybe you can redirect to the same ifb from tun0 and eth1 use iptables
marks to distinguish what came in eth0 (rules/mark in forward) and local
(rules/mark in output) then redirect to the same ifb from tun0 and eth1.
Some thoughts/hints.
Good that this is egress.
If you want to add a filter to an egress IF you need some qdisc on it so
add prio.
You need to avoid doubly catching tun0 traffic so mark everything you
need to shape and on eth1 just redirect marked traffic (this assumes you
can find a way to make all tun0 traffic on eth1 not be marked but still
mark local in output hmm - I am not sure about tuns and how/where tunnel
traffic is seen by netfilter).
To do this work in full 32bit hex (iptables) for the marks and use u32
to match the marks on filters so you can use masks. This way you could
arrange for say the top bit to be set on everything marked so you could
filter just on that bit for the redirect on eth1. For the filters on ifb
qdisc you can then exclude that bit.
Some testing/trial and error needed :-)
prev parent reply other threads:[~2015-01-09 11:20 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-08 9:39 Help setting up home router Gonçalo Luiz
2015-01-08 23:12 ` I-Strong, Russell J
2015-01-09 8:49 ` Gonçalo Luiz
2015-01-09 9:21 ` Dave Taht
2015-01-09 11:20 ` Andy Furniss [this message]
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=54AFB974.20404@gmail.com \
--to=adf.lists@gmail.com \
--cc=lartc@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.