All,
I have worked on a updated version 2.0 RC3 of the STARTAMPR script. I've
also included more detailed instructions in the STARTAMPR file, as well
as a README. Original versions of the script remain compatible and can
continue to run on AMPRNet devices.
Also, for those wanting to reload the routing table on boot, I've
created a new script called BACKUP_AMPR.
Features of BACKUP_AMPR:
- creates an hourly output of "ip route get table 44" - table44_bak
- creates an hourly executable script to re-add those routes -
restore44sh
New in STARTAMRPR v2.0 RC3:
- DYNAMIC GATEWAY IP SUPPORT, proper configuration of Local Subnets
will end need to exclude your subnet using rip44d -a switch
- Routing tables and rules used to provide default routes and
blackholes independently for each subnet
- SECURITY FIX, packets for destinations not listed in TABLE 44 are
blackholed
- Examples of connecting to Gateways behind 44.0.0.0/s BGPed subnets
The files and README are located here for those on AMPRNet:
http://44.60.44.10/amprnet_docs/start_ampr_version2
73,
- Lynwood
KB3VWG
Hi everyone!
I am trying to use the access to the AMPRNet by VPN via
amprnet-vpn1.aprs.fi
I already got hold of a lotw certificate but cannot get access.
Is this to place to hope for further help?
73 de oe1rsa
--
_________________________________________
_ _ | Roland Schwarz
|_)(_ |
| \__) | mailto:roland.schwarz@blackspace.at
________| http://www.blackspace.at
>>>> Does anyone know if OH7LZB ever documented anywhere how to setup the
>>>> server end of the OpenVPN that validates using the LoTW CA?
>>The server end is stock openvpn, so you may use the openvpn config
>>instructions / documentation to set it up. Nothing fancy, .
I have and have been using a stock openvpn server with my own
generated certificate
authority, server keys. All is fine there.
I tried replacing the certificate authority with the
amprnet-vpn-ca.crt (lotw) file, and all I get is TLS key
handshake/negotiation failed messages when I try and connect. So
there is something I am not understanding on if the server keys have
to be built specific CA to that somehow?
Steve
David,
I like the idea. I remember commenting when the hsmm-mesh/hamnet
firmware first implemented something like that, we needed that on the
amprnet in order to find things on the network. Which will make it
more useful.
At the very least each gateway needs a dashboard or something.
But you are right, it has to be low bandwidth, as we still have a lot
of technological challenges when it comes to radio links and speed.
Short of that you have to nmap the whole address space :-)
Not that long ago I suggested a way to denote the radio link speeds
connecting the gateways to the radio LAN's in the portal.
Closest thing we have presently is an index webserver at:
http://web.oe2xzr.at.ampr.org/
Overall the German Hamnet guys have some good things going
Active hosts:
http://hamnetdb.net/?m=host&as=0
We need to recruit people with good coding skills to help develop
things. I'd be offering to help if I knew more in that department.
---- Quote ----
Back to the original "available services" part of this thread, I've been
thinking about this as well. Maybe the group could consider a services
advertisement protocol like ZeroConf (Avahi in Linux, Bonjour in OSX)
with some modifications to minimize it's chattyness? Things like
stations should not beacon what services they offer more than once an
hour w/o being directly probed, etc.
--David
KI6ZHD
Hey fellow AMPRs!
I have been playing around with devices in my allocated block today, and realized there doesn't seem to be a consolidated place to show where services might be hosted on the AMPRNet... for example a GPS trained NTP server, IRC server, etc... allowing amateur related traffic to stay on the 44/8. Does something like that exist? Is there any reason to not make services like I am describing available to other hams?
Thanks,
Neill
Nevermind, turns out one of the files I was using still had some XML
stuff in it.
So now I have it working with SecurePoint OpenVPN in Windows 7:
http://sourceforge.net/projects/securepoint/
And CentOS 5.5 using openvpn 2.2.2, as well as on as Raspberry Pi,
raspbian, openvpn 2.2.1
Roland, are you attempting to connect using the GUI in Ubuntu 15.04 or
using the command line?
[root@kb9mwr openvpn]# nmap 85.188.1.118 -p 1773
Starting Nmap 5.00 ( http://nmap.org ) at 2015-10-16 12:17 CDT
Interesting ports on amprgw.rats.fi (85.188.1.118):
PORT STATE SERVICE
1773/tcp closed unknown
Nmap done: 1 IP address (1 host up) scanned in 0.52 seconds
Despite this, it works for me:
[root@kb9mwr openvpn]# openvpn client.conf
Fri Oct 16 12:18:07 2015 OpenVPN 2.2.2 i686-redhat-linux-gnu [SSL]
[LZO2] [EPOLL] [PKCS11] [eurephia] built on Apr 5 2012
Fri Oct 16 12:18:07 2015 WARNING: No server certificate verification
method has been enabled. See http://openvpn.net/howto.html#mitm for
more info.
Fri Oct 16 12:18:07 2015 NOTE: OpenVPN 2.1 requires '--script-security
2' or higher to call user-defined scripts or executables
Fri Oct 16 12:18:07 2015 WARNING: file 'client.key' is group or others
accessible
Fri Oct 16 12:18:07 2015 LZO compression initialized
Fri Oct 16 12:18:07 2015 Control Channel MTU parms [ L:1542 D:138
EF:38 EB:0 ET:0 EL:0 ]
Fri Oct 16 12:18:07 2015 Socket Buffers: R=[110592->131072] S=[110592->131072]
Fri Oct 16 12:18:07 2015 Data Channel MTU parms [ L:1542 D:1450 EF:42
EB:135 ET:0 EL:0 AF:3/1 ]
Fri Oct 16 12:18:07 2015 Local Options hash (VER=V4): '41690919'
Fri Oct 16 12:18:07 2015 Expected Remote Options hash (VER=V4): '530fdded'
Fri Oct 16 12:18:07 2015 UDPv4 link local (bound): [undef]:1194
Fri Oct 16 12:18:07 2015 UDPv4 link remote: 85.188.1.118:1773
Fri Oct 16 12:18:07 2015 TLS: Initial packet from 85.188.1.118:1773,
sid=af8cd2e6 8b7e00df
Fri Oct 16 12:18:08 2015 VERIFY OK: depth=1, /O=AMPRnet/CN=OH7LZB_VPN_service_CA
Fri Oct 16 12:18:08 2015 VERIFY OK: depth=0, /CN=ampr-gw.he.fi
Fri Oct 16 12:18:10 2015 Data Channel Encrypt: Cipher 'BF-CBC'
initialized with 128 bit key
Fri Oct 16 12:18:10 2015 Data Channel Encrypt: Using 160 bit message
hash 'SHA1' for HMAC authentication
Fri Oct 16 12:18:10 2015 Data Channel Decrypt: Cipher 'BF-CBC'
initialized with 128 bit key
Fri Oct 16 12:18:10 2015 Data Channel Decrypt: Using 160 bit message
hash 'SHA1' for HMAC authentication
Fri Oct 16 12:18:10 2015 Control Channel: TLSv1, cipher TLSv1/SSLv3
DHE-RSA-AES256-SHA, 2048 bit RSA
Fri Oct 16 12:18:10 2015 [ampr-gw.he.fi] Peer Connection Initiated
with 85.188.1.118:1773
Fri Oct 16 12:18:12 2015 SENT CONTROL [ampr-gw.he.fi]: 'PUSH_REQUEST' (status=1)
Fri Oct 16 12:18:12 2015 PUSH: Received control message:
'PUSH_REPLY,route 44.0.0.0 255.0.0.0,route 44.139.11.0
255.255.255.192,topology net30,ping 24,ping-restart 120,ifconfig
44.139.11.58 44.139.11.57'
Fri Oct 16 12:18:12 2015 OPTIONS IMPORT: timers and/or timeouts modified
Fri Oct 16 12:18:12 2015 OPTIONS IMPORT: --ifconfig/up options modified
Fri Oct 16 12:18:12 2015 OPTIONS IMPORT: route options modified
Fri Oct 16 12:18:12 2015 ROUTE default_gateway=192.168.1.1
Fri Oct 16 12:18:12 2015 TUN/TAP device tun0 opened
Fri Oct 16 12:18:12 2015 TUN/TAP TX queue length set to 100
Fri Oct 16 12:18:12 2015 /sbin/ip link set dev tun0 up mtu 1500
Fri Oct 16 12:18:12 2015 /sbin/ip addr add dev tun0 local 44.139.11.58
peer 44.139.11.57
Fri Oct 16 12:18:12 2015 /sbin/ip route add 44.0.0.0/8 via 44.139.11.57
Fri Oct 16 12:18:12 2015 /sbin/ip route add 44.139.11.0/26 via 44.139.11.57
Fri Oct 16 12:18:12 2015 Initialization Sequence Completed
[root@kb9mwr openvpn]# ifconfig tun0
tun0 Link encap:UNSPEC HWaddr
00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:44.139.11.58 P-t-P:44.139.11.57 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:1 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:48 (48.0 b) TX bytes:0 (0.0 b)
