> 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 -----
> Thanks for posting this. I didn't know.
The last I heard about that, it would be a block at the end of the address range.... because
it would be easier to route "everything except this". Apparently it was changed again.
(I also didn't know)
Rob
> I actually have some server resources where I was considering hosting a large echolink proxy service for echolink users however I have run into issues getting fiber providers to bring the ip’s in for me to use.. So I am not sure what my next step should be considering returning my ip’s if I can’t seem to follow through.
> By the way I have to use Java for minecraft servers so my 12 core 24 thread should easily handle a bunch of proxy servers.. However if you have some thing that is Linux based and works well I would be all ears to help out the community using the newer code if willing to share..
The proxy/relay server we use can be downloaded from my webserver: http://pe1chl.nl.eu.org/Softw/elproxy.tar.gz
It runs on Linux, and probably on BSD as well after some changing of sockopt names.
We have been using it for a couple of years. There is one small race condition that I still haven't been able to locate, I plan to try to convert it from the use of select() to using poll() and hopefully get rid of that.
But still it runs for months on end, sometimes losing one or two proxies that get stuck in the logon phase.
It requires a system with a number of IP addresses that are routable to internet. They can be AMPRnet or other public space.
Rob
Hi! I have a dual Nic micro atx MB that I use as my main router on my 120/20 MB residential connection.
I was wondering if it would be possible to have a 3rd nic (pcie) that could be use as the apmrnet gateway to hamprnet for my allocation.
I dont want to have my local home net available on 44 net but if I need to hook up my segment to the internet I want it to be available.
I am not bad on linux, but I am not a network engineer. Been playing with wds ap/station captive portal and modding routers. but this is just over my knowledge base.
Anyone willing to help?
Thanks
Pierre
VE2PF
Hi
I have entered new ddns.net name to one of the gateways i have installed and while pressing the save button got "unable to resolve host" error
The name is resolvable ...
Is the Portal lazy ?
Any info is welcome
Ronen - 4Z4ZQ
All,
I wanted to inform you all - that I have successfully compiled and ran
ampr-ripd on a Meraki (Power PC) and MikroTik (Atheros, the binary for
my previous routers worked).
I have included the PPC binary in the 2.3 TAR on my site (along with
x86_64 and Atheros ar71xx). Its only dependency remains: libstdcpp.
73,
- Lynwood
KB3VWG
Cloudflare has announced a new internet-wide DNS resolution
service. There's a good writeup on it at
https://blog.cloudflare.com/dns-resolver-1-1-1-1/
This bit of news isn't much advantage to people on the tunneled
AMPRNet, but the writeup is nonetheless interesting.
- Brian
> Not much details there. I see DNS updates are to be done by the
> coordinators. As they are volunteers, and as they may be very busy, this
> may not be compatible with a quick update required by a growing network
But you can be the volunteer yourself!
> Our plans were to get a subnet large enough for our island, and to
> manage the "internal" subnetting locally.
You have presented your plans before, and here everyone is wary that a network
on a comparatively small and rural territory like Corsica (330.000 inhabitants)
only used by radio amateurs is not likely to be as large as you picture it.
We all know about the difficulty in getting IPv4 space on internet, but using Net-44
space for a Wireless ISP that just happens to have a couple of radio amateurs in
its admin team is not the way to go.
So you will have to present convincing evidence that this is not what is going on.
> I'm wondering about what would be the best solution :
> - Use an independant domain name (ie, "radioamateur.tk")
> - Use a subdomain of ampr.org (ie, "corsica.ampr.org"), with a
> sub-delegation from the parent "ampr.org" domain
> In both solutions, we would have immediate access for local updates, on
> our local DNS servers.
Different networks prefer and use different solutions. Some use an independent
domain, some use sub-delegated subdomains, others are directly under ampr.org.
Each of them of course has advantages and disadvantages and each sees it in a
different way.
On the Dutch network we put our addresses directly under .ampr.org and use the main DNS
servers. For updating, I am using a script that automatically sends the updates
to the server based on a local hosts file I update with newly assigned addresses.
Whenever I run the script, which automatically happens once a day, the diff between
the current and previous version is made and all changes are sent to the robot by
mail, and appear in the global DNS some minutes later.
I also download the zone file and keep it locally for use when the internet connection
fails. Systems using our local resolvers (44.137.0.1 and 44.137.0.2)
still have .ampr.org resolution, for those addresses not sub-delegated.
This way I don't have to worry about providing DNS service on internet (which is a
can of worms...) and still everyone has access to our names. Reverse also works,
which is usually a problem on the independent networks.
Rob
> Tell that to Cisco that uses 1.1.1.1 as part of their default config for the wireless access points.
It appears that Cisco is well aware of the mistake that they made, and the default has been changed to 192.0.2.1
which is a properly reserved address for this.
I see recommendations to change this address dating back to 2010, so by now it should have been changed
by most active admins, and if not it will not really break anything unless users are using hardwired
DNS settings and use the new 1.1.1.1 service.
However, in wireless systems like this, users will likely use DHCP to set their DNS resolvers, and it will
work at least until the admin changes the DNS advertised via DHCP and does not realize that 1.1.1.1 is
already in use in their own system.
I tried reaching the 1.1.1.1 DNS service via 4 different ISPs here in the Netherlands and it works OK on
all of them. Apparently the use of 1.1.1.1 in routers is not too big of an issue.
Rob
