How-to: Linking servers

These are old archives. They are kept for historic purposes only.
Ron2K

How-to: Linking servers

Post by Ron2K » Tue May 11, 2004 7:09 am

Ron's Guide to Linking Servers

1: Introduction

The question "How do I link servers", or "Help! I've got a problem with linking servers!!!!" gets asked around the forums quite frequently. Actually, a LOT. And it's also one of the most difficult things to get right. Hence this guide, which I'm hoping will answer most of your questions.

2: Getting the basics sorted out

OK, for demonstration purposes, I'm going to call our two servers server1.yourdomain.tld and server2.yourdomain.tld. (This information would be in your Me Block.)

For starters, check the Me Block and make sure that the server numerics are DIFFERENT. You can't link two servers with the same numeric.

Now, I'm assuming that you have a server class set up. If not, do it now. Yes, now. After you're done that, go to your servers' listen blocks and see which ports you can use for the linking (more than likely your dedicated server ports). For demonstration purposes, server1 will have a dedicated server port at 8067, and server2 at 8097.

You'll also need the IP addresses of the two servers. Let's say that server1 has IP 1.2.3.4 and server2 has IP 5.6.7.8. Of course, you can use their real hostnames instead - but note that if you do this, you cannot accept an incoming link (unless you set link::options::nohostcheck) because the hostname is used for connecting and validating incoming connections (the manual has more detail on this point).

OK, now to put in the link blocks.

server1.yourdomain.tld will have the following link block:

Code: Select all

link server2.yourdomain.tld {
	username *;
	hostname 5.6.7.8;
	bind-ip *;
	port 8097;
	hub *;
	password-connect "LiNk";
	password-receive "LiNk";
	class servers;
};
And server2.yourdomain.tld will have this:

Code: Select all

link server1.yourdomain.tld {
	username *;
	hostname 1.2.3.4;
	bind-ip *;
	port 8067;
	hub *;
	password-connect "LiNk";
	password-receive "LiNk";
	class servers;
};
The important thing to remember is that server1 will contain information for linking to server2, and vice versa. Never forget this! On that note, it should be apparent that the name of the link block must match the remote server's name in it's Me Block (see this thread for an example)

