For some time we have been hosting Echolink proxies and relays on the system that is the
gateway for 44.137.0.0/16 (BGP routed) in Amsterdam, Netherlands. We use a /24 subnet for that.
Such proxies and relays facilitate the use if Echolink by users and repeaters that are behind NAT
or are otherwise firewalled. About 100 repeaters around the world use our proxies, and over 600
users of the mobile app use our relays.
Each Echolink proxy and relay requires a different IPv4 address. This can be a static address on
internet, but often people have no /24 to spare for such things. AMPRnet provides the required
address space. (unfortunately with an unintended side-effect, but in general it works well)
For performance of the Echolink system it would be best when there are more places with a similar
setup, distributed around the globe.
Are there other BGP-routed sites outside Europe where such a service could be run?
I have written a C program for this, that uses considerably less resources than the original Java
software. On a 2.67GHz XEON server it causes a load around 0.05 for our 200 proxies and 10 relays.
Of course it makes some network traffic, about 3 GB/day for the relays and similar for the proxies.
When you have your gateway located in a suitable datacenter and are interested in such a setup
to facilitate Echolink, please send me an e-mail and I can provide more info.
Maybe we could even get the whole echolink.org infra hosted on AMPRnet space, which would solve
the problem there now is with partially connected AMPRnet networks.
(when the directory server is on AMPRnet, the problem with NAT between HAMNET and internet disappears)
Rob
> This is not a special problem for the 44.190 space. It affects every
> direct connected 44 announcement for those users that cannot use IPIP
> tunneling because they don't have a plain IPv4-connection. In Europe it
> is very common to give normal customers a so called "DS-Lite Connection"
> or a plain IPv6-connection. Everything that must be reached in the
> IPv4-world from those custumers sites mostly goes through this ugly
> "carrier-grade-nat (CGN)" which in most cases doesn't work very well for
> our special needs.
IMHO the preferred solution for this is to setup regional routing points
where IPIP (and preferably BGP announcement) is possible, and where those
users that have limited internet connections can connect via a VPN technology
that still works for them. This way, their HAMNET traffic can be forwarded
untranslated.
It is the method that we use, and various others do it as well. As was
shown before on this thread, VM/VPS services that can be used for this are
widely available. And those do not suffer from having CGNAT or dynamic
addresses. At least not yet.
Rob
> Wasn't the idea to 44.190.0.0/16 subnets available via BGP? If so, why
> would there be NAT?
Of course for directly connected networks there will be no NAT, but there are those networks
that are connected to internet via consumer internet connections (and no IPIP tunneling)
and the traffic from those networks to the 44.190 space will pass through NAT routers.
Rob
> 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! :)
The Java proxy server requires 25-30 MB of memory for each instance, which can run 1 proxy.
The C version I wrote uses about 2.5 MB of memory to run 200 proxies and 10 relays in a single process.
Rob
> Well, I have a VPS in Melbourne, which runs IRLP reflector 9550, among
> other things. I currently have a /28 of public (non AMPR) IPs, which
> are fully utilisied by Echolink. I could ask about getting a /24 BGP
> announced, so I could participate.
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.
> One thing I am not seeing addressed by this proposal is what happens
> with the nodes themselves, which are the the most problematic part of
> Echolink (and IRLP) due to their incompatibility with NAT (requiring
> port forwarding to work at all).
That is what the whole proxy/relay thing is about.
A proxy lives on a system with unlimited UDP access from/to internet (port 5198/5199)
and it also listens on port 8100 (default) for TCP connections from a repeater, link
or user who is behind NAT. When a user connects it relays the UDP traffic from those
ports to the TCP connection, and vice-versa. So it solves the NAT problem for that
specific user, while preserving full functionality (the user behind the proxy can
connect to several other stations and accept connections from other stations all at
the same time). But a proxy can be used only by one user at the same time, that is
why you want like 200 proxies. Proxies register themselves at Echolink.org, and a
user wanting to use one can retrieve a list from the server and select one, some clients
can automatically pick a non-busy proxy from that list. The Echolinks server sorts
the list by geolocation distance to the requester, so your own proxies will appear
at the top of the list.
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.
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.
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 :-)
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).
Rob
> I think original routing methods are not easy to use and have drawbacks :
> - eBGP is not available to end-users, or even to small teams or repeater
> operators. It requires network skills, and access to telecom operator
> data centers.
I think end-users or teams should not try to use eBGP unless they want
to do it as another learning project as part of their AMPRnet gateway.
Announcing your AMPRnet allocation on internet is simply a matter of
telling your colocation/VPS hosting company that you have portable address
space that you want to announce on internet and route that to your server
or router. That is a standard change in their portfolio, they do that
for lots of other customers and for them it is a simple matter of
configuration in their existing network. They know how to do it and
they already monitor it.
When you do it yourself, you will have to get an AS, peering, setup
your router, cope with the vast amount of routes and the processing
and storage they require, etc. Not something to embark on lightly,
and usually not necessary at all.
> As far as I can tell, one of them (VE7ALB) is in Canada, and the
> other three (KK6NEI, K4JH, W6KWF) are in California and plan to
> locate their Echolink relays in the same data center in Fremont,
> California. I wonder if it would be beneficial for those three to
> pool their resources in some way?
I agree that is not an optimal situation. It would be better to cooperate
and maybe setup 3 or 5 relays each, and some proxies. It can be good to have
some redundancy but it makes little sense to have 30 relays and 600 proxies
all in the same state. I wasn't aware that this is the case, the USA
is big and relays in California, New York and Texas would have been fine :-)
Rob
> I just applied for a /24 out of 44.190/16, to help with this endeavor.
> I’ll be announcing the prefix out of a commercial datacenter in Fremont, CA under ASN 7247.
I advise you (like is best for everyone who announces 44Net space on BGP) to make the system part of the IPIP tunnel mesh as well.
I.e. make a tunl0 interface and run ampr-ripd on it, register it as a gateway using an extra IP address outside the /24 subnet.
Add only the routes received over RIP, not a default route to ampr-gw. Of course you have a default route to your BGP router.
This ensures that you are reachable for all AMPRnet hosts as well as normal internet systems, even when they cannot route their traffic transparently over internet themselves.
It looks like we have 3 interested parties in the US and Canada, which would certainly help out for now.
It would be nice if someone in the far east or Australia could join in. We always have a large number of users from Thailand, for example.
Rob
> One of the main purpose of amateur radio is to experiment new things.
> Then, I think it's globally a good idea to experiment new routing
> variants, that are more suitable with today and tomorrow usages. Of
> course, this will raise compatibility issues and routing problems. But
> that's our job to find solutions :-)
In general I think that is true. But in this particular case, that experiment is just there
to work around unfortunate decisions made in the past. I can understand that it is now a lot
of work to re-work the German HAMNET to make it compatible with a plain routed address space,
but I do not see it as my responsibility to jump through hoops instead.
When it would be a simple change, I would not have a problem. But as it is now, it is just as
much work for us to cover their irregularities than it is for them to adapt their network.
In that case I favor the "clean solution".
> Here, in Corsica, we'll try to adapt our home-made system (OpenVPN
> tunnels to two central gateways, and OSPF routing through 10.0.0.0/8
> private addressing) to AMPR addressing. One of the main advantages is
> that user connection is very easy (we developed a Plug and Play system
> called "TKBox" : an OpenWRT router, which opens VPN tunnels to our two
> data centers, in VPN pass-through mode). It's suitable for a remote
> location such as our island, because our two data centers will be the
> only points of connection with the outside world. All the specific
> routing and firewalling has to be tone only there.
That is very similar to what we do here on the 44.137.0.0/16 network and you will not encounter
the difficulties of NAT when you do it that way. All traffic internal and outside of your network
is just plain routed. We use OpenVPN only for end-users that connect to our gateway and get
44Net space but only over the tunnels. However, that is the "novice class" of AMPRnet, we really
do not want users to connect that way forever. They should use radio links, and when no access
point is available they should get together and establish one. And that is developing rapidly.
Of course access points would ideally be linked to other access points via radio, but until their
density is sufficient to make that possible we also allow a VPN connection to a central router
located in the datacenter, either GRE or L2TP/IPsec, and we run BGP over that connection so it
can be used for the connectivity to AMPRnet or as a backup in case their are problems with the
radio link. Radio links have preference in the recommended BGP setup.
In this network we have untranslated internet access for every station because we do not directly
send traffic on a user's internet connection (only the tunneled traffic to the central router that
forwards the encapsulated 44Net packets to internet).
In my opinion that is the correct way to do it.
Of course if you want to setup many gateways like that across a larger country, the practical
difficulty is that you need to negotiate BGP routing in many places. It is so much easier to just
give in on that and go out via NAT over some local amateur's internet connection.
But it causes the problems that Jann is now facing.
Rob
[This has been forwarded to a number of mailing lists, but in
case you haven't already seen it, you may find it of interest.
This copy was received from the NANOG list. - Brian]
Begin forwarded message:
From: Alexander Isavnin <isavnin(a)gmail.com>
Subject: [cooperation-wg] Massive IP blockings in Russia
Date: April 17, 2018 at 1:36:33 PM EDT
To: cooperation-wg(a)ripe.net
Dear colleagues!
I'm not pleased to inform you that RosComNadzor, a Russian Communication
supervisory body, has started blocking huge ranges of IPs belonging
to different cloud infrastructures, mostly Amazon and Google Cloud.
Those ranges include: 13.52.0.0/14, 13.56.0.0/14, 18.184.0.0/15,
18.194.0.0/15, 18.196.0.0/15, 34.192.0.0/10, 34.240.0.0/13,
34.248.0.0/13, 35.156.0.0/14, 35.160.0.0/13, 35.176.0.0/15,
52.0.0.0/11, 52.192.0.0/11, 52.208.0.0/13, 52.28.0.0/15, 52.58.0.0/15,
54.144.0.0/12, 54.160.0.0/12, 54.228.0.0/15, 54.72.0.0/15, 54.88.0.0/16.
Russian ISPs MUST fully block all traffic to such networks. The
list is frequently updated and gets automatically propagated to ISP
every once in a while, failure to block any address may result in
1500eur fine. The infrastructure listed above is being added to
the blocklist under 'counter-terrorist and counter-extremist' order
of the General Prosecutor Office, #27-31-2015/Id4082-15, issued in
2015 and often used for blocking an arbitrary unwanted content.
The real reason for such blocking is an attempt to cut access to
Telegram messenger, which refused to provide end-to-end encryption
keys to the Federal Security Service (previously known as KGB).
This is a case similar to San-Bernardino shooter's, where the FBI
was denied access to the shooter's iPhone, but courts in Russia
have made completely opposite decision. Telegram's infrastructure
is being blocked by a different decision by RosKomNadzor, #2-1779/2018.
Cloud infrastructures are being blocked for massive proxy and VPN
hosting used to dodge messenger blocking.
It is said, that more Apple and Google networks may be blocked soon
for apps updates and push notifications delivery for Telegram.
We hope to still have the global IP connectivity to keep you informed
about how the situation develops. Do not be surprised if some of
your services placed in cloud infrastructures will miss Russian
customers.
You can monitor the number of IP addresses, domains and URLs to be
blocked in Russia at the https://2018.schors.spb.ru/ page (run by
the famous ENOG community member Phil Kulin). Detailed information
(also via API) is available at the https://reestr.rublacklist.net
run by RosKomSvoboda civil society group.
Kind regards,
Alexander Isavnin
Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum
----- End forwarded message -----
