* RE: DNAT, Is it possible to find the original destination?
@ 2004-11-08 23:14 Daniel Chemko
0 siblings, 0 replies; 6+ messages in thread
From: Daniel Chemko @ 2004-11-08 23:14 UTC (permalink / raw)
To: Jason Lunz, netfilter
-m conntrack is the key here:
conntrack match v1.2.9 options:
[!] --ctstate
[INVALID|ESTABLISHED|NEW|RELATED|UNTRACKED|SNAT|DNAT][,...]
State(s) to match
[!] --ctproto proto Protocol to match; by number or name,
eg. `tcp'
--ctorigsrc [!] address[/mask]
Original source specification
--ctorigdst [!] address[/mask]
Original destination specification
--ctreplsrc [!] address[/mask]
Reply source specification
--ctrepldst [!] address[/mask]
Reply destination specification
[!] --ctstatus [NONE|EXPECTED|SEEN_REPLY|ASSURED|CONFIRMED][,...]
Status(es) to match
[!] --ctexpire time[:time] Match remaining lifetime in seconds
against
value or range of values (inclusive)
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: DNAT, Is it possible to find the original destination?
2004-11-01 15:30 lumberjack
2004-11-01 16:10 ` Jason Opperisano
@ 2004-11-08 23:09 ` Jason Lunz
1 sibling, 0 replies; 6+ messages in thread
From: Jason Lunz @ 2004-11-08 23:09 UTC (permalink / raw)
To: netfilter
lumberjack@lumberjackvillage.com said:
> iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to 8080
>
> Is there any way that my application can look in the table and see the real
> destination? I've seen several things in patch-o-matic that do things with
iirc, doesn't the SO_ORIGDST sockopt (or something like that) tell you
this?
Jason
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: DNAT, Is it possible to find the original destination?
2004-11-02 6:11 ` Lumberjack
@ 2004-11-02 13:39 ` Jason Opperisano
0 siblings, 0 replies; 6+ messages in thread
From: Jason Opperisano @ 2004-11-02 13:39 UTC (permalink / raw)
To: netfilter
On Tue, Nov 02, 2004 at 01:11:19AM -0500, Lumberjack wrote:
> Couple follow ups. I searched back the last two or three months and didn't
> find any "no nos" on using /proc/net/ip_conntrack. All I can figure is
> that it could be a hit to read through if very large. Not sure yet how
> /proc fs might lock things either (if that might be an issue). So any
> reason for using this to be a "bad thing" please provide some sort of hint
> if possible.
the thread that it ended up coming out in that i was thinking of:
http://marc.theaimsgroup.com/?l=netfilter&m=109649105915501&w=2
and yes--it has to do with read locking.
> Another. If I do something to read in the contents of
> /proc/net/ip_conntrack and then do something to send some output to stdin
> of iptables-restore/iptables does my app need to be GPL based? Boarders
> here seem rather grey. I am not modifying any GPL code nor extending it so
> it doesn't seem to me be something that "modifies" and thus requires to be
> released under the GPL.
can't help ya there...
-j
--
"Here we have an ordinary square.
Whoa! Slow down egghead!"
--The Simpsons
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: DNAT, Is it possible to find the original destination?
2004-11-01 16:10 ` Jason Opperisano
@ 2004-11-02 6:11 ` Lumberjack
2004-11-02 13:39 ` Jason Opperisano
0 siblings, 1 reply; 6+ messages in thread
From: Lumberjack @ 2004-11-02 6:11 UTC (permalink / raw)
To: netfilter
>> Is there any way that my application can look in the table and see the
>> real
>> destination? I've seen several things in patch-o-matic that do things
>> with
>> conntrack but there doesn't seem to be any command, /proc or /dev entry
>> available to query "i have a connection from host foo, iptables, who was
>> foo
>> really wanting to speak too?".
>
> well, in the case of you example port (80), if you're talking about an
> HTTP request, the original destination of the request is preserved in the
> "Host: " header. this is how transparent proxying works.
>
> in the general case, i don't suppose there's anything stopping you from
> performing a lookup against /proc/net/ip_conntrack within your app to
> find the original dst ip (although it's been pointed out here recently
> that lookups against /proc/net/ip_conntrack are a bad idea--check the
> archives).
>
> -j
>
Couple follow ups. I searched back the last two or three months and didn't
find any "no nos" on using /proc/net/ip_conntrack. All I can figure is that
it could be a hit to read through if very large. Not sure yet how /proc fs
might lock things either (if that might be an issue). So any reason for
using this to be a "bad thing" please provide some sort of hint if possible.
Another. If I do something to read in the contents of
/proc/net/ip_conntrack and then do something to send some output to stdin of
iptables-restore/iptables does my app need to be GPL based? Boarders here
seem rather grey. I am not modifying any GPL code nor extending it so it
doesn't seem to me be something that "modifies" and thus requires to be
released under the GPL.
Thanks,
Jason
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: DNAT, Is it possible to find the original destination?
2004-11-01 15:30 lumberjack
@ 2004-11-01 16:10 ` Jason Opperisano
2004-11-02 6:11 ` Lumberjack
2004-11-08 23:09 ` Jason Lunz
1 sibling, 1 reply; 6+ messages in thread
From: Jason Opperisano @ 2004-11-01 16:10 UTC (permalink / raw)
To: netfilter
On Mon, Nov 01, 2004 at 09:30:26AM -0600, lumberjack@lumberjackvillage.com wrote:
> iptables 1.2.9 on SuSE 9.1
>
> I am using iptables redirection to send things inbound to port 80 to
> localhost:8080:
>
> iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to 8080
>
> Is there any way that my application can look in the table and see the real
> destination? I've seen several things in patch-o-matic that do things with
> conntrack but there doesn't seem to be any command, /proc or /dev entry
> available to query "i have a connection from host foo, iptables, who was foo
> really wanting to speak too?".
well, in the case of you example port (80), if you're talking about an
HTTP request, the original destination of the request is preserved in the
"Host: " header. this is how transparent proxying works.
in the general case, i don't suppose there's anything stopping you from
performing a lookup against /proc/net/ip_conntrack within your app to
find the original dst ip (although it's been pointed out here recently
that lookups against /proc/net/ip_conntrack are a bad idea--check the
archives).
-j
--
"If something is to hard to do, then it's not worth doing."
--The Simpsons
^ permalink raw reply [flat|nested] 6+ messages in thread
* DNAT, Is it possible to find the original destination?
@ 2004-11-01 15:30 lumberjack
2004-11-01 16:10 ` Jason Opperisano
2004-11-08 23:09 ` Jason Lunz
0 siblings, 2 replies; 6+ messages in thread
From: lumberjack @ 2004-11-01 15:30 UTC (permalink / raw)
To: netfilter
iptables 1.2.9 on SuSE 9.1
I am using iptables redirection to send things inbound to port 80 to
localhost:8080:
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to 8080
Is there any way that my application can look in the table and see the real
destination? I've seen several things in patch-o-matic that do things with
conntrack but there doesn't seem to be any command, /proc or /dev entry
available to query "i have a connection from host foo, iptables, who was foo
really wanting to speak too?".
Thanks,
Jason
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2004-11-08 23:14 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-11-08 23:14 DNAT, Is it possible to find the original destination? Daniel Chemko
-- strict thread matches above, loose matches on Subject: below --
2004-11-01 15:30 lumberjack
2004-11-01 16:10 ` Jason Opperisano
2004-11-02 6:11 ` Lumberjack
2004-11-02 13:39 ` Jason Opperisano
2004-11-08 23:09 ` Jason Lunz
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.