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