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.