OK, now rehash your servers (if you changed the Me Block while you were sorting out your numerics, you'll have to restart), and then you should be able to connect them up using the /CONNECT command.

If it doesn't link, check everything again. If it still doesn't work, then post in these forums for help. If your link does work, well then it's time for some fine-tuning.

3: Fine-tuning your link

Encrypted connections: You might want to encrypt the connections between the two servers to prevent "sniffing". In fact, you SHOULD do this. Now, obviously your IRCd's need to be compiled with SSL support for this to work. Then, you need to make your dedicated server ports SSL-only. Once you've done that, go to your link blocks and add the following code to them:

Code: Select all

	options {
		ssl;
	};
That should do it.

The above code would be referred to by the UnrealIRCd team (as well as the Fine Manual) as link::options:ssl.

Compressed connections: I can't think of a good reason why you wouldn't want to compress the data streaming between the two servers. It will save you plenty of bandwidth, believe me. Firstly, you'll need to have both servers compiled with zip support (if you're using the Win32 build, it's enabled). Now, go and add the link::options::zip option to the options section that we put in earlier, so that you get something like this:

Code: Select all

	options {
		ssl;
		zip;
	};
One important note: you'll need the zip option set at BOTH ends.

If you're particularly picky, you can use link::compression-level to set the level of compression.

Hub vs leaf? A hub has multiple servers linked to it, while a leaf can only link to one server. Now, let's say that you want server2 to be a leaf. Go to server1's configuration file and change link::hub to link::leaf so that you get something like this:

Code: Select all

link server2.yourdomain.tld{
	...
	leaf *;
	...
};
Now, the manual states the value attached to link::leaf is "a mask that this server will act like a leaf towards". So if you need to change it, then change it, otherwise leave it alone.

(You may also want to play around with link::leafdepth, but I don't know much about it and so would welcome some information in this regard.)

One last, very important thing. A server is EITHER a hub OR a leaf. You CANNOT combine these two options.

Changing hosts: Use link::options::nodnscache (doesn't cache the IP for outgoing server connections) and/or link::options::nohostcheck (doesn't validate the link::hostname). That should sort that little issue out.

Auto-connect: Use link::options::autoconnect. The time between connection attempts is specified in class::connfreq for the class you're using. You need only enable this from one side

4: Special information for linking services

Firstly, you CANNOT use ssl or zip in your options unless your services supports these. And they probably don't.

Secondly, you should ALWAYS set your services server to be a hub and not a leaf. The reason for this is because the OperServ JUPE command introduces fake servers onto your network, and obviously this won't work correctly if your services server has been specified as a leaf.

Thirdly, services will connect to you. Don't try and connect to it. Which means: don't try use /CONNECT on it, and take out link::options::autoconnect for your services server if it's there.

Finally, EVERY server on your network will need a U-Line for your services server for it to be able to change the modes correctly. The best way to do this is by using remote includes if every server on your network has them enabled.

5: Frequently Asked Questions
  • How do I set it up so that if the connection with one server fails, my server connects to another server?
    This is what deny link blocks are for. Taken from a codemastr post: "You setup a condition for hub2 so that it is only linked to if hub1 is not around." You might also want to see this thread.
  • Can I link my server to two hubs?
    This really depends on what the resulting network topology will look like. If you end up with something like this:

    Code: Select all

    HUB1 ------- YOU ------- HUB2
    ...then you should be fine. If however, you end up with something like this:

    Code: Select all

    HUB 1 ------- HUB 2
        \         /
         \       /
          \     /
           \   /
            YOU
    (Yes, I know that my ASCII art sucks...)

    ...well, that won't work. Circular topologies aren't allowed when linking IRC Servers (it's explicitly mentioned in RFC1459).
6: Conclusion

Well, I hope that this guide answers most of your questions and solves most of your problems. If this doesn't help, post in the support forums and we'll be quite happy to help you.

If you notice any errors in this guide, please point them out to me. After I'm through with kicking myself, I'll correct them.
Last edited by Ron2K on Sat Apr 02, 2005 10:58 am, edited 4 times in total.

jewles
Posts: 263
Joined: Thu Mar 11, 2004 7:41 pm
Location: Herndon, VA
Contact:

Post by jewles » Tue May 11, 2004 6:09 pm

LoL Thats Awesome... :) Sucks that it will probably only be read by small 20% of people! :) :lol: :lol: :lol: :lol: :lol: :lol: <== my army
Last edited by jewles on Mon May 17, 2004 6:31 pm, edited 1 time in total.
FBSD-DEV Project
http://www.fbsd-dev.org

YatesDev Hosting
http://www.yatesdev.com

The Wrong Way
http://www.thewrongway.net

Syzop
UnrealIRCd head coder
Posts: 1795
Joined: Sat Mar 06, 2004 8:57 pm
Location: .nl
Contact:

Post by Syzop » Tue May 11, 2004 7:51 pm

You probably want to make the link::hostname stuff a bit more clear.. coz, this won't work:
Of course, you can use their real hostnames instead.
If you have a hostname (eg blah.blah.org) in link::hostname you cannot accept an incomming link (unless you have link::options::nohostcheck set) since the hostname is used for both connecting AND validating incomming connections, and for the latter only ips will work. This is quite clearly documented in http://www.vulnscan.org/UnrealIrcd/unre ... #linkblock ;).

[*edit* made sticky already */edit*]

Ron2K

Post by Ron2K » Tue May 18, 2004 5:48 am

Syzop wrote:You probably want to make the link::hostname stuff a bit more clear.. coz, this won't work:
Of course, you can use their real hostnames instead.
If you have a hostname (eg blah.blah.org) in link::hostname you cannot accept an incomming link (unless you have link::options::nohostcheck set) since the hostname is used for both connecting AND validating incomming connections, and for the latter only ips will work. This is quite clearly documented in http://www.vulnscan.org/UnrealIrcd/unre ... #linkblock ;).

[*edit* made sticky already */edit*]
Added, thanks - I'd forgotten about it. (I wrote it from memory, you see.)

jewles
Posts: 263
Joined: Thu Mar 11, 2004 7:41 pm
Location: Herndon, VA
Contact:

Post by jewles » Tue May 18, 2004 10:38 am

might also be better to be consistent and to leave the port the same throughout the entire link


server1.yourdomain.tld

Code: Select all

port 8097;
server2.yourdomain.tld

Code: Select all

port 8067;
FBSD-DEV Project
http://www.fbsd-dev.org

YatesDev Hosting
http://www.yatesdev.com

The Wrong Way
http://www.thewrongway.net

Ron2K

Post by Ron2K » Tue May 18, 2004 11:53 am

I deliberately used different ports for demonstration purposes.

Syzop
UnrealIRCd head coder
Posts: 1795
Joined: Sat Mar 06, 2004 8:57 pm
Location: .nl
Contact:

Post by Syzop » Tue May 18, 2004 6:35 pm

Looks good now :).
I deliberately used different ports for demonstration purposes.
Exactly.

