ID:815950
 
Keywords: bind, byond, force, ip
I'm setting up a server on a linux dedicated box and I'm getting ready to add a couple of ip's to the box. Is it possible to bind dream daemon to an ip currently?
No, there's no way to manually bind it to a network interface, but it should be accessible from the external IP regardless of which internal IP it's running from -- as long as the ports are forwarded correctly.
I want to ensure the correct ip is put onto the hub though. Not all of my addresses will allow this connection for security reasons.
In response to Techy2493
Techy2493 wrote:
I want to ensure the correct ip is put onto the hub though. Not all of my addresses will allow this connection for security reasons.

You can open a port to one IP address using iptables.

If the port isn't open on another IP they can't enter the game.
I know this, but I need some way of ensuring Byond puts the correct ip address onto the hub. If it picks the wrong one no one will be able to connect. Does it cycle through possible ip's and pick one players are able to connect to or just pick the first one it can?
I assume that what A.T.H.K saying is that when you block the port your world uses on IPs, BYOND HUB won't be able to notice those IPs and therefore they won't show up.

What you should do is set DreamDaemon to run on a specific port* (try "man DreamDaemon") and then use iptables or a software to block your DreamDaemon port for the IPs that you don't want to be seen. Make sure you don't block the port for the IP you want to use.

Edit: *Thanks to Murrawhip or otherwise I wouldn't notice. I meant port not IP, sorry.
In response to Phoestre
Phoestre wrote:
What you should do is set DreamDaemon to run on a specific IP (try "man DreamDaemon")

There is no way to do this yet, which is what this feature request is for.

Phoestre wrote:
and then use iptables or a software to block your DreamDaemon port for the IPs that you don't want to be seen. Make sure you don't block the port for the IP you want to use.

DreamDaemon will attempt to host on the single IP address that it chooses to use (I think it might be the last alias with Internet? I haven't determined what its selection criteria are yet), and if the port doesn't let it through, it will fail. It doesn't try other IP addresses, in my testing.
Sorry Murrawhip, I meant port not IP :/ I guess one should triple-read before posting lol.

I'm not sure but usually softwares(therefore I think Dream Daemon should be similar) merely broadcasts and listens on the port specified.

Therefore if more than a single IP resolves to a computer, they all would reach the Dream Daemon as long as the port is not blocked.

In response to Phoestre
Phoestre wrote:
Therefore if more than a single IP resolves to a computer, they all would reach the Dream Daemon as long as the port is not blocked.

Yep this is true, but DreamDaemon can only select one IP address to tell the hub to broadcast.
Personally, I want to host DreamDaemon on port 80 on one of my other IP addresses. I'm just going to have to wait for a bind IP function, methinks.
I haven't tried but DreamDaemon might not be selecting an IP at all. It is most likely sending a POST to BYOND HUB or opening a socket.
On the other side, BYOND HUB tries to resolve the IP and tries to send back a POST, or use the open socket to confirm it can reach.

If that is how it works, the IP should be the one with the least hop route(ideally). But don't be surprised if thats not it, because there is so much to take into consideration as ISPs/hubs between BYOND server and DreamDaemon may not necessarily point the connection to the route with least hops.
DreamDaemon will host on all available IP addresses. So if you have 3 network cards, each with a different IP address, it will start hosting on all of them at once.

Currently this cannot be changed, meaning if you want to prevent access from a particular IP address you have to set up the firewall to block it, which is an annoying way of doing it because you'll lose a network port on all other IP's on the machine you're hosting from.
JBoer, the problem they're figuring out though is which interface it contacts the hub on even though it's listening on all. The answer probably lies somewhere in the kernel of whatever distribution you're using.
Simply the software must support binding IP's. I guess you can do it a few hacky ways.

This may interest you - http://daniel-lange.com/archives/ 53-Binding-applications-to-a-specific-IP.html - I didn't read it, didn't have time I just googled...
The most likely scenario is DD doesn't contact HUB through a specific network card. It is just that when HUB tries to contact back(after resolving the IP), it ends up at one of the network cards due to the way ISPs routed it.

Although I don't think it is the end of world to block a few ports on all other IPs as there are still so many other ports that you won't need to use all of them in your lifetime lol.

ATHK's link explains how to bind any software to a specific IP on linux. However the way it works is, you bind the software to a specific *LAN* IP. So before doing that, you should figure out which LAN IP resolves to the real/WAN IP you want. It is easy but things may get complicated for non technical users.
We don't really have non-technical users on Linux, trying to do this. It's not really a scenario they bother with.
In response to Audeuro
Audeuro wrote:
JBoer, the problem they're figuring out though is which interface it contacts the hub on even though it's listening on all. The answer probably lies somewhere in the kernel of whatever distribution you're using.

Oh. In that case it would be through the network card configured on the system that has the highest priority.

On Windows machines anyway every network card has a certain priority. AFAIK the one with the highest priority is used for outbound traffic.

On Linux I would expect "eth0" to be the one that gets the highest priority. There's probably a list somewhere.
You don't really bind to an adaptor in Linux, only addresses. The kernel's routing table handles shifting data to/from interface.
In response to Phoestre
Phoestre wrote:
The most likely scenario is DD doesn't contact HUB through a specific network card. It is just that when HUB tries to contact back(after resolving the IP), it ends up at one of the network cards due to the way ISPs routed it.

DD does in fact contact the hub to inform it that it is a live world, and it goes from that address. The hub grabs the world address from there and translates that to the BYOND.world URL. The part that you care about is the interface/IP selected by the kernel to go outbound.
In response to Audeuro
Audeuro wrote:
Phoestre wrote:
The most likely scenario is DD doesn't contact HUB through a specific network card. It is just that when HUB tries to contact back(after resolving the IP), it ends up at one of the network cards due to the way ISPs routed it.

DD does in fact contact the hub to inform it that it is a live world, and it goes from that address. The hub grabs the world address from there and translates that to the BYOND.world URL. The part that you care about is the interface/IP selected by the kernel to go outbound.

I'm not saying otherwise :) What I meant is DD doesn't select a network card specifically. I'm not saying it doesn't contact to HUB :)