Re: Connect to localhost bound port from outside?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Pascal Hambourg wrote:
Yes. This is not a reverse path issue, as rp_filter=1 checks only the
source address, not the destination address.
Ah.
AFAIK, it is hard coded. I guess the reason is that RFC 3330 reserves
127.0.0./8 for the loopback and prohibits its use on any network outside
the host. Unfortunately, the routing code does not know that the packet
was DNATed and has an original non-loopback destination address.
*nod*
I do not see how a dummy interface might be useful here. Can you please
clarify ?
(See below)
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. Dummy network
is akin to a network card that does not talk to any thing else. 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.
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.
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.
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. 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.
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. So, you could possibly have a different
management IP / interface (pair) than public service IP / interface
(pair) on the system. You could also have all management access pass
through the filter:INPUT and public service pass through filter:FORWARD.
Or, if you are worried about the overhead of forwarding traffic to get
to your public services, you could reverse things and put public on the
main IP / interface and management on the dummy IP / interface. Thus
segregating which traffic is filtered where.
I don't know if there is an benefit / harm in doing things either way,
it's just an idea that I had.
One use that I do see for such a dummy network would be in a lab type
environment where some sort of routing protocol is running on each
system, students could create / destroy networks on dummy as they wanted
to (so long as they did not conflict) with a benefit of each system in
the lab being able to route to each and every dummy network for testing
/ learning type of exercises.
Grant. . . .
[Index of Archives]
[Linux Netfilter Development]
[Linux Kernel Networking Development]
[Netem]
[Berkeley Packet Filter]
[Linux Kernel Development]
[Advanced Routing & Traffice Control]
[Bugtraq]