Dukat
Posts: 1083
Joined: Tue Mar 16, 2004 5:44 pm
Location: Switzerland

Post by Dukat » Tue May 18, 2004 6:51 pm

To make things more interesting you could use different passwords... :wink:

I'm asking myself how many people out there are using "LiNk" as their Password... Probably a LOT :shock:

Melkor
Posts: 8
Joined: Sun Jul 11, 2004 6:39 am

Hmmpf

Post by Melkor » Sun Jul 11, 2004 7:24 am

Code:
link server2.yourdomain.tld{
...
leaf *;
...
};
do I add the leaf to the Hub server or the connecting server?

for instance, would it be

(on hub config)
link Logic.CA.US.XeroLogic.net
{
username *;
hostname 63.110.126.238;
bind-ip 63.110.126.237;
port 5050;
leaf *;
password-connect "****";
password-receive "****";
class servers;
options
zip;
}
(IRCD config)
link Hub.Us.XeroLogic.net
{
username *;
hostname 63.110.126.237;
bind-ip 64.110.125.238;
port 5050;
hug *;
password-connect "****";
password-receive "****";
class servers;
options
zip;
}
would that work?

because it seems to be givng me major problems

Ron2K

Re: Hmmpf

Post by Ron2K » Thu Jul 22, 2004 12:05 pm

Melkor wrote: (IRCD config)
link Hub.Us.XeroLogic.net
{
username *;
hostname 63.110.126.237;
bind-ip 64.110.125.238;
port 5050;
hug *;
password-connect "****";
password-receive "****";
class servers;
options
zip;
}
would that work?

because it seems to be givng me major problems
How about a hub? :P

Also, try link::bind-ip *

It would also be helpful if you post the error messages that you're getting, so that we can see exactly where your problem is.

pomme
Posts: 7
Joined: Sat Oct 09, 2004 6:30 am

Post by pomme » Mon Nov 01, 2004 1:29 am

Using easy passwords for server linking is very bad. Imagine if someone spoofed the IP, and then connected to your server, sending RAW IRC commands like SERVER... to initiate a server<-->server connection. You wouldn't want your IRC network hijacked over something simple that could be avoided by choosing a more complex password.

w00t
Posts: 1136
Joined: Thu Mar 25, 2004 3:31 am
Location: Nowra, Australia

Post by w00t » Tue Nov 02, 2004 12:45 am

Have you tried doing it? It isn't that easy.
-ChatSpike IRC Network [http://www.chatspike.net]
-Denora Stats [http://denora.nomadirc.net]
-Omerta [http://www.barafranca.com]

aquanight
Official supporter
Posts: 862
Joined: Tue Mar 09, 2004 10:47 pm
Location: Boise, ID

Post by aquanight » Tue Nov 02, 2004 12:58 am

Actually it is. Servers don't get NOSPOOF protection. (Runs off the bugtracker to suggest :P .) This means that someone could establish a successful connection without needing to know what they've been sent. The only trick is getting a hold of the IP the server is allowed from. Of course, if the server is *, then...

w00t
Posts: 1136
Joined: Thu Mar 25, 2004 3:31 am
Location: Nowra, Australia

Post by w00t » Tue Nov 02, 2004 12:59 am

aquanight wrote:Actually it is. Servers don't get NOSPOOF protection. (Runs off the bugtracker to suggest :P .) This means that someone could establish a successful connection without needing to know what they've been sent. The only trick is getting a hold of the IP the server is allowed from. Of course, if the server is *, then...
Well, yes that was my first thought, nospoof. If that doesn't work, then ah well. But the attacker must know the IP/port that the other server is meant to be running on (unless, as you pointed out, the dumbasses use "*")
-ChatSpike IRC Network [http://www.chatspike.net]
-Denora Stats [http://denora.nomadirc.net]
-Omerta [http://www.barafranca.com]

pomme
Posts: 7
Joined: Sat Oct 09, 2004 6:30 am

Post by pomme » Tue Nov 02, 2004 6:02 am

All IPs can be spoofed. Don't think an anti-spoofing device will prevent people from spoofing your IP. IP headers can be modified quite easily. I know you won't believe me here, but I could show proof. However, I *could* show proof, but I won't, simply because I don't want to let everyone know how to get cracking tools. The internet is bad enough as it is with crackers. We don't need more.

Locked