All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pascal Hambourg <pascal.mail@plouf.fr.eu.org>
To: Mail List - Netfilter <netfilter@lists.netfilter.org>
Subject: Re: Connect to localhost bound port from outside?
Date: Thu, 01 Feb 2007 00:01:48 +0100	[thread overview]
Message-ID: <45C11FDC.4030908@plouf.fr.eu.org> (raw)
In-Reply-To: <45C0E06F.3080405@riverviewtech.net>

Grant Taylor a écrit :
> 
>>> I have often considered using lo for local only but using dummy as a 
>>> spur network to bind services to and then route traffic in to the 
>>> spur network.  Thoughts / Opinions?
>>
>> A dummy interface is a black hole, a kind of "/dev/null" interface, 
>> traffic you route to it is lost. This is very different from a 
>> loopback interface, whose traffic you route to it loops back and is 
>> received by the local host. It is fine to use a dummy interface if you 
>> want to add an extra address to the host and bind services to it, but 
>> I guess you could do the same with the loopback interface.
> 
> I beg to differ.  Loop back is ONLY for the local host.  However, Dummy 
> is not only for local host.  Dummy is *usually* used for local host 
> only, however this is not an kernel enforced limitation.

So far, we both agree that loopback and dummy interfaces are very 
different. :-)

> Dummy network 
> is akin to a network card that does not talk to any thing else.

You can remove "else". A network card that does not talk to anything.

> I.e. if 
> I put a loop back plug in an ethernet card so that it sees its self UP 
> and UP (Cisco terms).  Then I can configure any computer to access the 
> dummy network VIA the computer that dummy is on.

Yes. But actually you access nothing but void.

> To verify this, I just brought my dummy net up with a 192.0.2.254 IP 
> address.  I then went to my Windows VM session and added a route to the 
> 192.0.2.x/24 network via my Linux host.  My Windows VM was able to ping 
> the 192.0.2.254 IP address on the dummy network.

Yes, but doing this you do not access the dummy network. You just access 
the dummy interface _address_ like any other address owned by that host. 
The dummy interface nevers sees that traffic. You could do the same just 
by adding that address to any other interface, including the loopback 
interface lo.

> With this in mind, if the dummy network is used to bind services to, it 
> would be possible to DNAT traffic destined to the local system in to the 
> dummy network with out being stopped the way that loop back does.

I am not sure I get what you mean... Maybe an example would help.

> Now, what I'm not sure about is if it would be possible to not use lo 
> but use dummy in place of it.  I.e. lo is down and down with dummy up 
> and up with 127.0.0.1 on it.

Hmm... You don't want lo to be down, else the host cannot communicate 
with itself any more.

> In this case I don't know if you could 
> DNAT traffic in to 127.0.0.1 from external or not.  And as I write this, 
> I think that this may be more of a problem with routing than interface. 
> If it is the routing code that says the only thing that can speak to 
> 127.x.y.z/24 is 127.x.y.z/24 then this will do no good.

The routing code does not say that only 127.0.0.0/8 (not /24) can talk 
to 127.0.0.0/8. Actually any address allocated to any interface on the 
host (which I call a local address) can talk to 127.0.0.0/8 and 
conversely. The routing code says that you can talk to or from 
127.0.0.0/8 only through the loopback interface. So giving 127.0.0.1 to 
another interface won't help.

> One thing that I do see as an advantage of using dummy in this way is 
> that it would be possible to bind services to the dummy IP which would 
> cause traffic destined for public services to pass through the 
> filter:FORWARD table / chain.

Huh ? Traffic destined to a local service goes through the INPUT chain, 
not the FORWARD chain. Whether the IP address you bind the service to 
belongs to a loopback interface, a dummy interface or any other 
interface does not make a difference. All local addresses belong to the 
host and create a local route in the special "local" routing table.


  reply	other threads:[~2007-01-31 23:01 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-31  7:33 Connect to localhost bound port from outside? jan_bar
2007-01-31  9:03 ` Покотиленко Костик
2007-01-31  9:43   ` jan_bar
2007-01-31 10:39     ` Martijn Lievaart
     [not found]     ` <46560.2001:888:19e1::53.1170239989.squirrel@dexter>
2007-01-31 11:52       ` Martijn Lievaart
2007-01-31 10:13 ` Pascal Hambourg
2007-01-31 15:36   ` Grant Taylor
2007-01-31 16:03     ` Pascal Hambourg
2007-01-31 18:31       ` Grant Taylor
2007-01-31 23:01         ` Pascal Hambourg [this message]
2007-01-31 23:57           ` Grant Taylor
2007-02-06 19:13     ` R. DuFresne
2007-02-06 19:38       ` 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=45C11FDC.4030908@plouf.fr.eu.org \
    --to=pascal.mail@plouf.fr.eu.org \
    --cc=netfilter@lists.netfilter.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.