Le 15/02/2016 14:01, Marius Petrescu a écrit :
But if the user near you is not an authorized ham
radio operator, and
if he will use ham radio links, that is illegal.
So, unless you can guarantee that there will be no ham specific
on-the-air activity, it is ok.
You are true :-) But, on a networking point of view, this is not a
"routing" problem. This is a "firewall" problem, which should be
handled
in upper layers.
But usually, since this is a amateur radio network,
there is no reason
why a regular internet user should have direct access to the 44
address space.
In my design, all communications between Internet and hamnet will be
firewalled, of course with very restrictive rules ! Regular users must
not have direct access to ham networks, but anybody should be able to
listen ham QSOs. I see several situations where information should be
accessed both by hams and Internet users. For example, a WEB server
presenting the project and the ham activities, where people could listen
the QSOs on our VHF/UHF networks through a WEB interface, a
reverse-beacon system, etc... This will be handled through a "DMZ". The
Internet users will have "read only" access.
I see several ways of doing that :
1/ A central gateway, with one public (Internet) IP address, and one
44.x address. This gateway would act as a router/firewall/VPN server,
and would handle all trafic between different networks. Access to
servers in DMZ is achieved via NAT.
2/ Publicly available machines (those in DMZ) have dual IP addressing :
one public WAN IP (for accessing from Internet) and one 44.x address
(for accessing from hamnet). Anyway, this makes administration more
complicated. I'm not a fan of dual addresses.
3/ All hamnet machines have 44.x addresses (whether they can be accessed
from Internet or not). They are organized in smaller subnets, or
"zones", and a firewall allows/forbids trafic between zones according to
our general policy
Actually, our test network is built as in 1. But the solution 3 seems
better to me on an engineering point of view. I think it's easier to
manage and to reconfigure. The final setup has not been decided yet, and
will probably be a mix of the three.
Moreover, there are "special" situations that need to be investigated.
For example, one of our sites will host a VHF repeater, that will be
connected to the central VoIP server, through a pure hamnet link. But
this site also hosts a meteo station and a webcam, whose results are not
reserved to ham people, but need to be shared over Internet. And this
site is also used as a contest station, where operators in "assisted
mode" want to be able to access to Internet, and update their Facebook
status during the 48h of the contest :-) What type of addressing should
we use for that site ? 44.x ? Public Internet ? Private 10.x ? The
answer is not as easy as "regular users should not have access to 44.x
address space" ;-)
The ampr gateway actually creates a filter, by
preventing direct
forwarding between ampr subnets and selective IP access, so a regular
internet user can only connect via tunnels to registered hosts (in
this case meaning hosts with an DNS entry).
ampr.org provides those facilities in standard. But, as we want to be
"autonomous", we will provide our own tunnels (IPSEC for site to site
VPNs, OpenVPN for end-users). Then, my idea would be to handle all this
locally, on our central firewall/gateway, so that we can fine-tune the
rules to our needs. That's why routing the whole 44.x subnet via BGP to
our gateway seems interesting to me.
Comments and ideas are welcome.
73 de TK1BI