The easiest way would be to put an Echolink system server on a 44.x.y.z
IP...
Anybody working on this?
This will avoid NAT and proxies, but problem with bandwith and latency
staies the same if serveral "44 islands" are connected via tunnels.
You then have to consider the bandwith of the tunnels and the
performance of the peers.
Micha, DD2MIC
Am 30.05.2016 um 10:01 schrieb Rob Janssen:
(Please trim inclusions from previous messages)
_______________________________________________
The basic idea would be that AMPR to AMPR traffic
is a go since it is
tunneled directly.
Public IP to AMPR is a no-go for tunneled networks.
They have a public Gateway IP anyway, so you should use that one for
access
from the internet.
Marius, YO2LOJ
When you use Echolink from within AMPRnet but want to use a public IP
you should
be very careful how to implement it. Some people configure an Echolink
repeater
on an AMPRnet address and then route the traffic to some gateway where
this address
is translated using NAT.
However, this does not work correctly! The Echolink repeater will
register itself
with the Echolink system server which is on public internet, so the
registration
address in the Echolink system is the address of your NAT router.
But internally, the repeater has a 44.x.x.x address so when someone from
a 44.x.x.x
address connects the reply will come from the wrong address and the
connection
does not go through.
This manifests itself when some other systems are natively on AMPRnet
not using NAT.
For example, here in the Netherlands we have several repeaters with a
true AMPRnet
address that is BGP routed, and we also run several Echolink proxies and
relays
on AMPRnet addresses. In neighboring Germany, the NAT method is often
used, where
the repeaters have a 44.x.x.x address but connect to the Echolink server
via NAT.
As a result, no connections between the repeaters in these two areas are
possible,
and worse: people using our Echolink proxies and relays cannot connect
to German
repeaters or users.
It can be solved by not using NAT to translate the Echolink traffic to
public
addresses, but instead run an Echolink proxy on the gateway system which
converts
the internal AMPRnet address of the Echolink repeater to the public
address of
the gateway. Unfortunately only a single proxy can be run per public IP
address,
so a "normal" gateway with a single external address can only host a
single repeater.
To solve this, a number of proxies can be run e.g. in a datacenter where
an IPv4
subnet is available for them (more and more difficult, of course!).
This has now been done in Germany.
The disadvantage of this solution is that all users that are on AMPRnet
still connect
to the outside address. On a BGP routed AMPRnet network where no
proxies or
translations are used, local users can connect the repeater directly.
Rob
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net