On 21/04/18 02:18, Rob Janssen wrote:
That would be great! You can start getting a /24 (from your country network or from that 44.190 network, that does not really matter when you are not close to another network like Germany) and setup your system to be on the tunnel mesh. Then you can experiment with the software. In parallel you can get your BGP announcement fixed.
Well, I requested a /24 from the 44.190 block. Figured it's best to keep all of that Internet facing stuff together. I figure it shouldn't take too long to get the BGP announcement done, once I give my provider the details.
That is what the whole proxy/relay thing is about.
OK, well given they've been around for years (and I actually do run a few on the existing /28, private ones for myself and the VoIP Hurricane Net), I was wondering if there was more to this, but certainly, being able to spin up a heap of public proxies and relays would be a good thing. :)
At least, when you have setup geolocation properly for your subnet. When you carve your subnet out of a country network this will work automatically when your coordinator has properly registered the country network. When he/she hasn't, your subnet will likely appear as located in San Diego, California. But you can fix that by sending a couple of registration requests to the most important geolocation providers, easlily found by googling for IP geolocation. This is another disaddvantage of the 44.190 space: you will certainly have to solve this problem yourself.
Though it does mean I know I've addressed the problem. :)
A relay is a bit different. It allows only limited functionality: only outgoing connections, only a single destination at a time. It is used by default by the phone apps. A relay can serve multiple users at the same time, but the group of users can only connect to different destinations. When a user of a relay wants to connect to a destination (e.g. a popular repeater) that has already been connected by another user, the relay will refuse the connection and the app will have to hop over to another relay to try it there. That is why it is suggested to run 10 relays at each site.
Yeah I've found relays to be hit and miss as a user, and having more relays available would certainly help that.
Relays are not automatically registered. They need to be manually registered at Echolink, who will put them in a geo DNS so users will get their address when querying relay.echolink.org and being closest to your relay. Try a dig -t a relay.echolink.org to see what it returns for you (most likely it will return our relays at 44.137.75.x in Amsterdam, not really close for you :-)
Actually, no I get different IPs
;; ANSWER SECTION: relay.echolink.org. 300 IN A 107.23.158.3 relay.echolink.org. 300 IN A 107.23.11.57 relay.echolink.org. 300 IN A 107.23.109.134 relay.echolink.org. 300 IN A 107.23.146.139 relay.echolink.org. 300 IN A 107.23.146.140
They're in the USA, not exactly close, so it's definitely worth running proxies here. :)
*IP Address*
107.23.158.3 *Location* United States, Virginia, Ashburn
That is what we are trying to solve by getting some more relays deployed. But first you can experiment with proxies, you can turn them on or off at your own will. Once you have started to run relays you need to take care that they remain running or when you want to quit, to tell that to the Echolink people so they can take them out of the pool, so users will not have to try to reach them in vain (until they try one that still works).
I've run several proxies for years, but for this new venture, I will have to go over to the proxy software that was mentioned here yesterday. Should free up a bit of RAM to do so, Java is a hog! :)