On Thu, 11 Sep 1997, Peter Hartman wrote:
> -- Hello,
> I have been mulling this one over and wanted to throw it at you all to
> see if ideas could be had. My mud is running on a machine behind a
> firewall. The firewall machine is linux-2.0.30 running ipfwadm and
> redir
> (redir redirects port 4000 from gateway -> internal_mud_machine).
> However
> the mud machine (which is masqueraded) thinks that every connection is
> from gateway, rather than unique hosts. How can I fix this? Can you
> point me in the right direction on what files to dig through to have the
> mud detect the actual host.
You need to dig through the redir source code and figure out how to make
it communicate to circle the correct source ip. Unless the mud and redir
are on the same machine, there's no way to get the correct ip by changing
circle.
Why? Redir doesn't redirect the socket channel as the name implies. All
it does is create a new outgoing socket to your mud for each incoming
socket on that port, copying data between the two connections. Since all
connections to the mud are sockets that originate from the gateway, accept
correctly returns the gateway machine as the source ip.
It probably wouldn't be too hard to fix this if you've got the redir
source and you like sockets :) Have redir open a connection to the mud on
a port other than the normal mud port to use as a communications channel.
Then, each time redir opens a player connection, pass the actual ip to the
mud using the secondary port. If you have timing problems, pass each
redir outgoing port number together with the player's ip, so the host can
check through descriptors to find the connection with a port match. Note
that stock circle doens't keep track of the peer's outgoing port, but you
can add the port to descriptor_data and set it to ntohs(peer.sin_port).
Does that answer your question?
Sam
+------------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://democracy.queensu.ca/~fletcher/Circle/list-faq.html |
+------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/08/00 PST