https://wiki.ampr.org/w/api.php?action=feedcontributions&user=Oh7lzb&feedformat=atom44Net Wiki - User contributions [en]2024-03-29T06:46:18ZUser contributionsMediaWiki 1.41.0https://wiki.ampr.org/w/index.php?title=OH7LZB_VPN&diff=872OH7LZB VPN2019-08-18T17:42:50Z<p>Oh7lzb: Update LotW URLs</p>
<hr />
<div>AMPRNet VPN is an experimental method to access the AMPRNet using a VPN from anywhere on the Internet. The VPN is openly available to any amateur radio operators who have successfully applied for an X.509 certificate from one of the following Certificate Authorities:<br />
<br />
* [http://www.arrl.org/logbook-of-the-world ARRL Logbook of the World (LoTW)]<br />
<br />
The Certificate Authority (CA) validates using a relatively strong method that the operator is actually licensed, and gives the operator a cryptographic certificate to prove that. Other services, such as the AMPRNet VPN can then check that the operator possesses a valid amateur radio operator certificate (and the accompanying private key), without any manual work being performed by the operators of those services. The operator can use his private key to sign LoTW log files, or any other information he wishes to communicate, and other parties trusting the CA can use the certificate to check that they have been transmitted by someone who has a private key and a certificate for a callsign from the CA.<br />
<br />
If and when other organisations start to give out X.509 certificates, after sufficient amateur radio license validation, the AMPRNet VPN will be configured to accept those in addition to the LoTW. If you're not willing to obtain a LoTW certificate, please set up a CA for your local club or association, document the method of license validation you're using, and I'll be happy to trust your certificates.<br />
<br />
The VPN operator (Hessu, OH7LZB) does not have time to run a CA and validate licenses manually, so please don't ask for a certificate from anywhere else than the CAs listed above. Thanks!<br />
<br />
The AMPRNet VPN is only used to access the AMPRNet. While you're connected to the AMPRNet VPN, the VPN client will only transmit packets from you to the AMPRNet via the VPN. Packets from you to the rest of the Internet will not go via the VPN - they'll flow out from your local network connection as before. This is called a [http://en.wikipedia.org/wiki/Split_tunneling split tunnel VPN configuration].<br />
<br />
The setup is still a bit complicated - it can be made easier and more automatic with a little additional software in a later phase.<br />
<br />
The AMPRNet VPN is an experimental service. It might be shut down for technical or political reasons - we'll see if it's a feasible idea or not.<br />
<br />
= Getting a certificate from LoTW =<br />
<br />
Go through [https://lotw.arrl.org/lotw-help/getting-started/ these simple steps]. After step 4 you're ready to continue with the AMPRNet VPN.<br />
<br />
It's going to take some time to validate, and you'll have to do some manual work (especially if you're outside the USA), but that is intentional. It significantly reduces abuse of the system, and increases its security.<br />
<br />
= Extracting the certificate from LoTW =<br />
<br />
LoTW uses a custom file format (.TQ*) to exchange certificates, but after the LoTW certificate process is done and the TrustedQSL software has your certificates, they can be easily copied from TrustedQSL's directories. You'll need three files: your '''user certificate''', an '''intermediate certificate''' that was used to sign it, and your '''private key'''. The only secret piece of information is the private key - you should not reveal it to anyone at any point, as they could then use services on your behalf, using your callsign.<br />
<br />
== Windows ==<br />
<br />
* C:\Documents and Settings\your-username\Application Data\TrustedQSL contains two directories, '''certs''' and '''keys'''.<br />
* certs\user contains the '''user certificate'''<br />
* certs\authorities contains an '''intermediate certificate'''<br />
* keys\YOURCALL contains, within some XML, your '''private key'''<br />
<br />
Make copies of those files in another directory, and work on those copies in order to avoid breaking the originals.<br />
<br />
The user and intermediate certificates need to be concatenated to a single file named '''client.crt'''. The user certificate must be first, followed by the intermediate certificate. That can be done by an ascii editor such as Notepad (Wordpad or Word is likely to mess it up in a big way).<br />
<br />
The private key needs to be extracted from the YOURCALL file. The file is a regular ASCII text file, and contains a block which looks something like this (just longer):<br />
<br />
-----BEGIN RSA PRIVATE KEY-----<br />
Proc-Type: 4,ENCRYPTED<br />
DEK-Info: DES-EDE3-CBC,0C7B5495F6A91F31<br />
<br />
0xmWfliK/v9U88MFyYtUbteRoAkfVMK6BllcdID3pZzmdykHaPLZUjXOCUh3vFUX<br />
1bjnYwXpLX/CxgZ6NIxQIk7jMjL3iaP5SkWzCswqi9mCO+zHxuS6PWq7YwbWNFgo<br />
7smNcko1yTp7f/VbS4CZ5kgIF9kCgNaiqdxq+v0IcphQHRR4xjfLpBQ4ckYOi4nC<br />
jqFR1BitwBL4K2JeE9PGUkkUBwvU4oOi9PGChuoxMXs8PwKi/dZTmSWM7kOfMiBw<br />
-----END RSA PRIVATE KEY-----<br />
<br />
Copy-paste that block to a separate file named '''client.key'''.<br />
<br />
== Linux and Mac ==<br />
<br />
* ~/.tqsl/certs/user contains the '''user certificate'''<br />
* ~/.tqsl/certs/authorities contains an '''intermediate certificate'''<br />
* ~/.tqsl/keys/YOURCALL contains, within some XML, your '''private key'''<br />
<br />
The user and intermediate certificates need to be concatenated to a single file named '''client.crt'''. The user certificate must be first, followed by the intermediate certificate. That can be done by a single command:<br />
<br />
cat ~/.tqsl/certs/user ~/.tqsl/certs/authorities > client.crt<br />
<br />
The private key needs to be extracted from the YOURCALL file. The file is a regular ASCII text file, and contains a block which looks something like this (just longer):<br />
<br />
-----BEGIN RSA PRIVATE KEY-----<br />
Proc-Type: 4,ENCRYPTED<br />
DEK-Info: DES-EDE3-CBC,0C7B5495F6A91F31<br />
<br />
0xmWfliK/v9U88MFyYtUbteRoAkfVMK6BllcdID3pZzmdykHaPLZUjXOCUh3vFUX<br />
1bjnYwXpLX/CxgZ6NIxQIk7jMjL3iaP5SkWzCswqi9mCO+zHxuS6PWq7YwbWNFgo<br />
7smNcko1yTp7f/VbS4CZ5kgIF9kCgNaiqdxq+v0IcphQHRR4xjfLpBQ4ckYOi4nC<br />
jqFR1BitwBL4K2JeE9PGUkkUBwvU4oOi9PGChuoxMXs8PwKi/dZTmSWM7kOfMiBw<br />
-----END RSA PRIVATE KEY-----<br />
<br />
Copy-paste that block to a separate file named '''client.key'''. If you're going to open up the original private key file in a text editor, it's a good idea to make a backup copy of that file first in case of an accidental corruption of its contents.<br />
<br />
= Configuring AMPRNet VPN =<br />
<br />
== Windows: OpenVPN ==<br />
<br />
# [http://openvpn.net/index.php/download/community-downloads.html Download the Windows Installer], it's free and open source.<br />
# Run the installer to install it.<br />
# [http://he.fi/amprnet-vpn/amprnet-vpn-win.zip Download the AMPRNet VPN configuration files for Windows]<br />
# Open up the zip file, it contains two files: amprnet-vpn.ovpn and amprnet-vpn-ca.crt.<br />
# In Start menu, under OpenVPN => Shortcuts you'll find an entry named '''OpenVPN configuration file directory'''. Open it, and move the two files from the zip to the configuration file directory. <br />
# Place client.crt and client.key, which were created previously, in the configuration file directory.<br />
# Run the '''OpenVPN GUI''' from the desktop icon or start menu. A new icon will appear in the lower right corner (two computers with red screens + a globe on the side).<br />
# Right-click the OpenVPN toolbar icon and select '''Connect'''.<br />
<br />
If you chose to encrypt your private key with a password (or passphrase) when initially applying for a LoTW certificate and generating the Certificate Request, OpenVPN will ask you for that password when connecting.<br />
<br />
To rephrase: When OpenVPN says "Enter Password", the password being asked is the one you picked when you first applied for a LoTW certificate. It's not something the VPN operator knows (or should know). It's not the one you got on a postcard. Only you have ever been aware of that password (hopefully).<br />
<br />
== Linux: OpenVPN ==<br />
<br />
=== Ubuntu 15.10 ===<br />
<br />
Here is steps to install AMPRNet VPN to Ubuntu 15.10 destop. Install OpenVPN plugin to network manager.<br />
Open terminal and type<br />
<br />
sudo apt-get install network-manager-open vpn-gnome<br />
<br />
Then add VPN-connection information to NetworkManager<br />
<br />
# Click network manager icon on taskbar<br />
# Edit connections<br />
# Add<br />
# OpenVPN<br />
# Create<br />
#* Connection name: AMPRNet<br />
#* Gateway: amprnet-vpn1.aprs.fi<br />
#* Select proper files to User Certificate, CA certificate and Private key<br />
#* Optionally enter private key password if you are set one<br />
# Click Advanced<br />
#* [x] Use custom gateway port: 1773<br />
#* [x] Use LZO data compression<br />
# Click OK<br />
# Click Save<br />
# Click Close<br />
<br />
Now you can connect to VPN <br />
<br />
# Click network manager icon on taskbar<br />
# VPN connections -> AMPRNet<br />
# Connection should be established<br />
<br />
== Linux (Raspberry PI): OpenVPN ==<br />
<br />
Log in to Raspberry Pi console. Install openvpn software.<br />
<br />
sudo apt-get install openvpn<br />
<br />
Create openvpn client configuration file with your favourite editor to /etc/openvpn/client.conf<br />
<br />
<pre><br />
client<br />
dev tun<br />
proto udp<br />
remote amprnet-vpn1.aprs.fi 1773<br />
resolv-retry infinite<br />
persist-key<br />
persist-tun<br />
ca amprnet-vpn-ca.crt<br />
cert client.crt<br />
key client.key<br />
comp-lzo<br />
verb 3<br />
</pre><br />
<br />
Extract your client certificate and key as explained above section Extracting the certificate from LoTW. Copy your certificate files client.crt and client.key to /etc/openvpn/ . You also need amprnet-vpn-ca.crt which can be found inside this archive<br />
http://he.fi/amprnet-vpn/amprnet-vpn-win.zip . Extract it and copy to /etc/openvpn/<br />
<br />
Restart openvpn<br />
<br />
service openvpn restart<br />
<br />
All done.<br />
<br />
== Mac OS X: Tunnelblick ==<br />
<br />
# [http://code.google.com/p/tunnelblick/ Download Tunnelblick], it's free and open source, and works like a charm. It's based on OpenVPN.<br />
# [http://he.fi/amprnet-vpn/amprnet-vpn-tblk.zip Download the AMPRNet VPN configuration for Tunnelblick], it's a zip file containing a directory with a couple files<br />
# Double-click the downloaded zip file to extract it, you'll get a directory named '''amprnet-vpn.tblk'''<br />
# Move the '''private key''' (in a file which was named '''client.key''' in the previous step) to that directory<br />
# Move the certificates (in a file which was named '''client.crt''' in the previous step) to that directory<br />
# Double-click the '''amprnet-vpn.tblk''' directory - this will launch Tunnelblick and install the VPN configuration<br />
<br />
You should now see a "tunnel" icon in the top right corner of the screen. Click it to see a few menu items allowing you to connect and disconnect the VPN.<br />
<br />
If you chose to encrypt your private key with a password (or passphrase) when initially applying for a LoTW certificate and generating the Certificate Request, Tunnelblick will ask you for that passphrase when connecting.<br />
<br />
To rephrase: When Tunnelblick says "A passphrase is required to connect to amprnet-vpn", the passphrase being asked is the one you picked when you first applied for a LoTW certificate. It's not something the VPN operator knows (or should know). Only you have ever been aware of that passphrase (hopefully).</div>Oh7lzbhttps://wiki.ampr.org/w/index.php?title=Gateway&diff=60Gateway2013-05-08T06:47:44Z<p>Oh7lzb: </p>
<hr />
<div>A lot of the 44/8 address space is interconnected via [[gateway|gateways]]. These are IPIP encapsulated [[tunnel|tunnels]] that carry the 44/8 address space allocated to a particular region or end user. There exists a database of all the gateways public IP addresses and the subnets they service on the [[portal]]. This database generates a file called [[encap.txt]] which is basically a routing table that specifies which subnets can be reached via which gateway.<br />
<br />
In order to keep this database up to date, everyone that operates a gateway must register on the [[portal]] and have their gateway assigned to their account.<br />
<br />
As the portal only went live recently, we are in a transition phase, where all the old gateway entries that existed have been copied into the new database and are awaiting their "owners" to claim them. After a suitable period of time has elapsed, about a year, any unclaimed gateways will be removed from the system, thus ensuring that the database is as up to date and as accurate as possible. It is therefore important to register and claim your gateway asap!</div>Oh7lzbhttps://wiki.ampr.org/w/index.php?title=Gateway&diff=59Gateway2013-05-08T06:46:05Z<p>Oh7lzb: </p>
<hr />
<div>A lot of the 44/8 address space is interconnected via [[Gateway|gateways]]. These are IPIP encapsulated [[tunnel|tunnels]] that carry the 44/8 address space allocated to a particular region or end user. There exists a database of all the gateways public IP addresses and the subnets they service on the [[portal]]. This database generates a file called [[encap.txt]] which is basically a routing table that specifies which subnets can be reached via which gateway.<br />
<br />
In order to keep this database up to date, everyone that operates a gateway must register on the [[portal]] and have their gateway assigned to their account.<br />
<br />
As the portal only went live recently, we are in a transition phase, where all the old gateway entries that existed have been copied into the new database and are awaiting their "owners" to claim them. After a suitable period of time has elapsed, about a year, any unclaimed gateways will be removed from the system, thus ensuring that the database is as up to date and as accurate as possible. It is therefore important to register and claim your gateway asap!</div>Oh7lzbhttps://wiki.ampr.org/w/index.php?title=Main_Page&diff=58Main Page2013-05-08T06:11:50Z<p>Oh7lzb: /* Starting points */</p>
<hr />
<div>Welcome to the AMPRNet Wiki.<br />
<br />
If you wish to contribute, please send an email to wiki (at) ampr.org with your preferred username and a login will be created for you.<br />
<br />
If you are looking to get an IP allocation within the 44/8 AMPRNet please read the [[Portal]] page.<br />
<br />
If you operate a [[gateway]] please ensure you have registered on the [[portal]] and "claimed" your [[gateway]].<br />
<br />
Thanks!<br />
<br />
== Starting points ==<br />
<br />
* Basic information about the [[AMPRNet]] and the [[ampr.org]] domain<br />
* Instructions for [[setting up a gateway on Linux]]<br />
<br />
== Logo competition ==<br />
<br />
We are currently looking for suggestions for a unified logo to use on this Wiki and across the other websites we operate:<br />
<br />
* http://www.ampr.org<br />
* https://portal.ampr.org<br />
<br />
If you have any suggestions, please email them to wiki (at) ampr.org.</div>Oh7lzbhttps://wiki.ampr.org/w/index.php?title=Gateway&diff=56Gateway2013-05-08T06:07:50Z<p>Oh7lzb: </p>
<hr />
<div>A lot of the 44/8 address space is interconnected via gateways. These are IPIP encapsulated [[tunnel|tunnels]] that carry the 44/8 address space allocated to a particular region or end user. There exists a database of all the gateways public IP addresses and the subnets they service on the [[portal]]. This database generates a file called [[encap.txt]] which is basically a routing table that specifies which subnets can be reached via which gateway.<br />
<br />
In order to keep this database up to date, everyone that operates a gateway must register on the [[portal]] and have their gateway assigned to their account.<br />
<br />
As the portal only went live recently, we are in a transition phase, where all the old gateway entries that existed have been copied into the new database and are awaiting their "owners" to claim them. After a suitable period of time has elapsed, about a year, any unclaimed gateways will be removed from the system, thus ensuring that the database is as up to date and as accurate as possible. It is therefore important to register and claim your gateway asap!</div>Oh7lzbhttps://wiki.ampr.org/w/index.php?title=Gateway&diff=55Gateway2013-05-08T06:07:07Z<p>Oh7lzb: </p>
<hr />
<div>A lot of the 44/8 address space is interconnected via gateways. These are IPIP encapsulated [[tunnel|tunnels]] that carry the 44/8 address space allocated to a particular region or end user. There exists a database of all the gateways public IP addresses and the subnets they service on the [[portal]]. This database generates a file called encap.txt which is basically a routing table that specifies which subnets can be reached via which gateway.<br />
<br />
In order to keep this database up to date, everyone that operates a gateway must register on the [[portal]] and have their gateway assigned to their account.<br />
<br />
As the portal only went live recently, we are in a transition phase, where all the old gateway entries that existed have been copied into the new database and are awaiting their "owners" to claim them. After a suitable period of time has elapsed, about a year, any unclaimed gateways will be removed from the system, thus ensuring that the database is as up to date and as accurate as possible. It is therefore important to register and claim your gateway asap!</div>Oh7lzbhttps://wiki.ampr.org/w/index.php?title=Main_Page&diff=53Main Page2013-05-08T05:57:12Z<p>Oh7lzb: </p>
<hr />
<div>Welcome to the AMPRNet Wiki.<br />
<br />
If you wish to contribute, please send an email to wiki (at) ampr.org with your preferred username and a login will be created for you.<br />
<br />
If you are looking to get an IP allocation within the 44/8 AMPRNet please read the [[Portal]] page.<br />
<br />
If you operate a [[gateway]] please ensure you have registered on the [[portal]] and "claimed" your [[gateway]].<br />
<br />
Thanks!<br />
<br />
== Starting points ==<br />
<br />
* Basic information about the [[AMPRNet]] and the [[ampr.org]] domain<br />
* Instructions for [[setting up a gateway]]<br />
<br />
== Logo competition ==<br />
<br />
We are currently looking for suggestions for a unified logo to use on this Wiki and across the other websites we operate:<br />
<br />
* http://www.ampr.org<br />
* https://portal.ampr.org<br />
<br />
If you have any suggestions, please email them to wiki (at) ampr.org.</div>Oh7lzbhttps://wiki.ampr.org/w/index.php?title=Setting_up_a_gateway_on_Linux&diff=52Setting up a gateway on Linux2013-05-08T05:54:13Z<p>Oh7lzb: /* Native Linux kernel AX.25 and IPIP tunneling */</p>
<hr />
<div>There are a few different ways to run an AMPRnet gateway on a Linux system. Each has some benefits, so you'll need to pick your favourite.<br />
<br />
Before configuring the Linux gateway you'll need to follow the [[setting up a gateway|common instructions for setting up a gateway]]: Obtain your AMPRnet 44/8 IP addresses from a regional coordinator, obtain a public static IP address for your gateway, insert your gateway in the Gateways database using the [[Portal]] and get some of your 44.* IP addresses registered in the [[ampr.org]] DNS.<br />
<br />
= Flavours of Linux gateways =<br />
<br />
== Native Linux kernel AX.25 and IPIP tunneling ==<br />
<br />
Linux contains the necessary building blocks for a gateway without much added software. Radio interfaces are configured much like any other network interfaces such as Ethernet, they're just given amateur radio callsigns in addition to an IP address (callsign will act the role of the Ethernet MAC address). If you're familiar with Linux configuration but have not heard of NOS, or if you wish to go with minimal amount of moving parts, this would probably be your choice.<br />
<br />
Setting up a native Linux gateway consists of two main steps:<br />
<br />
'''Setting up tunnel routing to the rest of the AMPRnet'''<br />
<br />
* [[rip44d]] is a new method, using RIPv2 to automatically set up routes<br />
* Downloading the [[encap.txt]] file using FTP and setting up routes using a [[munge script]] is the traditional method<br />
<br />
'''Setting up radio interfaces in Linux'''<br />
<br />
* Linux AX.25 set-up<br />
* 802.11 WiFi on amateur frequencies (2.4 or 5 GHz) is a new popular way to set up fast links<br />
<br />
== Running JNOS (or other NOS) on top of Linux ==<br />
<br />
If you're already familiar with running NOS on top of DOS or Linux, or wish to keep the AMPRnet IP packet routing away from the host Linux system, it might make sense to run JNOS as an application on top of Linux.<br />
<br />
The downside is that it'll have a slightly higher overhead (consumed memory and CPU), and you'll have two IP routers running on top of each other instead of just one, which is seen as slightly complicated by some.<br />
<br />
The upside is that you'll also get the JNOS BBS-type features, and some other traditional services without installing additional software on top.<br />
<br />
John Martin KF8KK has written a [http://kf8kk.com/packet/jnos-linux/linux-jnos-setup-1.htm Linux - Jnos Setup and Configuration HOW-TO].</div>Oh7lzbhttps://wiki.ampr.org/w/index.php?title=Setting_up_a_gateway_on_Linux&diff=51Setting up a gateway on Linux2013-05-08T05:50:49Z<p>Oh7lzb: /* Native Linux kernel AX.25 and IPIP tunneling */</p>
<hr />
<div>There are a few different ways to run an AMPRnet gateway on a Linux system. Each has some benefits, so you'll need to pick your favourite.<br />
<br />
Before configuring the Linux gateway you'll need to follow the [[setting up a gateway|common instructions for setting up a gateway]]: Obtain your AMPRnet 44/8 IP addresses from a regional coordinator, obtain a public static IP address for your gateway, insert your gateway in the Gateways database using the [[Portal]] and get some of your 44.* IP addresses registered in the [[ampr.org]] DNS.<br />
<br />
= Flavours of Linux gateways =<br />
<br />
== Native Linux kernel AX.25 and IPIP tunneling ==<br />
<br />
Linux contains the necessary building blocks for a gateway without much added software. Radio interfaces are configured much like any other network interfaces such as Ethernet, they're just given amateur radio callsigns in addition to an IP address (callsign will act the role of the Ethernet MAC address). If you're familiar with Linux configuration but have not heard of NOS, or if you wish to go with minimal amount of moving parts, this would probably be your choice.<br />
<br />
Setting up a native Linux gateway consists of two main steps:<br />
<br />
'''Setting up tunnel routing to the rest of the AMPRnet'''<br />
<br />
* [[rip44d]] is a new method, using RIPv2 to automatically set up routes<br />
* Downloading the [[encap]].txt file using FTP and setting up routes using a [[munge script]] is the traditional method<br />
<br />
'''Setting up radio interfaces in Linux'''<br />
<br />
* Linux AX.25 set-up<br />
* 802.11 WiFi on amateur frequencies (2.4 or 5 GHz) is a new popular way to set up fast links<br />
<br />
== Running JNOS (or other NOS) on top of Linux ==<br />
<br />
If you're already familiar with running NOS on top of DOS or Linux, or wish to keep the AMPRnet IP packet routing away from the host Linux system, it might make sense to run JNOS as an application on top of Linux.<br />
<br />
The downside is that it'll have a slightly higher overhead (consumed memory and CPU), and you'll have two IP routers running on top of each other instead of just one, which is seen as slightly complicated by some.<br />
<br />
The upside is that you'll also get the JNOS BBS-type features, and some other traditional services without installing additional software on top.<br />
<br />
John Martin KF8KK has written a [http://kf8kk.com/packet/jnos-linux/linux-jnos-setup-1.htm Linux - Jnos Setup and Configuration HOW-TO].</div>Oh7lzbhttps://wiki.ampr.org/w/index.php?title=Setting_up_a_gateway_on_Linux&diff=50Setting up a gateway on Linux2013-05-08T05:49:33Z<p>Oh7lzb: /* Native Linux kernel AX.25 and IPIP tunneling */</p>
<hr />
<div>There are a few different ways to run an AMPRnet gateway on a Linux system. Each has some benefits, so you'll need to pick your favourite.<br />
<br />
Before configuring the Linux gateway you'll need to follow the [[setting up a gateway|common instructions for setting up a gateway]]: Obtain your AMPRnet 44/8 IP addresses from a regional coordinator, obtain a public static IP address for your gateway, insert your gateway in the Gateways database using the [[Portal]] and get some of your 44.* IP addresses registered in the [[ampr.org]] DNS.<br />
<br />
= Flavours of Linux gateways =<br />
<br />
== Native Linux kernel AX.25 and IPIP tunneling ==<br />
<br />
Linux contains the necessary building blocks for a gateway without much added software. Radio interfaces are configured much like any other network interfaces such as Ethernet, they're just given amateur radio callsigns in addition to an IP address (callsign will act the role of the Ethernet MAC address). If you're familiar with Linux configuration but have not heard of NOS, or if you wish to go with minimal amount of moving parts, this would probably be your choice.<br />
<br />
Setting up a native Linux gateway consists of two main steps:<br />
<br />
'''Setting up tunnel routing to the rest of the AMPRnet'''<br />
<br />
* [[rip44d]] is a new method, using RIPv2 to automatically set up routes<br />
* Downloading the [[encap]].txt file using FTP and setting up routes using a [[munge script]] is the traditional method<br />
<br />
'''Setting up radio interfaces in Linux'''<br />
<br />
* Linux AX.25 set-up<br />
* 802.11 WiFi on amateur frequencies (2.4 or 5 GHz) is a new popular way to set up fast links</div>Oh7lzbhttps://wiki.ampr.org/w/index.php?title=Setting_up_a_gateway_on_Linux&diff=49Setting up a gateway on Linux2013-05-08T05:48:36Z<p>Oh7lzb: Created page with "There are a few different ways to run an AMPRnet gateway on a Linux system. Each has some benefits, so you'll need to pick your favourite. Before configuring the Linux gatewa..."</p>
<hr />
<div>There are a few different ways to run an AMPRnet gateway on a Linux system. Each has some benefits, so you'll need to pick your favourite.<br />
<br />
Before configuring the Linux gateway you'll need to follow the [[setting up a gateway|common instructions for setting up a gateway]]: Obtain your AMPRnet 44/8 IP addresses from a regional coordinator, obtain a public static IP address for your gateway, insert your gateway in the Gateways database using the [[Portal]] and get some of your 44.* IP addresses registered in the [[ampr.org]] DNS.<br />
<br />
= Flavours of Linux gateways =<br />
<br />
== Native Linux kernel AX.25 and IPIP tunneling ==<br />
<br />
Linux contains the necessary building blocks for a gateway without much added software. Radio interfaces are configured much like any other network interfaces such as Ethernet, they're just given amateur radio callsigns in addition to an IP address (callsign will act the role of the Ethernet MAC address). If you're familiar with Linux configuration but have not heard of NOS, or if you wish to go with minimal amount of moving parts, this would probably be your choice.<br />
<br />
Setting up a native Linux gateway consists of two main steps:<br />
<br />
'''Setting up tunnel routing to the rest of the AMPRnet'''<br />
<br />
* [[rip44d]] is a new method, using RIPv2 to automatically set up routes<br />
* Downloading the [[encap]].txt file using FTP and setting up routes using a munge script is the traditional method<br />
<br />
'''Setting up radio interfaces in Linux'''<br />
<br />
* Linux AX.25 set-up<br />
* 802.11 WiFi on amateur frequencies (2.4 or 5 GHz) is a new popular way to set up fast links</div>Oh7lzbhttps://wiki.ampr.org/w/index.php?title=Ampr.org&diff=48Ampr.org2013-05-08T05:42:54Z<p>Oh7lzb: Created page with "AMPR.ORG is the domain that is available for ham radio operators to register their AMPRNet hosts, and for other ham radio related computer systems. Domain names in AMPR.O..."</p>
<hr />
<div>AMPR.ORG is the domain that is available for ham radio operators to register their [[AMPRNet]] hosts, and for other ham radio related computer systems.<br />
<br />
Domain names in AMPR.ORG are available to any licensed amateur radio operator who is interested in advancing the art of ham radio digital communications. In most countries, there is a local coordinator who is responsible for assigning an address and updating the master hosts list. There is no formal organization, no membership requirements, and no dues. All of the work is done by volunteers as they have time to do it.<br />
<br />
If you are a ham who needs an address, contact your local coordinator. AMPR.ORG is not intended to be, and should not be used as, a substitute for buying a personal domain name. It's really there for ham radio use.<br />
<br />
= Updating the ampr.org DNS zone =<br />
<br />
... TODO: write up on how to formulate a good update request to the local coordinator.<br />
<br />
Contact your local coordinator to request an update of the zone. A list of coordinators can be found on the [[Portal]]:<br />
<br />
* [https://portal.ampr.org/networks.php https://portal.ampr.org/networks.php]</div>Oh7lzbhttps://wiki.ampr.org/w/index.php?title=Portal&diff=47Portal2013-05-08T05:32:06Z<p>Oh7lzb: </p>
<hr />
<div>We have developed a Portal that allows users of the 44/8 address space to manage their allocations, configure gateway information and manage their entries in the ampr.org domain. The portal can be found here:<br />
<br />
[https://portal.ampr.org https://portal.ampr.org]<br />
<br />
At the time of writing the [[gateway]] portion of the portal is up and running, if you operate a [[gateway]], please ensure that you register with the portal so that you can manage your [[gateway]] entry and have it included in the encap and [[rip44d]] updates.<br />
<br />
We have just completed the IP address allocation part of the portal: if you have an existing address allocation from within 44/8 please register on the portal and let us know about it, so it can be officially allocated to you.<br />
<br />
If you are looking to get an IP allocation within 44/8 please register on the portal and place your request.<br />
<br />
<br />
The main problem we faced with the old setup was how to ensure the data we have is accurate and up to date.<br />
<br />
The new portal is our answer to that problem: folks register and are allocated an IP or subnet of IP's that they are responsible for. The system doesn't then just let them get on with it - the system is designed to actively ensure that each allocation is still being used, the person must login to the portal on a regular basis, or if they do not, an email will be sent automatically to them asking them to confirm their continued use of the IP(s). If no response is received from the emailed request, two further attempts are made to contact the person, after which the system places their allocation in a de-activated state. The person is able to login and re-activate the allocation for a certain time after de-activation, beyond that time period the allocation will be deleted from the database - thus keeping it all as up to date as is possible.<br />
<br />
Some manual intervention is encouraged, for example the second, and all subsequent reminder emails and de-activation emails are cc'd to the co-ordinator responsible for the next higher subnet, so they could attempt a more manual approach to remind the person to login - this is to be encouraged as sometimes emails (especially automated ones) can be blocked in spam folders, people change their email address and forget to update the portal, etc.</div>Oh7lzbhttps://wiki.ampr.org/w/index.php?title=Portal&diff=46Portal2013-05-08T05:31:43Z<p>Oh7lzb: </p>
<hr />
<div>We have developed a Portal that allows users of the 44/8 address space to manage their allocations, configure gateway information and manage their entries in the ampr.org domain. The portal can be found here:<br />
<br />
[https://portal.ampr.org https://portal.ampr.org]<br />
<br />
At the time of writing the [[gateway]] portion of the portal is up and running, if you operate a [[gateway]], please ensure that you register with the portal so that you can manage your [[gateway]] entry and have it included in the encap and [[Rip44d]] updates.<br />
<br />
We have just completed the IP address allocation part of the portal: if you have an existing address allocation from within 44/8 please register on the portal and let us know about it, so it can be officially allocated to you.<br />
<br />
If you are looking to get an IP allocation within 44/8 please register on the portal and place your request.<br />
<br />
<br />
The main problem we faced with the old setup was how to ensure the data we have is accurate and up to date.<br />
<br />
The new portal is our answer to that problem: folks register and are allocated an IP or subnet of IP's that they are responsible for. The system doesn't then just let them get on with it - the system is designed to actively ensure that each allocation is still being used, the person must login to the portal on a regular basis, or if they do not, an email will be sent automatically to them asking them to confirm their continued use of the IP(s). If no response is received from the emailed request, two further attempts are made to contact the person, after which the system places their allocation in a de-activated state. The person is able to login and re-activate the allocation for a certain time after de-activation, beyond that time period the allocation will be deleted from the database - thus keeping it all as up to date as is possible.<br />
<br />
Some manual intervention is encouraged, for example the second, and all subsequent reminder emails and de-activation emails are cc'd to the co-ordinator responsible for the next higher subnet, so they could attempt a more manual approach to remind the person to login - this is to be encouraged as sometimes emails (especially automated ones) can be blocked in spam folders, people change their email address and forget to update the portal, etc.</div>Oh7lzbhttps://wiki.ampr.org/w/index.php?title=44Net_mailing_list&diff=4544Net mailing list2013-05-08T05:29:14Z<p>Oh7lzb: </p>
<hr />
<div>The [http://hamradio.ucsd.edu/mailman/listinfo/44net AMPRNet working group discussion list] is a mailing list where amprnet users and gateway operators discuss all things [[AMPRNet]]. Subscribe and browse the archives to learn more!<br />
<br />
* [http://hamradio.ucsd.edu/mailman/listinfo/44net http://hamradio.ucsd.edu/mailman/listinfo/44net]</div>Oh7lzbhttps://wiki.ampr.org/w/index.php?title=44Net_mailing_list&diff=4444Net mailing list2013-05-08T05:28:32Z<p>Oh7lzb: Created page with "The [http://hamradio.ucsd.edu/mailman/listinfo/44net AMPRNet working group discussion list] is a mailing list where amprnet users and gateway operators discuss all things AMPR..."</p>
<hr />
<div>The [http://hamradio.ucsd.edu/mailman/listinfo/44net AMPRNet working group discussion list] is a mailing list where amprnet users and gateway operators discuss all things AMPRNet. Subscribe and browse the archives to learn more!<br />
<br />
* [http://hamradio.ucsd.edu/mailman/listinfo/44net http://hamradio.ucsd.edu/mailman/listinfo/44net]</div>Oh7lzbhttps://wiki.ampr.org/w/index.php?title=Rip44d&diff=43Rip44d2013-05-08T05:23:42Z<p>Oh7lzb: </p>
<hr />
<div>Technically, rip44d is a custom RIPv2 daemon which receives periodic routing table updates from the [[AMPRNet]] routing service ([[Amprgw]]), and inserts them in the Linux routing table.<br />
<br />
RIP ([http://en.wikipedia.org/wiki/Routing_Information_Protocol Routing Information Protocol]) is a method to dynamically update IP routing tables. In practice, on the [[AMPRNet]] [[Gateway]], it removes the requirement to periodically download the tunnel routing table ([[encap.txt]]) using FTP and apply it to the routing table. It transmits changes quicker and should be simpler to set up. Amprgw transmits the RIP routing table updates every 5 minutes, while the encap.txt has traditionally been only updated once per day. Some operators have even done the downloads manually (and not very often).<br />
<br />
The RIP protocol is used in a slightly unconventional way on the AMPRNet, and the standard IP routing daemons such as zebra/quagga are not able to process these packets. Until those daemons are modified to support Amprnet routing updates, a custom implementation such as rip44d can be used.<br />
<br />
rip44d is written in the Perl programming language. C might be the conventionally right language to implement daemons such as this, but the author happened to have a good bunch of perl code that could be easily reused in the implementation of rip44d. The routing table is relatively small, so the performance or memory consumption of this daemon isn't very critical.<br />
<br />
= Requirements =<br />
<br />
# You'll need a Linux computer, which has been added in the Gateways file using the [[Portal]], so that it is know as an AMPRnet gateway and will receive RIP updates from the [[Amprgw]]. It will take some time before Amprgw will learn about new gateways.<br />
# If you have been running the gateway before, and you have already set up a cron job to automatically update the routing table by downloading encap.txt, you need to disable that cron job so that there's only one updating method running at a time.<br />
# The instructions below are currently only for Debian/Ubuntu, but there's nothing Debian-specific in rip44d - it should work fine on other distributions. It does not read or touch any of the operating system's configuration files.<br />
<br />
= Installation of dependencies on Debian/Ubuntu =<br />
<br />
install perl, and IO::Socket::Multicast, a Perl module used for receiving the RIP multicast packets<br />
<br />
sudo apt-get install perl libio-socket-multicast-perl<br />
<br />
install something to download the daemon, if needed<br />
<br />
sudo apt-get install curl<br />
<br />
= Installation of dependencies on other distributions =<br />
<br />
Other distributions should have an easy way to install the required packages too (using yum or a similar program). Please fill in details here, if you know them.<br />
<br />
If all else fails, but you have Perl installed already, you can use CPAN to install the module. For details, please see the [http://www.cpan.org/modules/INSTALL.html CPAN installation guide].<br />
<br />
cpan App::cpanminus<br />
cpanm IO::Socket::Multicast<br />
<br />
= Installation of rip44d =<br />
<br />
Download the daemon<br />
<br />
curl -O https://raw.github.com/hessu/rip44d/master/rip44d<br />
<br />
Make it executable<br />
<br />
chmod u+x rip44d<br />
<br />
= Run it for the first time =<br />
<br />
Run it first with the -v option to verify that it sees the route announcements from amprgw, and to learn the plaintext password used to authenticate the RIP packets (it's not included in the script, and I'm not posting it here, so that spoofing can only be done by those who are already receiving the announcements). Wait up to 5 minutes until the routes are transmitted, and it'll complain about the password it's not expecting:<br />
<br />
hessu@gateway:~$ sudo ./rip44d -v<br />
found local address: 1.2.3.4<br />
found local address: 127.0.0.1<br />
found local address: 44.255.259.253<br />
opening UDP socket...<br />
entering main loop, waiting for RIPv2 datagrams<br />
received from 44.0.0.1: 520: 504 bytes<br />
RIPv2 packet contains password PasswordFoundHere but we require none<br />
<br />
Run it again with the correct password<br />
<br />
hessu@gateway:~$ sudo ./rip44d -p PasswordGoesHere<br />
<br />
Within 5 minutes it should receive the new routing table and take it into use. For added fun, use -v (verbose) or -d (debug, really verbose) to see what it does.<br />
<br />
After confirming that it works, move it to /usr/local/sbin (or something) and put it in your boot scripts (sorry, no sysv init script provided yet). At minimum, the following lines in /etc/rc.local should do the required tricks to bring Amprnet routing up. The IP addresses are intentionally invalid – you'll need to replace them with your own.<br />
<br />
# Route my own subnet to blackhole, just to make sure I don't accidentally<br />
# transmit packets destined for us back out to Amprgw and create a loop.<br />
# More specific routes will route packets for these addresses out on the<br />
# correct radio interfaces.<br />
/sbin/ip route add blackhole 44.255.259.0/24<br />
# Bring up the tunnel interface and assign an IP address to it.<br />
/sbin/ifconfig tunl0 44.255.259.253 up || exit 2<br />
# Start up the RIP routing daemon to learn the routing table.<br />
/usr/local/sbin/rip44d -p PasswordGoesHere < /dev/null &<br />
<br />
That should be all. Really. The downside of this configuration is that it will take up to 5 minutes for the gateway to receive a routing update and become operational after a reboot. The daemon should really be improved to store the current routing table in a local file and load it from there when starting up.<br />
<br />
The above route add command will cause packets destined to 44.255.259.* to be dropped on the floor, unless a more specific route (such as 44.255.259.0/25) exists. If you route the whole /24 subnet to your radio interface, the blackhole route should not be used. If you have smaller subnets or per-host routes for each user host, the blackhole route will prevent packets destined to unused addresses from getting into a loop between your gateway and the Amprgw.<br />
<br />
= Notes =<br />
<br />
* rip44d automatically ignores announced routes which are pointed to the system's local addresses. The addresses are automatically learned using /sbin/ifconfig, but you can add more gateway addresses using -a (comma-separated list of IP addresses).<br />
* It expects that your tunnels are configured on tunl0. Use the -i <if> option to change to another. The tunnel interface must be up and configured before rip44d starts up.<br />
* Old encap routes may be present, the daemon will overwrite them as necessary (it won't touch more specific routes, or ones which are not found in the route advertisements). You don't need to "clean" the routing table before running rip44d if you have populated it from encap.txt.<br />
<br />
= Support, bug reports and improvements =<br />
<br />
If you have questions to ask about the usage of this daemon, please contact the [[44Net mailing list]].<br />
<br />
If you have improved the daemon and wish to submit a patch, please use Github. Create an account, fork the rip44d repository to your own private repository, push your changes there, and submit a merge request. I'll then merge the changes in the master source tree and release a new version. Thank you!<br />
<br />
Github repository: [https://github.com/hessu/rip44d https://github.com/hessu/rip44d]<br />
<br />
The daemon was written by Heikki Hannikainen, OH7LZB.<br />
<br />
= Links =<br />
<br />
* [http://www.qsl.net/kb9mwr/wapr/tcpip/rip44d.html Alternative installation instructions by KB9MWR]</div>Oh7lzbhttps://wiki.ampr.org/w/index.php?title=Rip44d&diff=42Rip44d2013-05-08T05:21:01Z<p>Oh7lzb: /* Installation of rip44d */</p>
<hr />
<div>Technically, rip44d is a custom RIPv2 daemon which receives periodic routing table updates from the [[AMPRNet]] routing service ([[Amprgw]]), and inserts them in the Linux routing table.<br />
<br />
RIP ([http://en.wikipedia.org/wiki/Routing_Information_Protocol Routing Information Protocol]) is a method to dynamically update IP routing tables. In practice, on the [[AMPRNet]] gateways, it removes the requirement to periodically download the tunnel routing table ([[encap.txt]]) using FTP and apply it to the routing table. It transmits changes quicker and should be simpler to set up. Amprgw transmits the RIP routing table updates every 5 minutes, while the encap.txt has traditionally been only updated once per day. Some operators have even done the downloads manually (and not very often).<br />
<br />
The RIP protocol is used in a slightly unconventional way on the Amprnet, and the standard IP routing daemons such as zebra/quagga are not able to process these packets. Until those daemons are modified to support Amprnet routing updates, a custom implementation such as rip44d can be used.<br />
<br />
rip44d is written in the Perl programming language. C might be the conventionally right language to implement daemons such as this, but the author happened to have a good bunch of perl code that could be easily reused in the implementation of rip44d. The routing table is relatively small, so the performance or memory consumption of this daemon isn't very critical.<br />
<br />
= Requirements =<br />
<br />
# You'll need a Linux computer, which has been added in the Gateways file using the [[Portal]], so that it is know as an AMPRnet gateway and will receive RIP updates from the [[Amprgw]]. It will take some time before Amprgw will learn about new gateways.<br />
# If you have been running the gateway before, and you have already set up a cron job to automatically update the routing table by downloading encap.txt, you need to disable that cron job so that there's only one updating method running at a time.<br />
# The instructions below are currently only for Debian/Ubuntu, but there's nothing Debian-specific in rip44d - it should work fine on other distributions. It does not read or touch any of the operating system's configuration files.<br />
<br />
= Installation of dependencies on Debian/Ubuntu =<br />
<br />
install perl, and IO::Socket::Multicast, a Perl module used for receiving the RIP multicast packets<br />
<br />
sudo apt-get install perl libio-socket-multicast-perl<br />
<br />
install something to download the daemon, if needed<br />
<br />
sudo apt-get install curl<br />
<br />
= Installation of dependencies on other distributions =<br />
<br />
Other distributions should have an easy way to install the required packages too (using yum or a similar program). Please fill in details here, if you know them.<br />
<br />
If all else fails, but you have Perl installed already, you can use CPAN to install the module. For details, please see the [http://www.cpan.org/modules/INSTALL.html CPAN installation guide].<br />
<br />
cpan App::cpanminus<br />
cpanm IO::Socket::Multicast<br />
<br />
= Installation of rip44d =<br />
<br />
Download the daemon<br />
<br />
curl -O https://raw.github.com/hessu/rip44d/master/rip44d<br />
<br />
Make it executable<br />
<br />
chmod u+x rip44d<br />
<br />
= Run it for the first time =<br />
<br />
Run it first with the -v option to verify that it sees the route announcements from amprgw, and to learn the plaintext password used to authenticate the RIP packets (it's not included in the script, and I'm not posting it here, so that spoofing can only be done by those who are already receiving the announcements). Wait up to 5 minutes until the routes are transmitted, and it'll complain about the password it's not expecting:<br />
<br />
hessu@gateway:~$ sudo ./rip44d -v<br />
found local address: 1.2.3.4<br />
found local address: 127.0.0.1<br />
found local address: 44.255.259.253<br />
opening UDP socket...<br />
entering main loop, waiting for RIPv2 datagrams<br />
received from 44.0.0.1: 520: 504 bytes<br />
RIPv2 packet contains password PasswordFoundHere but we require none<br />
<br />
Run it again with the correct password<br />
<br />
hessu@gateway:~$ sudo ./rip44d -p PasswordGoesHere<br />
<br />
Within 5 minutes it should receive the new routing table and take it into use. For added fun, use -v (verbose) or -d (debug, really verbose) to see what it does.<br />
<br />
After confirming that it works, move it to /usr/local/sbin (or something) and put it in your boot scripts (sorry, no sysv init script provided yet). At minimum, the following lines in /etc/rc.local should do the required tricks to bring Amprnet routing up. The IP addresses are intentionally invalid – you'll need to replace them with your own.<br />
<br />
# Route my own subnet to blackhole, just to make sure I don't accidentally<br />
# transmit packets destined for us back out to Amprgw and create a loop.<br />
# More specific routes will route packets for these addresses out on the<br />
# correct radio interfaces.<br />
/sbin/ip route add blackhole 44.255.259.0/24<br />
# Bring up the tunnel interface and assign an IP address to it.<br />
/sbin/ifconfig tunl0 44.255.259.253 up || exit 2<br />
# Start up the RIP routing daemon to learn the routing table.<br />
/usr/local/sbin/rip44d -p PasswordGoesHere < /dev/null &<br />
<br />
That should be all. Really. The downside of this configuration is that it will take up to 5 minutes for the gateway to receive a routing update and become operational after a reboot. The daemon should really be improved to store the current routing table in a local file and load it from there when starting up.<br />
<br />
The above route add command will cause packets destined to 44.255.259.* to be dropped on the floor, unless a more specific route (such as 44.255.259.0/25) exists. If you route the whole /24 subnet to your radio interface, the blackhole route should not be used. If you have smaller subnets or per-host routes for each user host, the blackhole route will prevent packets destined to unused addresses from getting into a loop between your gateway and the Amprgw.<br />
<br />
= Notes =<br />
<br />
* rip44d automatically ignores announced routes which are pointed to the system's local addresses. The addresses are automatically learned using /sbin/ifconfig, but you can add more gateway addresses using -a (comma-separated list of IP addresses).<br />
* It expects that your tunnels are configured on tunl0. Use the -i <if> option to change to another. The tunnel interface must be up and configured before rip44d starts up.<br />
* Old encap routes may be present, the daemon will overwrite them as necessary (it won't touch more specific routes, or ones which are not found in the route advertisements). You don't need to "clean" the routing table before running rip44d if you have populated it from encap.txt.<br />
<br />
= Support, bug reports and improvements =<br />
<br />
If you have questions to ask about the usage of this daemon, please contact the [[44Net mailing list]].<br />
<br />
If you have improved the daemon and wish to submit a patch, please use Github. Create an account, fork the rip44d repository to your own private repository, push your changes there, and submit a merge request. I'll then merge the changes in the master source tree and release a new version. Thank you!<br />
<br />
Github repository: [https://github.com/hessu/rip44d https://github.com/hessu/rip44d]<br />
<br />
The daemon was written by Heikki Hannikainen, OH7LZB.<br />
<br />
= Links =<br />
<br />
* [http://www.qsl.net/kb9mwr/wapr/tcpip/rip44d.html Alternative installation instructions by KB9MWR]</div>Oh7lzbhttps://wiki.ampr.org/w/index.php?title=Rip44d&diff=41Rip44d2013-05-08T05:20:03Z<p>Oh7lzb: /* Notes */</p>
<hr />
<div>Technically, rip44d is a custom RIPv2 daemon which receives periodic routing table updates from the [[AMPRNet]] routing service ([[Amprgw]]), and inserts them in the Linux routing table.<br />
<br />
RIP ([http://en.wikipedia.org/wiki/Routing_Information_Protocol Routing Information Protocol]) is a method to dynamically update IP routing tables. In practice, on the [[AMPRNet]] gateways, it removes the requirement to periodically download the tunnel routing table ([[encap.txt]]) using FTP and apply it to the routing table. It transmits changes quicker and should be simpler to set up. Amprgw transmits the RIP routing table updates every 5 minutes, while the encap.txt has traditionally been only updated once per day. Some operators have even done the downloads manually (and not very often).<br />
<br />
The RIP protocol is used in a slightly unconventional way on the Amprnet, and the standard IP routing daemons such as zebra/quagga are not able to process these packets. Until those daemons are modified to support Amprnet routing updates, a custom implementation such as rip44d can be used.<br />
<br />
rip44d is written in the Perl programming language. C might be the conventionally right language to implement daemons such as this, but the author happened to have a good bunch of perl code that could be easily reused in the implementation of rip44d. The routing table is relatively small, so the performance or memory consumption of this daemon isn't very critical.<br />
<br />
= Requirements =<br />
<br />
# You'll need a Linux computer, which has been added in the Gateways file using the [[Portal]], so that it is know as an AMPRnet gateway and will receive RIP updates from the [[Amprgw]]. It will take some time before Amprgw will learn about new gateways.<br />
# If you have been running the gateway before, and you have already set up a cron job to automatically update the routing table by downloading encap.txt, you need to disable that cron job so that there's only one updating method running at a time.<br />
# The instructions below are currently only for Debian/Ubuntu, but there's nothing Debian-specific in rip44d - it should work fine on other distributions. It does not read or touch any of the operating system's configuration files.<br />
<br />
= Installation of dependencies on Debian/Ubuntu =<br />
<br />
install perl, and IO::Socket::Multicast, a Perl module used for receiving the RIP multicast packets<br />
<br />
sudo apt-get install perl libio-socket-multicast-perl<br />
<br />
install something to download the daemon, if needed<br />
<br />
sudo apt-get install curl<br />
<br />
= Installation of dependencies on other distributions =<br />
<br />
Other distributions should have an easy way to install the required packages too (using yum or a similar program). Please fill in details here, if you know them.<br />
<br />
If all else fails, but you have Perl installed already, you can use CPAN to install the module. For details, please see the [http://www.cpan.org/modules/INSTALL.html CPAN installation guide].<br />
<br />
cpan App::cpanminus<br />
cpanm IO::Socket::Multicast<br />
<br />
= Installation of rip44d =<br />
<br />
Download the daemon<br />
<br />
curl -k -O https://raw.github.com/hessu/rip44d/master/rip44d<br />
<br />
Make it executable<br />
<br />
chmod u+x rip44d<br />
<br />
= Run it for the first time =<br />
<br />
Run it first with the -v option to verify that it sees the route announcements from amprgw, and to learn the plaintext password used to authenticate the RIP packets (it's not included in the script, and I'm not posting it here, so that spoofing can only be done by those who are already receiving the announcements). Wait up to 5 minutes until the routes are transmitted, and it'll complain about the password it's not expecting:<br />
<br />
hessu@gateway:~$ sudo ./rip44d -v<br />
found local address: 1.2.3.4<br />
found local address: 127.0.0.1<br />
found local address: 44.255.259.253<br />
opening UDP socket...<br />
entering main loop, waiting for RIPv2 datagrams<br />
received from 44.0.0.1: 520: 504 bytes<br />
RIPv2 packet contains password PasswordFoundHere but we require none<br />
<br />
Run it again with the correct password<br />
<br />
hessu@gateway:~$ sudo ./rip44d -p PasswordGoesHere<br />
<br />
Within 5 minutes it should receive the new routing table and take it into use. For added fun, use -v (verbose) or -d (debug, really verbose) to see what it does.<br />
<br />
After confirming that it works, move it to /usr/local/sbin (or something) and put it in your boot scripts (sorry, no sysv init script provided yet). At minimum, the following lines in /etc/rc.local should do the required tricks to bring Amprnet routing up. The IP addresses are intentionally invalid – you'll need to replace them with your own.<br />
<br />
# Route my own subnet to blackhole, just to make sure I don't accidentally<br />
# transmit packets destined for us back out to Amprgw and create a loop.<br />
# More specific routes will route packets for these addresses out on the<br />
# correct radio interfaces.<br />
/sbin/ip route add blackhole 44.255.259.0/24<br />
# Bring up the tunnel interface and assign an IP address to it.<br />
/sbin/ifconfig tunl0 44.255.259.253 up || exit 2<br />
# Start up the RIP routing daemon to learn the routing table.<br />
/usr/local/sbin/rip44d -p PasswordGoesHere < /dev/null &<br />
<br />
That should be all. Really. The downside of this configuration is that it will take up to 5 minutes for the gateway to receive a routing update and become operational after a reboot. The daemon should really be improved to store the current routing table in a local file and load it from there when starting up.<br />
<br />
The above route add command will cause packets destined to 44.255.259.* to be dropped on the floor, unless a more specific route (such as 44.255.259.0/25) exists. If you route the whole /24 subnet to your radio interface, the blackhole route should not be used. If you have smaller subnets or per-host routes for each user host, the blackhole route will prevent packets destined to unused addresses from getting into a loop between your gateway and the Amprgw.<br />
<br />
= Notes =<br />
<br />
* rip44d automatically ignores announced routes which are pointed to the system's local addresses. The addresses are automatically learned using /sbin/ifconfig, but you can add more gateway addresses using -a (comma-separated list of IP addresses).<br />
* It expects that your tunnels are configured on tunl0. Use the -i <if> option to change to another. The tunnel interface must be up and configured before rip44d starts up.<br />
* Old encap routes may be present, the daemon will overwrite them as necessary (it won't touch more specific routes, or ones which are not found in the route advertisements). You don't need to "clean" the routing table before running rip44d if you have populated it from encap.txt.<br />
<br />
= Support, bug reports and improvements =<br />
<br />
If you have questions to ask about the usage of this daemon, please contact the [[44Net mailing list]].<br />
<br />
If you have improved the daemon and wish to submit a patch, please use Github. Create an account, fork the rip44d repository to your own private repository, push your changes there, and submit a merge request. I'll then merge the changes in the master source tree and release a new version. Thank you!<br />
<br />
Github repository: [https://github.com/hessu/rip44d https://github.com/hessu/rip44d]<br />
<br />
The daemon was written by Heikki Hannikainen, OH7LZB.<br />
<br />
= Links =<br />
<br />
* [http://www.qsl.net/kb9mwr/wapr/tcpip/rip44d.html Alternative installation instructions by KB9MWR]</div>Oh7lzbhttps://wiki.ampr.org/w/index.php?title=Rip44d&diff=40Rip44d2013-05-08T05:19:27Z<p>Oh7lzb: </p>
<hr />
<div>Technically, rip44d is a custom RIPv2 daemon which receives periodic routing table updates from the [[AMPRNet]] routing service ([[Amprgw]]), and inserts them in the Linux routing table.<br />
<br />
RIP ([http://en.wikipedia.org/wiki/Routing_Information_Protocol Routing Information Protocol]) is a method to dynamically update IP routing tables. In practice, on the [[AMPRNet]] gateways, it removes the requirement to periodically download the tunnel routing table ([[encap.txt]]) using FTP and apply it to the routing table. It transmits changes quicker and should be simpler to set up. Amprgw transmits the RIP routing table updates every 5 minutes, while the encap.txt has traditionally been only updated once per day. Some operators have even done the downloads manually (and not very often).<br />
<br />
The RIP protocol is used in a slightly unconventional way on the Amprnet, and the standard IP routing daemons such as zebra/quagga are not able to process these packets. Until those daemons are modified to support Amprnet routing updates, a custom implementation such as rip44d can be used.<br />
<br />
rip44d is written in the Perl programming language. C might be the conventionally right language to implement daemons such as this, but the author happened to have a good bunch of perl code that could be easily reused in the implementation of rip44d. The routing table is relatively small, so the performance or memory consumption of this daemon isn't very critical.<br />
<br />
= Requirements =<br />
<br />
# You'll need a Linux computer, which has been added in the Gateways file using the [[Portal]], so that it is know as an AMPRnet gateway and will receive RIP updates from the [[Amprgw]]. It will take some time before Amprgw will learn about new gateways.<br />
# If you have been running the gateway before, and you have already set up a cron job to automatically update the routing table by downloading encap.txt, you need to disable that cron job so that there's only one updating method running at a time.<br />
# The instructions below are currently only for Debian/Ubuntu, but there's nothing Debian-specific in rip44d - it should work fine on other distributions. It does not read or touch any of the operating system's configuration files.<br />
<br />
= Installation of dependencies on Debian/Ubuntu =<br />
<br />
install perl, and IO::Socket::Multicast, a Perl module used for receiving the RIP multicast packets<br />
<br />
sudo apt-get install perl libio-socket-multicast-perl<br />
<br />
install something to download the daemon, if needed<br />
<br />
sudo apt-get install curl<br />
<br />
= Installation of dependencies on other distributions =<br />
<br />
Other distributions should have an easy way to install the required packages too (using yum or a similar program). Please fill in details here, if you know them.<br />
<br />
If all else fails, but you have Perl installed already, you can use CPAN to install the module. For details, please see the [http://www.cpan.org/modules/INSTALL.html CPAN installation guide].<br />
<br />
cpan App::cpanminus<br />
cpanm IO::Socket::Multicast<br />
<br />
= Installation of rip44d =<br />
<br />
Download the daemon<br />
<br />
curl -k -O https://raw.github.com/hessu/rip44d/master/rip44d<br />
<br />
Make it executable<br />
<br />
chmod u+x rip44d<br />
<br />
= Run it for the first time =<br />
<br />
Run it first with the -v option to verify that it sees the route announcements from amprgw, and to learn the plaintext password used to authenticate the RIP packets (it's not included in the script, and I'm not posting it here, so that spoofing can only be done by those who are already receiving the announcements). Wait up to 5 minutes until the routes are transmitted, and it'll complain about the password it's not expecting:<br />
<br />
hessu@gateway:~$ sudo ./rip44d -v<br />
found local address: 1.2.3.4<br />
found local address: 127.0.0.1<br />
found local address: 44.255.259.253<br />
opening UDP socket...<br />
entering main loop, waiting for RIPv2 datagrams<br />
received from 44.0.0.1: 520: 504 bytes<br />
RIPv2 packet contains password PasswordFoundHere but we require none<br />
<br />
Run it again with the correct password<br />
<br />
hessu@gateway:~$ sudo ./rip44d -p PasswordGoesHere<br />
<br />
Within 5 minutes it should receive the new routing table and take it into use. For added fun, use -v (verbose) or -d (debug, really verbose) to see what it does.<br />
<br />
After confirming that it works, move it to /usr/local/sbin (or something) and put it in your boot scripts (sorry, no sysv init script provided yet). At minimum, the following lines in /etc/rc.local should do the required tricks to bring Amprnet routing up. The IP addresses are intentionally invalid – you'll need to replace them with your own.<br />
<br />
# Route my own subnet to blackhole, just to make sure I don't accidentally<br />
# transmit packets destined for us back out to Amprgw and create a loop.<br />
# More specific routes will route packets for these addresses out on the<br />
# correct radio interfaces.<br />
/sbin/ip route add blackhole 44.255.259.0/24<br />
# Bring up the tunnel interface and assign an IP address to it.<br />
/sbin/ifconfig tunl0 44.255.259.253 up || exit 2<br />
# Start up the RIP routing daemon to learn the routing table.<br />
/usr/local/sbin/rip44d -p PasswordGoesHere < /dev/null &<br />
<br />
That should be all. Really. The downside of this configuration is that it will take up to 5 minutes for the gateway to receive a routing update and become operational after a reboot. The daemon should really be improved to store the current routing table in a local file and load it from there when starting up.<br />
<br />
The above route add command will cause packets destined to 44.255.259.* to be dropped on the floor, unless a more specific route (such as 44.255.259.0/25) exists. If you route the whole /24 subnet to your radio interface, the blackhole route should not be used. If you have smaller subnets or per-host routes for each user host, the blackhole route will prevent packets destined to unused addresses from getting into a loop between your gateway and the Amprgw.<br />
<br />
= Notes =<br />
<br />
* rip44d automatically ignores announced routes which are pointed to the system's local addresses. The addresses are automatically learned using /sbin/ifconfig, but you can add more gateway addresses using -a (comma-separated list of IP addresses).<br />
* rip44d is new, and it has not received a great deal of testing, so it is likely to contain bugs. Watch it closely in the beginning. Bugfixes are welcome (diff -u, please).<br />
* It expects that your tunnels are configured on tunl0. Use the -i <if> option to change to another. The tunnel interface must be up and configured before rip44d starts up.<br />
* Old encap routes may be present, the daemon will overwrite them as necessary (it won't touch more specific routes, or ones which are not found in the route advertisements). You don't need to "clean" the routing table before running rip44d if you have populated it from encap.txt.<br />
<br />
= Support, bug reports and improvements =<br />
<br />
If you have questions to ask about the usage of this daemon, please contact the [[44Net mailing list]].<br />
<br />
If you have improved the daemon and wish to submit a patch, please use Github. Create an account, fork the rip44d repository to your own private repository, push your changes there, and submit a merge request. I'll then merge the changes in the master source tree and release a new version. Thank you!<br />
<br />
Github repository: [https://github.com/hessu/rip44d https://github.com/hessu/rip44d]<br />
<br />
The daemon was written by Heikki Hannikainen, OH7LZB.<br />
<br />
= Links =<br />
<br />
* [http://www.qsl.net/kb9mwr/wapr/tcpip/rip44d.html Alternative installation instructions by KB9MWR]</div>Oh7lzbhttps://wiki.ampr.org/w/index.php?title=Rip44d&diff=39Rip44d2013-05-08T05:03:22Z<p>Oh7lzb: </p>
<hr />
<div>Technically, rip44d is a custom RIPv2 daemon which receives periodic routing table updates from the [[AMPRNet]] routing service ([[Amprgw]]), and inserts them in the Linux routing table.<br />
<br />
RIP ([http://en.wikipedia.org/wiki/Routing_Information_Protocol Routing Information Protocol]) is a method to dynamically update IP routing tables. In practice, on the [[AMPRNet]] gateways, it removes the requirement to periodically download the tunnel routing table ([[encap.txt]]) using FTP and apply it to the routing table. It transmits changes quicker and should be simpler to set up. Amprgw transmits the RIP routing table updates every 5 minutes, while the encap.txt has traditionally been only updated once per day. Some operators have even done the downloads manually (and not very often).<br />
<br />
The RIP protocol is used in a slightly unconventional way on the Amprnet, and the standard IP routing daemons such as zebra/quagga are not able to process these packets. Until those daemons are modified to support Amprnet routing updates, a custom implementation such as rip44d can be used.<br />
<br />
rip44d is written in the Perl programming language. C might be the conventionally right language to implement daemons such as this, but the author happened to have a good bunch of perl code that could be easily reused in the implementation of rip44d. The routing table is relatively small, so the performance or memory consumption of this daemon isn't very critical.<br />
<br />
= Requirements =<br />
<br />
# You'll need a Linux computer, which has been added in the Gateways file using the [[Portal]], so that it is know as an AMPRnet gateway and will receive RIP updates from the [[Amprgw]]. It will take some time before Amprgw will learn about new gateways.<br />
# If you have been running the gateway before, and you have already set up a cron job to automatically update the routing table by downloading encap.txt, you need to disable that cron job so that there's only one updating method running at a time.<br />
# The instructions below are currently only for Debian/Ubuntu, but there's nothing Debian-specific in rip44d - it should work fine on other distributions. It does not read or touch any of the operating system's configuration files.<br />
<br />
= Installation of dependencies on Debian/Ubuntu =<br />
<br />
install perl, and IO::Socket::Multicast, a Perl module used for receiving the RIP multicast packets<br />
<br />
sudo apt-get install perl libio-socket-multicast-perl<br />
<br />
install something to download the daemon, if needed<br />
<br />
sudo apt-get install wget<br />
<br />
= Installation of dependencies on other distributions =<br />
<br />
Other distributions should have an easy way to install the required packages too (using yum or a similar program). Please fill in details here, if you know them.<br />
<br />
If all else fails, but you have Perl installed already, you can use CPAN to install the module. For details, please see the [http://www.cpan.org/modules/INSTALL.html CPAN installation guide].<br />
<br />
cpan App::cpanminus<br />
cpanm IO::Socket::Multicast<br />
<br />
= Installation of rip44d =<br />
<br />
Download the daemon<br />
<br />
wget http://he.fi/rip44d/rip44d<br />
<br />
Make it executable<br />
<br />
chmod u+x rip44d<br />
<br />
= Run it for the first time =<br />
<br />
Run it first with the -v option to verify that it sees the route announcements from amprgw, and to learn the plaintext password used to authenticate the RIP packets (it's not included in the script, and I'm not posting it here, so that spoofing can only be done by those who are already receiving the announcements). Wait up to 5 minutes until the routes are transmitted, and it'll complain about the password it's not expecting:<br />
<br />
hessu@gateway:~$ sudo ./rip44d -v<br />
found local address: 1.2.3.4<br />
found local address: 127.0.0.1<br />
found local address: 44.255.259.253<br />
opening UDP socket...<br />
entering main loop, waiting for RIPv2 datagrams<br />
received from 44.0.0.1: 520: 504 bytes<br />
RIPv2 packet contains password PasswordFoundHere but we require none<br />
<br />
Run it again with the correct password<br />
<br />
hessu@gateway:~$ sudo ./rip44d -p PasswordGoesHere<br />
<br />
Within 5 minutes it should receive the new routing table and take it into use. For added fun, use -v (verbose) or -d (debug, really verbose) to see what it does.<br />
<br />
After confirming that it works, move it to /usr/local/sbin (or something) and put it in your boot scripts (sorry, no sysv init script provided yet). At minimum, the following lines in /etc/rc.local should do the required tricks to bring Amprnet routing up. The IP addresses are intentionally invalid – you'll need to replace them with your own.<br />
<br />
# Route my own subnet to blackhole, just to make sure I don't accidentally<br />
# transmit packets destined for us back out to Amprgw and create a loop.<br />
# More specific routes will route packets for these addresses out on the<br />
# correct radio interfaces.<br />
/sbin/ip route add blackhole 44.255.259.0/24<br />
# Bring up the tunnel interface and assign an IP address to it.<br />
/sbin/ifconfig tunl0 44.255.259.253 up || exit 2<br />
# Start up the RIP routing daemon to learn the routing table.<br />
/usr/local/sbin/rip44d -p PasswordGoesHere < /dev/null &<br />
<br />
That should be all. Really. The downside of this configuration is that it will take up to 5 minutes for the gateway to receive a routing update and become operational after a reboot. The daemon should really be improved to store the current routing table in a local file and load it from there when starting up.<br />
<br />
The above route add command will cause packets destined to 44.255.259.* to be dropped on the floor, unless a more specific route (such as 44.255.259.0/25) exists. If you route the whole /24 subnet to your radio interface, the blackhole route should not be used. If you have smaller subnets or per-host routes for each user host, the blackhole route will prevent packets destined to unused addresses from getting into a loop between your gateway and the Amprgw.<br />
<br />
= Notes =<br />
<br />
* rip44d automatically ignores announced routes which are pointed to the system's local addresses. The addresses are automatically learned using /sbin/ifconfig, but you can add more gateway addresses using -a (comma-separated list of IP addresses).<br />
* rip44d is new, and it has not received a great deal of testing, so it is likely to contain bugs. Watch it closely in the beginning. Bugfixes are welcome (diff -u, please).<br />
* It expects that your tunnels are configured on tunl0. Use the -i <if> option to change to another. The tunnel interface must be up and configured before rip44d starts up.<br />
* Old encap routes may be present, the daemon will overwrite them as necessary (it won't touch more specific routes, or ones which are not found in the route advertisements). You don't need to "clean" the routing table before running rip44d if you have populated it from encap.txt.<br />
<br />
= Support, bug reports and improvements =<br />
<br />
If you have questions to ask about the usage of this daemon, please contact the [[44Net mailing list]].<br />
<br />
If you have improved the daemon and wish to submit a patch, please use Github. Create an account, fork the rip44d repository to your own private repository, push your changes there, and submit a merge request. I'll then merge the changes in the master source tree and release a new version. Thank you!<br />
<br />
Github repository: [https://github.com/hessu/rip44d https://github.com/hessu/rip44d]<br />
<br />
The daemon was written by Heikki Hannikainen, OH7LZB.</div>Oh7lzbhttps://wiki.ampr.org/w/index.php?title=Rip44d&diff=38Rip44d2013-05-08T04:58:35Z<p>Oh7lzb: /* Notes */</p>
<hr />
<div>Technically, rip44d is a custom RIPv2 daemon which receives RIP updates from the 44/8 routing service ([[Amprgw]]), and inserts them in the Linux routing table.<br />
<br />
RIP ([http://en.wikipedia.org/wiki/Routing_Information_Protocol Routing Information Protocol]) is a method to dynamically update IP routing tables. In practice, on the [[AMPRNet]] gateways, it removes the requirement to periodically download the tunnel routing table ([[encap.txt]]) using FTP and apply it to the routing table. It transmits changes quicker and should be simpler to set up. Amprgw transmits the RIP routing table updates every 5 minutes, while the encap.txt has traditionally been only updated once per day. Some operators have even done the downloads manually (and not very often).<br />
<br />
The RIP protocol is used in a slightly unconventional way on the Amprnet, and the standard IP routing daemons such as zebra/quagga are not able to process these packets. Until those daemons are modified to support Amprnet routing updates, a custom implementation such as rip44d can be used.<br />
<br />
rip44d is written in the Perl programming language. C might be the conventionally right language to implement daemons such as this, but the author happened to have a good bunch of perl code that could be easily reused in the implementation of rip44d. The routing table is relatively small, so the performance or memory consumption of this daemon isn't very critical.<br />
<br />
= Requirements =<br />
<br />
# You'll need a Linux computer, which has been added in the Gateways file using the [[Portal]], so that it is know as an AMPRnet gateway and will receive RIP updates from the [[Amprgw]]. It will take some time before Amprgw will learn about new gateways.<br />
# If you have been running the gateway before, and you have already set up a cron job to automatically update the routing table by downloading encap.txt, you need to disable that cron job so that there's only one updating method running at a time.<br />
<br />
= Installation of dependencies on Debian/Ubuntu =<br />
<br />
install perl, and IO::Socket::Multicast, a Perl module used for receiving the RIP multicast packets<br />
<br />
sudo apt-get install perl libio-socket-multicast-perl<br />
<br />
install something to download the daemon, if needed<br />
<br />
sudo apt-get install wget<br />
<br />
= Installation of dependencies on other distributions =<br />
<br />
Other distributions should have an easy way to install the required packages too (using yum or a similar program). Please fill in details here, if you know them.<br />
<br />
If all else fails, but you have Perl installed already, you can use CPAN to install the module. For details, please see the [http://www.cpan.org/modules/INSTALL.html CPAN installation guide].<br />
<br />
cpan App::cpanminus<br />
cpanm IO::Socket::Multicast<br />
<br />
= Installation of rip44d =<br />
<br />
Download the daemon<br />
<br />
wget http://he.fi/rip44d/rip44d<br />
<br />
Make it executable<br />
<br />
chmod u+x rip44d<br />
<br />
= Run it for the first time =<br />
<br />
Run it first with the -v option to verify that it sees the route announcements from amprgw, and to learn the plaintext password used to authenticate the RIP packets (it's not included in the script, and I'm not posting it here, so that spoofing can only be done by those who are already receiving the announcements). Wait up to 5 minutes until the routes are transmitted, and it'll complain about the password it's not expecting:<br />
<br />
hessu@gateway:~$ sudo ./rip44d -v<br />
found local address: 1.2.3.4<br />
found local address: 127.0.0.1<br />
found local address: 44.255.259.253<br />
opening UDP socket...<br />
entering main loop, waiting for RIPv2 datagrams<br />
received from 44.0.0.1: 520: 504 bytes<br />
RIPv2 packet contains password PasswordFoundHere but we require none<br />
<br />
Run it again with the correct password<br />
<br />
hessu@gateway:~$ sudo ./rip44d -p PasswordGoesHere<br />
<br />
Within 5 minutes it should receive the new routing table and take it into use. For added fun, use -v (verbose) or -d (debug, really verbose) to see what it does.<br />
<br />
After confirming that it works, move it to /usr/local/sbin (or something) and put it in your boot scripts (sorry, no sysv init script provided yet). At minimum, the following lines in /etc/rc.local should do the required tricks to bring Amprnet routing up. The IP addresses are intentionally invalid – you'll need to replace them with your own.<br />
<br />
# Route my own subnet to blackhole, just to make sure I don't accidentally<br />
# transmit packets destined for us back out to Amprgw and create a loop.<br />
# More specific routes will route packets for these addresses out on the<br />
# correct radio interfaces.<br />
/sbin/ip route add blackhole 44.255.259.0/24<br />
# Bring up the tunnel interface and assign an IP address to it.<br />
/sbin/ifconfig tunl0 44.255.259.253 up || exit 2<br />
# Start up the RIP routing daemon to learn the routing table.<br />
/usr/local/sbin/rip44d -p PasswordGoesHere < /dev/null &<br />
<br />
That should be all. Really. The downside of this configuration is that it will take up to 5 minutes for the gateway to receive a routing update and become operational after a reboot. The daemon should really be improved to store the current routing table in a local file and load it from there when starting up.<br />
<br />
The above route add command will cause packets destined to 44.255.259.* to be dropped on the floor, unless a more specific route (such as 44.255.259.0/25) exists. If you route the whole /24 subnet to your radio interface, the blackhole route should not be used. If you have smaller subnets or per-host routes for each user host, the blackhole route will prevent packets destined to unused addresses from getting into a loop between your gateway and the Amprgw.<br />
<br />
= Notes =<br />
<br />
* rip44d automatically ignores announced routes which are pointed to the system's local addresses. The addresses are automatically learned using /sbin/ifconfig, but you can add more gateway addresses using -a (comma-separated list of IP addresses).<br />
* rip44d is new, and it has not received a great deal of testing, so it is likely to contain bugs. Watch it closely in the beginning. Bugfixes are welcome (diff -u, please).<br />
* It expects that your tunnels are configured on tunl0. Use the -i <if> option to change to another. The tunnel interface must be up and configured before rip44d starts up.<br />
* Old encap routes may be present, the daemon will overwrite them as necessary (it won't touch more specific routes, or ones which are not found in the route advertisements). You don't need to "clean" the routing table before running rip44d if you have populated it from encap.txt.<br />
<br />
= Support, bug reports and improvements =<br />
<br />
If you have questions to ask about the usage of this daemon, please contact the [[44Net mailing list]].<br />
<br />
If you have improved the daemon and wish to submit a patch, please use Github. Create an account, fork the rip44d repository to your own private repository, push your changes there, and submit a merge request. I'll then merge the changes in the master source tree and release a new version. Thank you!<br />
<br />
Github repository: [https://github.com/hessu/rip44d https://github.com/hessu/rip44d]<br />
<br />
The daemon was written by Heikki Hannikainen, OH7LZB.</div>Oh7lzbhttps://wiki.ampr.org/w/index.php?title=Rip44d&diff=37Rip44d2013-05-08T04:51:31Z<p>Oh7lzb: /* Requirements */</p>
<hr />
<div>Technically, rip44d is a custom RIPv2 daemon which receives RIP updates from the 44/8 routing service ([[Amprgw]]), and inserts them in the Linux routing table.<br />
<br />
RIP ([http://en.wikipedia.org/wiki/Routing_Information_Protocol Routing Information Protocol]) is a method to dynamically update IP routing tables. In practice, on the [[AMPRNet]] gateways, it removes the requirement to periodically download the tunnel routing table ([[encap.txt]]) using FTP and apply it to the routing table. It transmits changes quicker and should be simpler to set up. Amprgw transmits the RIP routing table updates every 5 minutes, while the encap.txt has traditionally been only updated once per day. Some operators have even done the downloads manually (and not very often).<br />
<br />
The RIP protocol is used in a slightly unconventional way on the Amprnet, and the standard IP routing daemons such as zebra/quagga are not able to process these packets. Until those daemons are modified to support Amprnet routing updates, a custom implementation such as rip44d can be used.<br />
<br />
rip44d is written in the Perl programming language. C might be the conventionally right language to implement daemons such as this, but the author happened to have a good bunch of perl code that could be easily reused in the implementation of rip44d. The routing table is relatively small, so the performance or memory consumption of this daemon isn't very critical.<br />
<br />
= Requirements =<br />
<br />
# You'll need a Linux computer, which has been added in the Gateways file using the [[Portal]], so that it is know as an AMPRnet gateway and will receive RIP updates from the [[Amprgw]]. It will take some time before Amprgw will learn about new gateways.<br />
# If you have been running the gateway before, and you have already set up a cron job to automatically update the routing table by downloading encap.txt, you need to disable that cron job so that there's only one updating method running at a time.<br />
<br />
= Installation of dependencies on Debian/Ubuntu =<br />
<br />
install perl, and IO::Socket::Multicast, a Perl module used for receiving the RIP multicast packets<br />
<br />
sudo apt-get install perl libio-socket-multicast-perl<br />
<br />
install something to download the daemon, if needed<br />
<br />
sudo apt-get install wget<br />
<br />
= Installation of dependencies on other distributions =<br />
<br />
Other distributions should have an easy way to install the required packages too (using yum or a similar program). Please fill in details here, if you know them.<br />
<br />
If all else fails, but you have Perl installed already, you can use CPAN to install the module. For details, please see the [http://www.cpan.org/modules/INSTALL.html CPAN installation guide].<br />
<br />
cpan App::cpanminus<br />
cpanm IO::Socket::Multicast<br />
<br />
= Installation of rip44d =<br />
<br />
Download the daemon<br />
<br />
wget http://he.fi/rip44d/rip44d<br />
<br />
Make it executable<br />
<br />
chmod u+x rip44d<br />
<br />
= Run it for the first time =<br />
<br />
Run it first with the -v option to verify that it sees the route announcements from amprgw, and to learn the plaintext password used to authenticate the RIP packets (it's not included in the script, and I'm not posting it here, so that spoofing can only be done by those who are already receiving the announcements). Wait up to 5 minutes until the routes are transmitted, and it'll complain about the password it's not expecting:<br />
<br />
hessu@gateway:~$ sudo ./rip44d -v<br />
found local address: 1.2.3.4<br />
found local address: 127.0.0.1<br />
found local address: 44.255.259.253<br />
opening UDP socket...<br />
entering main loop, waiting for RIPv2 datagrams<br />
received from 44.0.0.1: 520: 504 bytes<br />
RIPv2 packet contains password PasswordFoundHere but we require none<br />
<br />
Run it again with the correct password<br />
<br />
hessu@gateway:~$ sudo ./rip44d -p PasswordGoesHere<br />
<br />
Within 5 minutes it should receive the new routing table and take it into use. For added fun, use -v (verbose) or -d (debug, really verbose) to see what it does.<br />
<br />
After confirming that it works, move it to /usr/local/sbin (or something) and put it in your boot scripts (sorry, no sysv init script provided yet). At minimum, the following lines in /etc/rc.local should do the required tricks to bring Amprnet routing up. The IP addresses are intentionally invalid – you'll need to replace them with your own.<br />
<br />
# Route my own subnet to blackhole, just to make sure I don't accidentally<br />
# transmit packets destined for us back out to Amprgw and create a loop.<br />
# More specific routes will route packets for these addresses out on the<br />
# correct radio interfaces.<br />
/sbin/ip route add blackhole 44.255.259.0/24<br />
# Bring up the tunnel interface and assign an IP address to it.<br />
/sbin/ifconfig tunl0 44.255.259.253 up || exit 2<br />
# Start up the RIP routing daemon to learn the routing table.<br />
/usr/local/sbin/rip44d -p PasswordGoesHere < /dev/null &<br />
<br />
That should be all. Really. The downside of this configuration is that it will take up to 5 minutes for the gateway to receive a routing update and become operational after a reboot. The daemon should really be improved to store the current routing table in a local file and load it from there when starting up.<br />
<br />
The above route add command will cause packets destined to 44.255.259.* to be dropped on the floor, unless a more specific route (such as 44.255.259.0/25) exists. If you route the whole /24 subnet to your radio interface, the blackhole route should not be used. If you have smaller subnets or per-host routes for each user host, the blackhole route will prevent packets destined to unused addresses from getting into a loop between your gateway and the Amprgw.<br />
<br />
= Notes =<br />
<br />
* rip44d automatically ignores announced routes which are pointed to the system's local addresses. The addresses are automatically learned using /sbin/ifconfig, but you can add more gateway addresses using -a (comma-separated list of IP addresses).<br />
* rip44d is new, and it has not received a great deal of testing, so it is likely to contain bugs. Watch it closely in the beginning. Bugfixes are welcome (diff -u, please).<br />
* It expects that your tunnels are configured on tunl0. Use the -i <if> option to change to another. The tunnel interface must be up and configured before rip44d starts up.<br />
* Old encap routes may be present, the daemon will overwrite them as necessary (it won't touch more specific routes, or ones which are not found in the route advertisements). You don't need to "clean" the routing table before running rip44d if you have populated it from encap.txt.<br />
<br />
<br />
https://github.com/hessu/rip44d<br />
<br />
LICENSE AND COPYRIGHT<br />
<br />
Copyright (C) 2011 Heikki Hannikainen, OH7LZB<br />
<br />
Packaging Copyright (C) 2012 C.J. Adams-Collier, KF7BMP<br />
<br />
This program is released under the following license:<br />
EVVKTVH / ICCLEIYSIUYA<br />
http://evvk.com/evvktvh.html#english<br />
<br />
INSTALLATION<br />
<br />
http://www.qsl.net/kb9mwr/wapr/tcpip/rip44d.html</div>Oh7lzbhttps://wiki.ampr.org/w/index.php?title=Rip44d&diff=36Rip44d2013-05-08T04:46:14Z<p>Oh7lzb: Putting in the original rip44d page</p>
<hr />
<div>Technically, rip44d is a custom RIPv2 daemon which receives RIP updates from the 44/8 routing service ([[Amprgw]]), and inserts them in the Linux routing table.<br />
<br />
RIP ([http://en.wikipedia.org/wiki/Routing_Information_Protocol Routing Information Protocol]) is a method to dynamically update IP routing tables. In practice, on the [[AMPRNet]] gateways, it removes the requirement to periodically download the tunnel routing table ([[encap.txt]]) using FTP and apply it to the routing table. It transmits changes quicker and should be simpler to set up. Amprgw transmits the RIP routing table updates every 5 minutes, while the encap.txt has traditionally been only updated once per day. Some operators have even done the downloads manually (and not very often).<br />
<br />
The RIP protocol is used in a slightly unconventional way on the Amprnet, and the standard IP routing daemons such as zebra/quagga are not able to process these packets. Until those daemons are modified to support Amprnet routing updates, a custom implementation such as rip44d can be used.<br />
<br />
rip44d is written in the Perl programming language. C might be the conventionally right language to implement daemons such as this, but the author happened to have a good bunch of perl code that could be easily reused in the implementation of rip44d. The routing table is relatively small, so the performance or memory consumption of this daemon isn't very critical.<br />
<br />
= Requirements =<br />
<br />
# You'll need a Linux computer, which has been added in the Gateways file using the [[Portal]], so that it is know as an AMPRnet gateway and will receive RIP updates from the [[Amprgw]]. It will take some time before Amprgw will learn about new gateways.<br />
# If you have been running the gateway before, and you have already set up a cron job to automatically update the routing table by downloading encap.txt, you need to disable that cron job so that there's only one updating method running at a time.<br />
<br />
<br />
https://github.com/hessu/rip44d<br />
<br />
LICENSE AND COPYRIGHT<br />
<br />
Copyright (C) 2011 Heikki Hannikainen, OH7LZB<br />
<br />
Packaging Copyright (C) 2012 C.J. Adams-Collier, KF7BMP<br />
<br />
This program is released under the following license:<br />
EVVKTVH / ICCLEIYSIUYA<br />
http://evvk.com/evvktvh.html#english<br />
<br />
INSTALLATION<br />
<br />
http://www.qsl.net/kb9mwr/wapr/tcpip/rip44d.html</div>Oh7lzbhttps://wiki.ampr.org/w/index.php?title=OH7LZB_VPN&diff=35OH7LZB VPN2013-05-08T03:55:47Z<p>Oh7lzb: /* Getting a certificate from LoTW */</p>
<hr />
<div>AMPRNet VPN is an experimental method to access the AMPRNet using a VPN from anywhere on the Internet. The VPN is openly available to any amateur radio operators who have successfully applied for an X.509 certificate from one of the following Certificate Authorities:<br />
<br />
* [http://www.arrl.org/logbook-of-the-world ARRL Logbook of the World (LoTW)]<br />
<br />
The Certificate Authority (CA) validates using a relatively strong method that the operator is actually licensed, and gives the operator a cryptographic certificate to prove that. Other services, such as the AMPRNet VPN can then check that the operator possesses a valid amateur radio operator certificate (and the accompanying private key), without any manual work being performed by the operators of those services. The operator can use his private key to sign LoTW log files, or any other information he wishes to communicate, and other parties trusting the CA can use the certificate to check that they have been transmitted by someone who has a private key and a certificate for a callsign from the CA.<br />
<br />
If and when other organisations start to give out X.509 certificates, after sufficient amateur radio license validation, the AMPRNet VPN will be configured to accept those in addition to the LoTW. If you're not willing to obtain a LoTW certificate, please set up a CA for your local club or association, document the method of license validation you're using, and I'll be happy to trust your certificates.<br />
<br />
The VPN operator (Hessu, OH7LZB) does not have time to run a CA and validate licenses manually, so please don't ask for a certificate from anywhere else than the CAs listed above. Thanks!<br />
<br />
The AMPRNet VPN is only used to access the AMPRNet. While you're connected to the AMPRNet VPN, the VPN client will only transmit packets from you to the AMPRNet via the VPN. Packets from you to the rest of the Internet will not go via the VPN - they'll flow out from your local network connection as before. This is called a [http://en.wikipedia.org/wiki/Split_tunneling split tunnel VPN configuration].<br />
<br />
The setup is still a bit complicated - it can be made easier and more automatic with a little additional software in a later phase.<br />
<br />
The AMPRNet VPN is an experimental service. It might be shut down for technical or political reasons - we'll see if it's a feasible idea or not.<br />
<br />
= Getting a certificate from LoTW =<br />
<br />
Go through [http://www.arrl.org/instructions these simple steps]. After step 4 you're ready to continue with the AMPRNet VPN.<br />
<br />
It's going to take some time to validate, and you'll have to do some manual work (especially if you're outside the USA), but that is intentional. It significantly reduces abuse of the system, and increases its security.<br />
<br />
= Extracting the certificate from LoTW =<br />
<br />
LoTW uses a custom file format (.TQ*) to exchange certificates, but after the LoTW certificate process is done and the TrustedQSL software has your certificates, they can be easily copied from TrustedQSL's directories. You'll need three files: your '''user certificate''', an '''intermediate certificate''' that was used to sign it, and your '''private key'''. The only secret piece of information is the private key - you should not reveal it to anyone at any point, as they could then use services on your behalf, using your callsign.<br />
<br />
== Windows ==<br />
<br />
* C:\Documents and Settings\your-username\Application Data\TrustedQSL contains two directories, '''certs''' and '''keys'''.<br />
* certs\user contains the '''user certificate'''<br />
* certs\authorities contains an '''intermediate certificate'''<br />
* keys\YOURCALL contains, within some XML, your '''private key'''<br />
<br />
Make copies of those files in another directory, and work on those copies in order to avoid breaking the originals.<br />
<br />
The user and intermediate certificates need to be concatenated to a single file named '''client.crt'''. The user certificate must be first, followed by the intermediate certificate. That can be done by an ascii editor such as Notepad (Wordpad or Word is likely to mess it up in a big way).<br />
<br />
The private key needs to be extracted from the YOURCALL file. The file is a regular ASCII text file, and contains a block which looks something like this (just longer):<br />
<br />
-----BEGIN RSA PRIVATE KEY-----<br />
Proc-Type: 4,ENCRYPTED<br />
DEK-Info: DES-EDE3-CBC,0C7B5495F6A91F31<br />
<br />
0xmWfliK/v9U88MFyYtUbteRoAkfVMK6BllcdID3pZzmdykHaPLZUjXOCUh3vFUX<br />
1bjnYwXpLX/CxgZ6NIxQIk7jMjL3iaP5SkWzCswqi9mCO+zHxuS6PWq7YwbWNFgo<br />
7smNcko1yTp7f/VbS4CZ5kgIF9kCgNaiqdxq+v0IcphQHRR4xjfLpBQ4ckYOi4nC<br />
jqFR1BitwBL4K2JeE9PGUkkUBwvU4oOi9PGChuoxMXs8PwKi/dZTmSWM7kOfMiBw<br />
-----END RSA PRIVATE KEY-----<br />
<br />
Copy-paste that block to a separate file named '''client.key'''.<br />
<br />
== Linux and Mac ==<br />
<br />
* ~/.tqsl/certs/user contains the '''user certificate'''<br />
* ~/.tqsl/certs/authorities contains an '''intermediate certificate'''<br />
* ~/.tqsl/keys/YOURCALL contains, within some XML, your '''private key'''<br />
<br />
The user and intermediate certificates need to be concatenated to a single file named '''client.crt'''. The user certificate must be first, followed by the intermediate certificate. That can be done by a single command:<br />
<br />
cat ~/.tqsl/certs/user ~/.tqsl/certs/authorities > client.crt<br />
<br />
The private key needs to be extracted from the YOURCALL file. The file is a regular ASCII text file, and contains a block which looks something like this (just longer):<br />
<br />
-----BEGIN RSA PRIVATE KEY-----<br />
Proc-Type: 4,ENCRYPTED<br />
DEK-Info: DES-EDE3-CBC,0C7B5495F6A91F31<br />
<br />
0xmWfliK/v9U88MFyYtUbteRoAkfVMK6BllcdID3pZzmdykHaPLZUjXOCUh3vFUX<br />
1bjnYwXpLX/CxgZ6NIxQIk7jMjL3iaP5SkWzCswqi9mCO+zHxuS6PWq7YwbWNFgo<br />
7smNcko1yTp7f/VbS4CZ5kgIF9kCgNaiqdxq+v0IcphQHRR4xjfLpBQ4ckYOi4nC<br />
jqFR1BitwBL4K2JeE9PGUkkUBwvU4oOi9PGChuoxMXs8PwKi/dZTmSWM7kOfMiBw<br />
-----END RSA PRIVATE KEY-----<br />
<br />
Copy-paste that block to a separate file named '''client.key'''. If you're going to open up the original private key file in a text editor, it's a good idea to make a backup copy of that file first in case of an accidental corruption of its contents.<br />
<br />
= Configuring AMPRNet VPN =<br />
<br />
== Windows: OpenVPN ==<br />
<br />
# [http://openvpn.net/index.php/download/community-downloads.html Download the Windows Installer], it's free and open source.<br />
# Run the installer to install it.<br />
# [http://he.fi/amprnet-vpn/amprnet-vpn-win.zip Download the AMPRNet VPN configuration files for Windows]<br />
# Open up the zip file, it contains two files: amprnet-vpn.ovpn and amprnet-vpn-ca.crt.<br />
# In Start menu, under OpenVPN => Shortcuts you'll find an entry named '''OpenVPN configuration file directory'''. Open it, and move the two files from the zip to the configuration file directory. <br />
# Place client.crt and client.key, which were created previously, in the configuration file directory.<br />
# Run the '''OpenVPN GUI''' from the desktop icon or start menu. A new icon will appear in the lower right corner (two computers with red screens + a globe on the side).<br />
# Right-click the OpenVPN toolbar icon and select '''Connect'''.<br />
<br />
If you chose to encrypt your private key with a password (or passphrase) when initially applying for a LoTW certificate and generating the Certificate Request, OpenVPN will ask you for that password when connecting.<br />
<br />
To rephrase: When OpenVPN says "Enter Password", the password being asked is the one you picked when you first applied for a LoTW certificate. It's not something the VPN operator knows (or should know). It's not the one you got on a postcard. Only you have ever been aware of that password (hopefully).<br />
<br />
== Linux: OpenVPN ==<br />
<br />
... To be written ...<br />
<br />
== Mac OS X: Tunnelblick ==<br />
<br />
# [http://code.google.com/p/tunnelblick/ Download Tunnelblick], it's free and open source, and works like a charm. It's based on OpenVPN.<br />
# [http://he.fi/amprnet-vpn/amprnet-vpn-tblk.zip Download the AMPRNet VPN configuration for Tunnelblick], it's a zip file containing a directory with a couple files<br />
# Double-click the downloaded zip file to extract it, you'll get a directory named '''amprnet-vpn.tblk'''<br />
# Move the '''private key''' (in a file which was named '''client.key''' in the previous step) to that directory<br />
# Move the certificates (in a file which was named '''client.crt''' in the previous step) to that directory<br />
# Double-click the '''amprnet-vpn.tblk''' directory - this will launch Tunnelblick and install the VPN configuration<br />
<br />
You should now see a "tunnel" icon in the top right corner of the screen. Click it to see a few menu items allowing you to connect and disconnect the VPN.<br />
<br />
If you chose to encrypt your private key with a password (or passphrase) when initially applying for a LoTW certificate and generating the Certificate Request, Tunnelblick will ask you for that passphrase when connecting.<br />
<br />
To rephrase: When Tunnelblick says "A passphrase is required to connect to amprnet-vpn", the passphrase being asked is the one you picked when you first applied for a LoTW certificate. It's not something the VPN operator knows (or should know). Only you have ever been aware of that passphrase (hopefully).</div>Oh7lzbhttps://wiki.ampr.org/w/index.php?title=OH7LZB_VPN&diff=34OH7LZB VPN2013-05-08T03:55:13Z<p>Oh7lzb: </p>
<hr />
<div>AMPRNet VPN is an experimental method to access the AMPRNet using a VPN from anywhere on the Internet. The VPN is openly available to any amateur radio operators who have successfully applied for an X.509 certificate from one of the following Certificate Authorities:<br />
<br />
* [http://www.arrl.org/logbook-of-the-world ARRL Logbook of the World (LoTW)]<br />
<br />
The Certificate Authority (CA) validates using a relatively strong method that the operator is actually licensed, and gives the operator a cryptographic certificate to prove that. Other services, such as the AMPRNet VPN can then check that the operator possesses a valid amateur radio operator certificate (and the accompanying private key), without any manual work being performed by the operators of those services. The operator can use his private key to sign LoTW log files, or any other information he wishes to communicate, and other parties trusting the CA can use the certificate to check that they have been transmitted by someone who has a private key and a certificate for a callsign from the CA.<br />
<br />
If and when other organisations start to give out X.509 certificates, after sufficient amateur radio license validation, the AMPRNet VPN will be configured to accept those in addition to the LoTW. If you're not willing to obtain a LoTW certificate, please set up a CA for your local club or association, document the method of license validation you're using, and I'll be happy to trust your certificates.<br />
<br />
The VPN operator (Hessu, OH7LZB) does not have time to run a CA and validate licenses manually, so please don't ask for a certificate from anywhere else than the CAs listed above. Thanks!<br />
<br />
The AMPRNet VPN is only used to access the AMPRNet. While you're connected to the AMPRNet VPN, the VPN client will only transmit packets from you to the AMPRNet via the VPN. Packets from you to the rest of the Internet will not go via the VPN - they'll flow out from your local network connection as before. This is called a [http://en.wikipedia.org/wiki/Split_tunneling split tunnel VPN configuration].<br />
<br />
The setup is still a bit complicated - it can be made easier and more automatic with a little additional software in a later phase.<br />
<br />
The AMPRNet VPN is an experimental service. It might be shut down for technical or political reasons - we'll see if it's a feasible idea or not.<br />
<br />
= Getting a certificate from LoTW =<br />
<br />
Go through [http://www.arrl.org/instructions these simple steps]. After step 4 you're ready to continue with the AMPRNet VPN.<br />
<br />
It's going to take some time to validate, but that is intentional. It significantly reduces abuse of the system, and increases its security.<br />
<br />
= Extracting the certificate from LoTW =<br />
<br />
LoTW uses a custom file format (.TQ*) to exchange certificates, but after the LoTW certificate process is done and the TrustedQSL software has your certificates, they can be easily copied from TrustedQSL's directories. You'll need three files: your '''user certificate''', an '''intermediate certificate''' that was used to sign it, and your '''private key'''. The only secret piece of information is the private key - you should not reveal it to anyone at any point, as they could then use services on your behalf, using your callsign.<br />
<br />
== Windows ==<br />
<br />
* C:\Documents and Settings\your-username\Application Data\TrustedQSL contains two directories, '''certs''' and '''keys'''.<br />
* certs\user contains the '''user certificate'''<br />
* certs\authorities contains an '''intermediate certificate'''<br />
* keys\YOURCALL contains, within some XML, your '''private key'''<br />
<br />
Make copies of those files in another directory, and work on those copies in order to avoid breaking the originals.<br />
<br />
The user and intermediate certificates need to be concatenated to a single file named '''client.crt'''. The user certificate must be first, followed by the intermediate certificate. That can be done by an ascii editor such as Notepad (Wordpad or Word is likely to mess it up in a big way).<br />
<br />
The private key needs to be extracted from the YOURCALL file. The file is a regular ASCII text file, and contains a block which looks something like this (just longer):<br />
<br />
-----BEGIN RSA PRIVATE KEY-----<br />
Proc-Type: 4,ENCRYPTED<br />
DEK-Info: DES-EDE3-CBC,0C7B5495F6A91F31<br />
<br />
0xmWfliK/v9U88MFyYtUbteRoAkfVMK6BllcdID3pZzmdykHaPLZUjXOCUh3vFUX<br />
1bjnYwXpLX/CxgZ6NIxQIk7jMjL3iaP5SkWzCswqi9mCO+zHxuS6PWq7YwbWNFgo<br />
7smNcko1yTp7f/VbS4CZ5kgIF9kCgNaiqdxq+v0IcphQHRR4xjfLpBQ4ckYOi4nC<br />
jqFR1BitwBL4K2JeE9PGUkkUBwvU4oOi9PGChuoxMXs8PwKi/dZTmSWM7kOfMiBw<br />
-----END RSA PRIVATE KEY-----<br />
<br />
Copy-paste that block to a separate file named '''client.key'''.<br />
<br />
== Linux and Mac ==<br />
<br />
* ~/.tqsl/certs/user contains the '''user certificate'''<br />
* ~/.tqsl/certs/authorities contains an '''intermediate certificate'''<br />
* ~/.tqsl/keys/YOURCALL contains, within some XML, your '''private key'''<br />
<br />
The user and intermediate certificates need to be concatenated to a single file named '''client.crt'''. The user certificate must be first, followed by the intermediate certificate. That can be done by a single command:<br />
<br />
cat ~/.tqsl/certs/user ~/.tqsl/certs/authorities > client.crt<br />
<br />
The private key needs to be extracted from the YOURCALL file. The file is a regular ASCII text file, and contains a block which looks something like this (just longer):<br />
<br />
-----BEGIN RSA PRIVATE KEY-----<br />
Proc-Type: 4,ENCRYPTED<br />
DEK-Info: DES-EDE3-CBC,0C7B5495F6A91F31<br />
<br />
0xmWfliK/v9U88MFyYtUbteRoAkfVMK6BllcdID3pZzmdykHaPLZUjXOCUh3vFUX<br />
1bjnYwXpLX/CxgZ6NIxQIk7jMjL3iaP5SkWzCswqi9mCO+zHxuS6PWq7YwbWNFgo<br />
7smNcko1yTp7f/VbS4CZ5kgIF9kCgNaiqdxq+v0IcphQHRR4xjfLpBQ4ckYOi4nC<br />
jqFR1BitwBL4K2JeE9PGUkkUBwvU4oOi9PGChuoxMXs8PwKi/dZTmSWM7kOfMiBw<br />
-----END RSA PRIVATE KEY-----<br />
<br />
Copy-paste that block to a separate file named '''client.key'''. If you're going to open up the original private key file in a text editor, it's a good idea to make a backup copy of that file first in case of an accidental corruption of its contents.<br />
<br />
= Configuring AMPRNet VPN =<br />
<br />
== Windows: OpenVPN ==<br />
<br />
# [http://openvpn.net/index.php/download/community-downloads.html Download the Windows Installer], it's free and open source.<br />
# Run the installer to install it.<br />
# [http://he.fi/amprnet-vpn/amprnet-vpn-win.zip Download the AMPRNet VPN configuration files for Windows]<br />
# Open up the zip file, it contains two files: amprnet-vpn.ovpn and amprnet-vpn-ca.crt.<br />
# In Start menu, under OpenVPN => Shortcuts you'll find an entry named '''OpenVPN configuration file directory'''. Open it, and move the two files from the zip to the configuration file directory. <br />
# Place client.crt and client.key, which were created previously, in the configuration file directory.<br />
# Run the '''OpenVPN GUI''' from the desktop icon or start menu. A new icon will appear in the lower right corner (two computers with red screens + a globe on the side).<br />
# Right-click the OpenVPN toolbar icon and select '''Connect'''.<br />
<br />
If you chose to encrypt your private key with a password (or passphrase) when initially applying for a LoTW certificate and generating the Certificate Request, OpenVPN will ask you for that password when connecting.<br />
<br />
To rephrase: When OpenVPN says "Enter Password", the password being asked is the one you picked when you first applied for a LoTW certificate. It's not something the VPN operator knows (or should know). It's not the one you got on a postcard. Only you have ever been aware of that password (hopefully).<br />
<br />
== Linux: OpenVPN ==<br />
<br />
... To be written ...<br />
<br />
== Mac OS X: Tunnelblick ==<br />
<br />
# [http://code.google.com/p/tunnelblick/ Download Tunnelblick], it's free and open source, and works like a charm. It's based on OpenVPN.<br />
# [http://he.fi/amprnet-vpn/amprnet-vpn-tblk.zip Download the AMPRNet VPN configuration for Tunnelblick], it's a zip file containing a directory with a couple files<br />
# Double-click the downloaded zip file to extract it, you'll get a directory named '''amprnet-vpn.tblk'''<br />
# Move the '''private key''' (in a file which was named '''client.key''' in the previous step) to that directory<br />
# Move the certificates (in a file which was named '''client.crt''' in the previous step) to that directory<br />
# Double-click the '''amprnet-vpn.tblk''' directory - this will launch Tunnelblick and install the VPN configuration<br />
<br />
You should now see a "tunnel" icon in the top right corner of the screen. Click it to see a few menu items allowing you to connect and disconnect the VPN.<br />
<br />
If you chose to encrypt your private key with a password (or passphrase) when initially applying for a LoTW certificate and generating the Certificate Request, Tunnelblick will ask you for that passphrase when connecting.<br />
<br />
To rephrase: When Tunnelblick says "A passphrase is required to connect to amprnet-vpn", the passphrase being asked is the one you picked when you first applied for a LoTW certificate. It's not something the VPN operator knows (or should know). Only you have ever been aware of that passphrase (hopefully).</div>Oh7lzbhttps://wiki.ampr.org/w/index.php?title=OH7LZB_VPN&diff=33OH7LZB VPN2013-05-07T22:35:48Z<p>Oh7lzb: /* Windows: OpenVPN */</p>
<hr />
<div>AMPRNet VPN is an experimental method to access the AMPRNet using a VPN from anywhere on the Internet. The VPN is openly available to any amateur radio operators who have successfully applied for an X.509 certificate from one of the following Certificate Authorities:<br />
<br />
* ARRL Logbook of the World (LoTW)<br />
<br />
The CA validates using a relatively strong method that the operator is actually licensed, and gives the operator a certificate to prove that. Other services, such as the AMPRNet VPN can then check that the operator possesses a valid amateur radio operator certificate (and the accompanying private key), without any manual work being performed by the operators of those services.<br />
<br />
If and when other organisations start to give out X.509 certificates, after sufficient amateur radio license validation, the AMPRNet VPN can be configured to accept those in addition to the LoTW. If you're not willing to obtain a LoTW certificate, please set up a CA for your local club or association, document the method of license validation you're using, and I'll be happy to trust your certificates.<br />
<br />
The VPN operator (Hessu, OH7LZB) does not have time to run a CA and validate licenses manually, so please don't ask for a certificate from anywhere else than the CAs listed above. Thanks!<br />
<br />
The AMPRNet VPN is only used to access the AMPRNet. While you're connected to the AMPRNet VPN, the VPN client will only transmit packets from you to the AMPRNet via the VPN. Packets from you to the rest of the Internet will not go via the VPN - they'll flow out from your local network connection as before. This is called a [http://en.wikipedia.org/wiki/Split_tunneling split tunnel VPN configuration].<br />
<br />
The setup is still a bit complicated - it can be made easier and more automatic with a little additional software in a later phase.<br />
<br />
The AMPRNet VPN is an experimental service. It might be shut down for technical or political reasons - we'll see if it's a feasible idea or not.<br />
<br />
= Extracting the certificate from LoTW =<br />
<br />
LoTW uses a custom file format (.TQ*) to exchange certificates, but after the LoTW certificate process is done and the TrustedQSL software has your certificates, they can be easily copied from TrustedQSL's directories. You'll need three files: your '''user certificate''', an '''intermediate certificate''' that was used to sign it, and your '''private key'''. The only secret piece of information is the private key - you should not reveal it to anyone at any point, as they could then use services on your behalf, using your callsign.<br />
<br />
== Windows ==<br />
<br />
* C:\Documents and Settings\your-username\Application Data\TrustedQSL contains two directories, '''certs''' and '''keys'''.<br />
* certs\user contains the '''user certificate'''<br />
* certs\authorities contains an '''intermediate certificate'''<br />
* keys\YOURCALL contains, within some XML, your '''private key'''<br />
<br />
Make copies of those files in another directory, and work on those copies in order to avoid breaking the originals.<br />
<br />
The user and intermediate certificates need to be concatenated to a single file named '''client.crt'''. The user certificate must be first, followed by the intermediate certificate. That can be done by an ascii editor such as Notepad (Wordpad or Word is likely to mess it up in a big way).<br />
<br />
The private key needs to be extracted from the YOURCALL file. The file is a regular ASCII text file, and contains a block which looks something like this (just longer):<br />
<br />
-----BEGIN RSA PRIVATE KEY-----<br />
Proc-Type: 4,ENCRYPTED<br />
DEK-Info: DES-EDE3-CBC,0C7B5495F6A91F31<br />
<br />
0xmWfliK/v9U88MFyYtUbteRoAkfVMK6BllcdID3pZzmdykHaPLZUjXOCUh3vFUX<br />
1bjnYwXpLX/CxgZ6NIxQIk7jMjL3iaP5SkWzCswqi9mCO+zHxuS6PWq7YwbWNFgo<br />
7smNcko1yTp7f/VbS4CZ5kgIF9kCgNaiqdxq+v0IcphQHRR4xjfLpBQ4ckYOi4nC<br />
jqFR1BitwBL4K2JeE9PGUkkUBwvU4oOi9PGChuoxMXs8PwKi/dZTmSWM7kOfMiBw<br />
-----END RSA PRIVATE KEY-----<br />
<br />
Copy-paste that block to a separate file named '''client.key'''.<br />
<br />
== Linux and Mac ==<br />
<br />
* ~/.tqsl/certs/user contains the '''user certificate'''<br />
* ~/.tqsl/certs/authorities contains an '''intermediate certificate'''<br />
* ~/.tqsl/keys/YOURCALL contains, within some XML, your '''private key'''<br />
<br />
The user and intermediate certificates need to be concatenated to a single file named '''client.crt'''. The user certificate must be first, followed by the intermediate certificate. That can be done by a single command:<br />
<br />
cat ~/.tqsl/certs/user ~/.tqsl/certs/authorities > client.crt<br />
<br />
The private key needs to be extracted from the YOURCALL file. The file is a regular ASCII text file, and contains a block which looks something like this (just longer):<br />
<br />
-----BEGIN RSA PRIVATE KEY-----<br />
Proc-Type: 4,ENCRYPTED<br />
DEK-Info: DES-EDE3-CBC,0C7B5495F6A91F31<br />
<br />
0xmWfliK/v9U88MFyYtUbteRoAkfVMK6BllcdID3pZzmdykHaPLZUjXOCUh3vFUX<br />
1bjnYwXpLX/CxgZ6NIxQIk7jMjL3iaP5SkWzCswqi9mCO+zHxuS6PWq7YwbWNFgo<br />
7smNcko1yTp7f/VbS4CZ5kgIF9kCgNaiqdxq+v0IcphQHRR4xjfLpBQ4ckYOi4nC<br />
jqFR1BitwBL4K2JeE9PGUkkUBwvU4oOi9PGChuoxMXs8PwKi/dZTmSWM7kOfMiBw<br />
-----END RSA PRIVATE KEY-----<br />
<br />
Copy-paste that block to a separate file named '''client.key'''. If you're going to open up the original private key file in a text editor, it's a good idea to make a backup copy of that file first in case of an accidental corruption of its contents.<br />
<br />
= Configuring AMPRNet VPN =<br />
<br />
== Windows: OpenVPN ==<br />
<br />
# [http://openvpn.net/index.php/download/community-downloads.html Download the Windows Installer], it's free and open source.<br />
# Run the installer to install it.<br />
# [http://he.fi/amprnet-vpn/amprnet-vpn-win.zip Download the AMPRNet VPN configuration files for Windows]<br />
# Open up the zip file, it contains two files: amprnet-vpn.ovpn and amprnet-vpn-ca.crt.<br />
# In Start menu, under OpenVPN => Shortcuts you'll find an entry named '''OpenVPN configuration file directory'''. Open it, and move the two files from the zip to the configuration file directory. <br />
# Place client.crt and client.key, which were created previously, in the configuration file directory.<br />
# Run the '''OpenVPN GUI''' from the desktop icon or start menu. A new icon will appear in the lower right corner (two computers with red screens + a globe on the side).<br />
# Right-click the OpenVPN toolbar icon and select '''Connect'''.<br />
<br />
If you chose to encrypt your private key with a password (or passphrase) when initially applying for a LoTW certificate and generating the Certificate Request, OpenVPN will ask you for that password when connecting.<br />
<br />
To rephrase: When OpenVPN says "Enter Password", the password being asked is the one you picked when you first applied for a LoTW certificate. It's not something the VPN operator knows (or should know). It's not the one you got on a postcard. Only you have ever been aware of that password (hopefully).<br />
<br />
== Linux: OpenVPN ==<br />
<br />
... To be written ...<br />
<br />
== Mac OS X: Tunnelblick ==<br />
<br />
# [http://code.google.com/p/tunnelblick/ Download Tunnelblick], it's free and open source, and works like a charm. It's based on OpenVPN.<br />
# [http://he.fi/amprnet-vpn/amprnet-vpn-tblk.zip Download the AMPRNet VPN configuration for Tunnelblick], it's a zip file containing a directory with a couple files<br />
# Double-click the downloaded zip file to extract it, you'll get a directory named '''amprnet-vpn.tblk'''<br />
# Move the '''private key''' (in a file which was named '''client.key''' in the previous step) to that directory<br />
# Move the certificates (in a file which was named '''client.crt''' in the previous step) to that directory<br />
# Double-click the '''amprnet-vpn.tblk''' directory - this will launch Tunnelblick and install the VPN configuration<br />
<br />
You should now see a "tunnel" icon in the top right corner of the screen. Click it to see a few menu items allowing you to connect and disconnect the VPN.<br />
<br />
If you chose to encrypt your private key with a password (or passphrase) when initially applying for a LoTW certificate and generating the Certificate Request, Tunnelblick will ask you for that passphrase when connecting.<br />
<br />
To rephrase: When Tunnelblick says "A passphrase is required to connect to amprnet-vpn", the passphrase being asked is the one you picked when you first applied for a LoTW certificate. It's not something the VPN operator knows (or should know). Only you have ever been aware of that passphrase (hopefully).</div>Oh7lzbhttps://wiki.ampr.org/w/index.php?title=OH7LZB_VPN&diff=32OH7LZB VPN2013-05-07T22:11:37Z<p>Oh7lzb: /* Windows: OpenVPN */</p>
<hr />
<div>AMPRNet VPN is an experimental method to access the AMPRNet using a VPN from anywhere on the Internet. The VPN is openly available to any amateur radio operators who have successfully applied for an X.509 certificate from one of the following Certificate Authorities:<br />
<br />
* ARRL Logbook of the World (LoTW)<br />
<br />
The CA validates using a relatively strong method that the operator is actually licensed, and gives the operator a certificate to prove that. Other services, such as the AMPRNet VPN can then check that the operator possesses a valid amateur radio operator certificate (and the accompanying private key), without any manual work being performed by the operators of those services.<br />
<br />
If and when other organisations start to give out X.509 certificates, after sufficient amateur radio license validation, the AMPRNet VPN can be configured to accept those in addition to the LoTW. If you're not willing to obtain a LoTW certificate, please set up a CA for your local club or association, document the method of license validation you're using, and I'll be happy to trust your certificates.<br />
<br />
The VPN operator (Hessu, OH7LZB) does not have time to run a CA and validate licenses manually, so please don't ask for a certificate from anywhere else than the CAs listed above. Thanks!<br />
<br />
The AMPRNet VPN is only used to access the AMPRNet. While you're connected to the AMPRNet VPN, the VPN client will only transmit packets from you to the AMPRNet via the VPN. Packets from you to the rest of the Internet will not go via the VPN - they'll flow out from your local network connection as before. This is called a [http://en.wikipedia.org/wiki/Split_tunneling split tunnel VPN configuration].<br />
<br />
The setup is still a bit complicated - it can be made easier and more automatic with a little additional software in a later phase.<br />
<br />
The AMPRNet VPN is an experimental service. It might be shut down for technical or political reasons - we'll see if it's a feasible idea or not.<br />
<br />
= Extracting the certificate from LoTW =<br />
<br />
LoTW uses a custom file format (.TQ*) to exchange certificates, but after the LoTW certificate process is done and the TrustedQSL software has your certificates, they can be easily copied from TrustedQSL's directories. You'll need three files: your '''user certificate''', an '''intermediate certificate''' that was used to sign it, and your '''private key'''. The only secret piece of information is the private key - you should not reveal it to anyone at any point, as they could then use services on your behalf, using your callsign.<br />
<br />
== Windows ==<br />
<br />
* C:\Documents and Settings\your-username\Application Data\TrustedQSL contains two directories, '''certs''' and '''keys'''.<br />
* certs\user contains the '''user certificate'''<br />
* certs\authorities contains an '''intermediate certificate'''<br />
* keys\YOURCALL contains, within some XML, your '''private key'''<br />
<br />
Make copies of those files in another directory, and work on those copies in order to avoid breaking the originals.<br />
<br />
The user and intermediate certificates need to be concatenated to a single file named '''client.crt'''. The user certificate must be first, followed by the intermediate certificate. That can be done by an ascii editor such as Notepad (Wordpad or Word is likely to mess it up in a big way).<br />
<br />
The private key needs to be extracted from the YOURCALL file. The file is a regular ASCII text file, and contains a block which looks something like this (just longer):<br />
<br />
-----BEGIN RSA PRIVATE KEY-----<br />
Proc-Type: 4,ENCRYPTED<br />
DEK-Info: DES-EDE3-CBC,0C7B5495F6A91F31<br />
<br />
0xmWfliK/v9U88MFyYtUbteRoAkfVMK6BllcdID3pZzmdykHaPLZUjXOCUh3vFUX<br />
1bjnYwXpLX/CxgZ6NIxQIk7jMjL3iaP5SkWzCswqi9mCO+zHxuS6PWq7YwbWNFgo<br />
7smNcko1yTp7f/VbS4CZ5kgIF9kCgNaiqdxq+v0IcphQHRR4xjfLpBQ4ckYOi4nC<br />
jqFR1BitwBL4K2JeE9PGUkkUBwvU4oOi9PGChuoxMXs8PwKi/dZTmSWM7kOfMiBw<br />
-----END RSA PRIVATE KEY-----<br />
<br />
Copy-paste that block to a separate file named '''client.key'''.<br />
<br />
== Linux and Mac ==<br />
<br />
* ~/.tqsl/certs/user contains the '''user certificate'''<br />
* ~/.tqsl/certs/authorities contains an '''intermediate certificate'''<br />
* ~/.tqsl/keys/YOURCALL contains, within some XML, your '''private key'''<br />
<br />
The user and intermediate certificates need to be concatenated to a single file named '''client.crt'''. The user certificate must be first, followed by the intermediate certificate. That can be done by a single command:<br />
<br />
cat ~/.tqsl/certs/user ~/.tqsl/certs/authorities > client.crt<br />
<br />
The private key needs to be extracted from the YOURCALL file. The file is a regular ASCII text file, and contains a block which looks something like this (just longer):<br />
<br />
-----BEGIN RSA PRIVATE KEY-----<br />
Proc-Type: 4,ENCRYPTED<br />
DEK-Info: DES-EDE3-CBC,0C7B5495F6A91F31<br />
<br />
0xmWfliK/v9U88MFyYtUbteRoAkfVMK6BllcdID3pZzmdykHaPLZUjXOCUh3vFUX<br />
1bjnYwXpLX/CxgZ6NIxQIk7jMjL3iaP5SkWzCswqi9mCO+zHxuS6PWq7YwbWNFgo<br />
7smNcko1yTp7f/VbS4CZ5kgIF9kCgNaiqdxq+v0IcphQHRR4xjfLpBQ4ckYOi4nC<br />
jqFR1BitwBL4K2JeE9PGUkkUBwvU4oOi9PGChuoxMXs8PwKi/dZTmSWM7kOfMiBw<br />
-----END RSA PRIVATE KEY-----<br />
<br />
Copy-paste that block to a separate file named '''client.key'''. If you're going to open up the original private key file in a text editor, it's a good idea to make a backup copy of that file first in case of an accidental corruption of its contents.<br />
<br />
= Configuring AMPRNet VPN =<br />
<br />
== Windows: OpenVPN ==<br />
<br />
# [http://openvpn.net/index.php/download/community-downloads.html Download the Windows Installer], it's free and open source.<br />
# Run the installer to install it.<br />
# [http://he.fi/amprnet-vpn/amprnet-vpn-win.zip Download the AMPRNet VPN configuration files for Windows]<br />
# Open up the zip file, it contains two files: amprnet-vpn.ovpn and amprnet-vpn-ca.crt.<br />
# In Start menu, under OpenVPN => Shortcuts you'll find an entry named '''OpenVPN configuration file directory'''. Open it, and move the two files from the zip to the configuration file directory. <br />
# Place client.crt and client.key, which were created previously, in the configuration file directory.<br />
# Run the '''OpenVPN GUI''' from the desktop icon or start menu. A new icon will appear in the lower right corner (two computers with red screens + a globe on the side).<br />
# Right-click the OpenVPN toolbar icon and select '''Connect'''.<br />
<br />
If you chose to encrypt your private key with a password (or passphrase) when initially applying for a LoTW certificate and generating the Certificate Request, Tunnelblick will ask you for that passphrase when connecting.<br />
<br />
To rephrase: When Tunnelblick says "A passphrase is required to connect to amprnet-vpn", the passphrase being asked is the one you picked when you first applied for a LoTW certificate. It's not something the VPN operator knows (or should know). Only you have ever been aware of that passphrase (hopefully).<br />
<br />
== Linux: OpenVPN ==<br />
<br />
... To be written ...<br />
<br />
== Mac OS X: Tunnelblick ==<br />
<br />
# [http://code.google.com/p/tunnelblick/ Download Tunnelblick], it's free and open source, and works like a charm. It's based on OpenVPN.<br />
# [http://he.fi/amprnet-vpn/amprnet-vpn-tblk.zip Download the AMPRNet VPN configuration for Tunnelblick], it's a zip file containing a directory with a couple files<br />
# Double-click the downloaded zip file to extract it, you'll get a directory named '''amprnet-vpn.tblk'''<br />
# Move the '''private key''' (in a file which was named '''client.key''' in the previous step) to that directory<br />
# Move the certificates (in a file which was named '''client.crt''' in the previous step) to that directory<br />
# Double-click the '''amprnet-vpn.tblk''' directory - this will launch Tunnelblick and install the VPN configuration<br />
<br />
You should now see a "tunnel" icon in the top right corner of the screen. Click it to see a few menu items allowing you to connect and disconnect the VPN.<br />
<br />
If you chose to encrypt your private key with a password (or passphrase) when initially applying for a LoTW certificate and generating the Certificate Request, Tunnelblick will ask you for that passphrase when connecting.<br />
<br />
To rephrase: When Tunnelblick says "A passphrase is required to connect to amprnet-vpn", the passphrase being asked is the one you picked when you first applied for a LoTW certificate. It's not something the VPN operator knows (or should know). Only you have ever been aware of that passphrase (hopefully).</div>Oh7lzbhttps://wiki.ampr.org/w/index.php?title=OH7LZB_VPN&diff=31OH7LZB VPN2013-05-07T22:08:32Z<p>Oh7lzb: /* Windows */</p>
<hr />
<div>AMPRNet VPN is an experimental method to access the AMPRNet using a VPN from anywhere on the Internet. The VPN is openly available to any amateur radio operators who have successfully applied for an X.509 certificate from one of the following Certificate Authorities:<br />
<br />
* ARRL Logbook of the World (LoTW)<br />
<br />
The CA validates using a relatively strong method that the operator is actually licensed, and gives the operator a certificate to prove that. Other services, such as the AMPRNet VPN can then check that the operator possesses a valid amateur radio operator certificate (and the accompanying private key), without any manual work being performed by the operators of those services.<br />
<br />
If and when other organisations start to give out X.509 certificates, after sufficient amateur radio license validation, the AMPRNet VPN can be configured to accept those in addition to the LoTW. If you're not willing to obtain a LoTW certificate, please set up a CA for your local club or association, document the method of license validation you're using, and I'll be happy to trust your certificates.<br />
<br />
The VPN operator (Hessu, OH7LZB) does not have time to run a CA and validate licenses manually, so please don't ask for a certificate from anywhere else than the CAs listed above. Thanks!<br />
<br />
The AMPRNet VPN is only used to access the AMPRNet. While you're connected to the AMPRNet VPN, the VPN client will only transmit packets from you to the AMPRNet via the VPN. Packets from you to the rest of the Internet will not go via the VPN - they'll flow out from your local network connection as before. This is called a [http://en.wikipedia.org/wiki/Split_tunneling split tunnel VPN configuration].<br />
<br />
The setup is still a bit complicated - it can be made easier and more automatic with a little additional software in a later phase.<br />
<br />
The AMPRNet VPN is an experimental service. It might be shut down for technical or political reasons - we'll see if it's a feasible idea or not.<br />
<br />
= Extracting the certificate from LoTW =<br />
<br />
LoTW uses a custom file format (.TQ*) to exchange certificates, but after the LoTW certificate process is done and the TrustedQSL software has your certificates, they can be easily copied from TrustedQSL's directories. You'll need three files: your '''user certificate''', an '''intermediate certificate''' that was used to sign it, and your '''private key'''. The only secret piece of information is the private key - you should not reveal it to anyone at any point, as they could then use services on your behalf, using your callsign.<br />
<br />
== Windows ==<br />
<br />
* C:\Documents and Settings\your-username\Application Data\TrustedQSL contains two directories, '''certs''' and '''keys'''.<br />
* certs\user contains the '''user certificate'''<br />
* certs\authorities contains an '''intermediate certificate'''<br />
* keys\YOURCALL contains, within some XML, your '''private key'''<br />
<br />
Make copies of those files in another directory, and work on those copies in order to avoid breaking the originals.<br />
<br />
The user and intermediate certificates need to be concatenated to a single file named '''client.crt'''. The user certificate must be first, followed by the intermediate certificate. That can be done by an ascii editor such as Notepad (Wordpad or Word is likely to mess it up in a big way).<br />
<br />
The private key needs to be extracted from the YOURCALL file. The file is a regular ASCII text file, and contains a block which looks something like this (just longer):<br />
<br />
-----BEGIN RSA PRIVATE KEY-----<br />
Proc-Type: 4,ENCRYPTED<br />
DEK-Info: DES-EDE3-CBC,0C7B5495F6A91F31<br />
<br />
0xmWfliK/v9U88MFyYtUbteRoAkfVMK6BllcdID3pZzmdykHaPLZUjXOCUh3vFUX<br />
1bjnYwXpLX/CxgZ6NIxQIk7jMjL3iaP5SkWzCswqi9mCO+zHxuS6PWq7YwbWNFgo<br />
7smNcko1yTp7f/VbS4CZ5kgIF9kCgNaiqdxq+v0IcphQHRR4xjfLpBQ4ckYOi4nC<br />
jqFR1BitwBL4K2JeE9PGUkkUBwvU4oOi9PGChuoxMXs8PwKi/dZTmSWM7kOfMiBw<br />
-----END RSA PRIVATE KEY-----<br />
<br />
Copy-paste that block to a separate file named '''client.key'''.<br />
<br />
== Linux and Mac ==<br />
<br />
* ~/.tqsl/certs/user contains the '''user certificate'''<br />
* ~/.tqsl/certs/authorities contains an '''intermediate certificate'''<br />
* ~/.tqsl/keys/YOURCALL contains, within some XML, your '''private key'''<br />
<br />
The user and intermediate certificates need to be concatenated to a single file named '''client.crt'''. The user certificate must be first, followed by the intermediate certificate. That can be done by a single command:<br />
<br />
cat ~/.tqsl/certs/user ~/.tqsl/certs/authorities > client.crt<br />
<br />
The private key needs to be extracted from the YOURCALL file. The file is a regular ASCII text file, and contains a block which looks something like this (just longer):<br />
<br />
-----BEGIN RSA PRIVATE KEY-----<br />
Proc-Type: 4,ENCRYPTED<br />
DEK-Info: DES-EDE3-CBC,0C7B5495F6A91F31<br />
<br />
0xmWfliK/v9U88MFyYtUbteRoAkfVMK6BllcdID3pZzmdykHaPLZUjXOCUh3vFUX<br />
1bjnYwXpLX/CxgZ6NIxQIk7jMjL3iaP5SkWzCswqi9mCO+zHxuS6PWq7YwbWNFgo<br />
7smNcko1yTp7f/VbS4CZ5kgIF9kCgNaiqdxq+v0IcphQHRR4xjfLpBQ4ckYOi4nC<br />
jqFR1BitwBL4K2JeE9PGUkkUBwvU4oOi9PGChuoxMXs8PwKi/dZTmSWM7kOfMiBw<br />
-----END RSA PRIVATE KEY-----<br />
<br />
Copy-paste that block to a separate file named '''client.key'''. If you're going to open up the original private key file in a text editor, it's a good idea to make a backup copy of that file first in case of an accidental corruption of its contents.<br />
<br />
= Configuring AMPRNet VPN =<br />
<br />
== Windows: OpenVPN ==<br />
<br />
# [http://openvpn.net/index.php/download/community-downloads.html Download the Windows Installer], it's free and open source.<br />
# Run the installer to install it.<br />
# [http://he.fi/amprnet-vpn/amprnet-vpn-win.zip Download the AMPRNet VPN configuration files for Windows]<br />
# Open up the zip file, it contains two files: amprnet-vpn.ovpn and amprnet-vpn-ca.crt.<br />
# In Start menu, under OpenVPN => Shortcuts you'll find an entry named '''OpenVPN configuration file directory'''. Open it, and move the two files from the zip to the configuration file directory. <br />
# Place client.crt and client.key, which were created previously, in the configuration file directory.<br />
# Run the OpenVPN GUI.<br />
<br />
== Linux: OpenVPN ==<br />
<br />
... To be written ...<br />
<br />
== Mac OS X: Tunnelblick ==<br />
<br />
# [http://code.google.com/p/tunnelblick/ Download Tunnelblick], it's free and open source, and works like a charm. It's based on OpenVPN.<br />
# [http://he.fi/amprnet-vpn/amprnet-vpn-tblk.zip Download the AMPRNet VPN configuration for Tunnelblick], it's a zip file containing a directory with a couple files<br />
# Double-click the downloaded zip file to extract it, you'll get a directory named '''amprnet-vpn.tblk'''<br />
# Move the '''private key''' (in a file which was named '''client.key''' in the previous step) to that directory<br />
# Move the certificates (in a file which was named '''client.crt''' in the previous step) to that directory<br />
# Double-click the '''amprnet-vpn.tblk''' directory - this will launch Tunnelblick and install the VPN configuration<br />
<br />
You should now see a "tunnel" icon in the top right corner of the screen. Click it to see a few menu items allowing you to connect and disconnect the VPN.<br />
<br />
If you chose to encrypt your private key with a password (or passphrase) when initially applying for a LoTW certificate and generating the Certificate Request, Tunnelblick will ask you for that passphrase when connecting.<br />
<br />
To rephrase: When Tunnelblick says "A passphrase is required to connect to amprnet-vpn", the passphrase being asked is the one you picked when you first applied for a LoTW certificate. It's not something the VPN operator knows (or should know). Only you have ever been aware of that passphrase (hopefully).</div>Oh7lzbhttps://wiki.ampr.org/w/index.php?title=OH7LZB_VPN&diff=30OH7LZB VPN2013-05-07T22:07:54Z<p>Oh7lzb: </p>
<hr />
<div>AMPRNet VPN is an experimental method to access the AMPRNet using a VPN from anywhere on the Internet. The VPN is openly available to any amateur radio operators who have successfully applied for an X.509 certificate from one of the following Certificate Authorities:<br />
<br />
* ARRL Logbook of the World (LoTW)<br />
<br />
The CA validates using a relatively strong method that the operator is actually licensed, and gives the operator a certificate to prove that. Other services, such as the AMPRNet VPN can then check that the operator possesses a valid amateur radio operator certificate (and the accompanying private key), without any manual work being performed by the operators of those services.<br />
<br />
If and when other organisations start to give out X.509 certificates, after sufficient amateur radio license validation, the AMPRNet VPN can be configured to accept those in addition to the LoTW. If you're not willing to obtain a LoTW certificate, please set up a CA for your local club or association, document the method of license validation you're using, and I'll be happy to trust your certificates.<br />
<br />
The VPN operator (Hessu, OH7LZB) does not have time to run a CA and validate licenses manually, so please don't ask for a certificate from anywhere else than the CAs listed above. Thanks!<br />
<br />
The AMPRNet VPN is only used to access the AMPRNet. While you're connected to the AMPRNet VPN, the VPN client will only transmit packets from you to the AMPRNet via the VPN. Packets from you to the rest of the Internet will not go via the VPN - they'll flow out from your local network connection as before. This is called a [http://en.wikipedia.org/wiki/Split_tunneling split tunnel VPN configuration].<br />
<br />
The setup is still a bit complicated - it can be made easier and more automatic with a little additional software in a later phase.<br />
<br />
The AMPRNet VPN is an experimental service. It might be shut down for technical or political reasons - we'll see if it's a feasible idea or not.<br />
<br />
= Extracting the certificate from LoTW =<br />
<br />
LoTW uses a custom file format (.TQ*) to exchange certificates, but after the LoTW certificate process is done and the TrustedQSL software has your certificates, they can be easily copied from TrustedQSL's directories. You'll need three files: your '''user certificate''', an '''intermediate certificate''' that was used to sign it, and your '''private key'''. The only secret piece of information is the private key - you should not reveal it to anyone at any point, as they could then use services on your behalf, using your callsign.<br />
<br />
== Windows ==<br />
<br />
* C:\Documents and Settings\your-username\Application Data\TrustedQSL contains two directories, '''certs''' and '''keys'''.<br />
* certs/user contains the '''user certificate'''<br />
* certs/authorities contains an '''intermediate certificate'''<br />
* keys/YOURCALL contains, within some XML, your '''private key'''<br />
<br />
Make copies of those files in another directory, and work on those copies in order to avoid breaking the originals.<br />
<br />
The user and intermediate certificates need to be concatenated to a single file named '''client.crt'''. The user certificate must be first, followed by the intermediate certificate. That can be done by an ascii editor such as Notepad (Wordpad or Word is likely to mess it up in a big way).<br />
<br />
The private key needs to be extracted from the YOURCALL file. The file is a regular ASCII text file, and contains a block which looks something like this (just longer):<br />
<br />
-----BEGIN RSA PRIVATE KEY-----<br />
Proc-Type: 4,ENCRYPTED<br />
DEK-Info: DES-EDE3-CBC,0C7B5495F6A91F31<br />
<br />
0xmWfliK/v9U88MFyYtUbteRoAkfVMK6BllcdID3pZzmdykHaPLZUjXOCUh3vFUX<br />
1bjnYwXpLX/CxgZ6NIxQIk7jMjL3iaP5SkWzCswqi9mCO+zHxuS6PWq7YwbWNFgo<br />
7smNcko1yTp7f/VbS4CZ5kgIF9kCgNaiqdxq+v0IcphQHRR4xjfLpBQ4ckYOi4nC<br />
jqFR1BitwBL4K2JeE9PGUkkUBwvU4oOi9PGChuoxMXs8PwKi/dZTmSWM7kOfMiBw<br />
-----END RSA PRIVATE KEY-----<br />
<br />
Copy-paste that block to a separate file named '''client.key'''.<br />
<br />
== Linux and Mac ==<br />
<br />
* ~/.tqsl/certs/user contains the '''user certificate'''<br />
* ~/.tqsl/certs/authorities contains an '''intermediate certificate'''<br />
* ~/.tqsl/keys/YOURCALL contains, within some XML, your '''private key'''<br />
<br />
The user and intermediate certificates need to be concatenated to a single file named '''client.crt'''. The user certificate must be first, followed by the intermediate certificate. That can be done by a single command:<br />
<br />
cat ~/.tqsl/certs/user ~/.tqsl/certs/authorities > client.crt<br />
<br />
The private key needs to be extracted from the YOURCALL file. The file is a regular ASCII text file, and contains a block which looks something like this (just longer):<br />
<br />
-----BEGIN RSA PRIVATE KEY-----<br />
Proc-Type: 4,ENCRYPTED<br />
DEK-Info: DES-EDE3-CBC,0C7B5495F6A91F31<br />
<br />
0xmWfliK/v9U88MFyYtUbteRoAkfVMK6BllcdID3pZzmdykHaPLZUjXOCUh3vFUX<br />
1bjnYwXpLX/CxgZ6NIxQIk7jMjL3iaP5SkWzCswqi9mCO+zHxuS6PWq7YwbWNFgo<br />
7smNcko1yTp7f/VbS4CZ5kgIF9kCgNaiqdxq+v0IcphQHRR4xjfLpBQ4ckYOi4nC<br />
jqFR1BitwBL4K2JeE9PGUkkUBwvU4oOi9PGChuoxMXs8PwKi/dZTmSWM7kOfMiBw<br />
-----END RSA PRIVATE KEY-----<br />
<br />
Copy-paste that block to a separate file named '''client.key'''. If you're going to open up the original private key file in a text editor, it's a good idea to make a backup copy of that file first in case of an accidental corruption of its contents.<br />
<br />
= Configuring AMPRNet VPN =<br />
<br />
== Windows: OpenVPN ==<br />
<br />
# [http://openvpn.net/index.php/download/community-downloads.html Download the Windows Installer], it's free and open source.<br />
# Run the installer to install it.<br />
# [http://he.fi/amprnet-vpn/amprnet-vpn-win.zip Download the AMPRNet VPN configuration files for Windows]<br />
# Open up the zip file, it contains two files: amprnet-vpn.ovpn and amprnet-vpn-ca.crt.<br />
# In Start menu, under OpenVPN => Shortcuts you'll find an entry named '''OpenVPN configuration file directory'''. Open it, and move the two files from the zip to the configuration file directory. <br />
# Place client.crt and client.key, which were created previously, in the configuration file directory.<br />
# Run the OpenVPN GUI.<br />
<br />
== Linux: OpenVPN ==<br />
<br />
... To be written ...<br />
<br />
== Mac OS X: Tunnelblick ==<br />
<br />
# [http://code.google.com/p/tunnelblick/ Download Tunnelblick], it's free and open source, and works like a charm. It's based on OpenVPN.<br />
# [http://he.fi/amprnet-vpn/amprnet-vpn-tblk.zip Download the AMPRNet VPN configuration for Tunnelblick], it's a zip file containing a directory with a couple files<br />
# Double-click the downloaded zip file to extract it, you'll get a directory named '''amprnet-vpn.tblk'''<br />
# Move the '''private key''' (in a file which was named '''client.key''' in the previous step) to that directory<br />
# Move the certificates (in a file which was named '''client.crt''' in the previous step) to that directory<br />
# Double-click the '''amprnet-vpn.tblk''' directory - this will launch Tunnelblick and install the VPN configuration<br />
<br />
You should now see a "tunnel" icon in the top right corner of the screen. Click it to see a few menu items allowing you to connect and disconnect the VPN.<br />
<br />
If you chose to encrypt your private key with a password (or passphrase) when initially applying for a LoTW certificate and generating the Certificate Request, Tunnelblick will ask you for that passphrase when connecting.<br />
<br />
To rephrase: When Tunnelblick says "A passphrase is required to connect to amprnet-vpn", the passphrase being asked is the one you picked when you first applied for a LoTW certificate. It's not something the VPN operator knows (or should know). Only you have ever been aware of that passphrase (hopefully).</div>Oh7lzbhttps://wiki.ampr.org/w/index.php?title=OH7LZB_VPN&diff=29OH7LZB VPN2013-05-07T22:05:52Z<p>Oh7lzb: /* Linux: OpenVPN */</p>
<hr />
<div>AMPRNet VPN is an experimental method to access the AMPRNet using a VPN from anywhere on the Internet. The VPN is openly available to any amateur radio operators who have successfully applied for an X.509 certificate from one of the following Certificate Authorities:<br />
<br />
* ARRL Logbook of the World (LoTW)<br />
<br />
The CA validates using a relatively strong method that the operator is actually licensed, and gives the operator a certificate to prove that. Other services, such as the AMPRNet VPN can then check that the operator possesses a valid amateur radio operator certificate (and the accompanying private key), without any manual work being performed by the operators of those services.<br />
<br />
If and when other organisations start to give out X.509 certificates, after sufficient amateur radio license validation, the AMPRNet VPN can be configured to accept those in addition to the LoTW. If you're not willing to obtain a LoTW certificate, please set up a CA for your local club or association, document the method of license validation you're using, and I'll be happy to trust your certificates.<br />
<br />
The VPN operator does not have time to run a CA and validate licenses manually, so please don't ask for a certificate from anywhere else than the CAs listed above. Thanks!<br />
<br />
The AMPRNet VPN is only used to access the AMPRNet. While you're connected to the AMPRNet VPN, the VPN client will only transmit packets from you to the AMPRNet via the VPN. Packets from you to the rest of the Internet will not go via the VPN - they'll flow out from your local network connection as before. This is called a [http://en.wikipedia.org/wiki/Split_tunneling split tunnel VPN configuration].<br />
<br />
The setup is still a bit complicated - it can be made easier and more automatic with a little additional software in a later phase.<br />
<br />
= Extracting the certificate from LoTW =<br />
<br />
LoTW uses a custom file format (.TQ*) to exchange certificates, but after the LoTW certificate process is done and the TrustedQSL software has your certificates, they can be easily copied from TrustedQSL's directories. You'll need three files: your '''user certificate''', an '''intermediate certificate''' that was used to sign it, and your '''private key'''. The only secret piece of information is the private key - you should not reveal it to anyone at any point, as they could then use services on your behalf, using your callsign.<br />
<br />
== Windows ==<br />
<br />
* C:\Documents and Settings\your-username\Application Data\TrustedQSL contains two directories, '''certs''' and '''keys'''.<br />
* certs/user contains the '''user certificate'''<br />
* certs/authorities contains an '''intermediate certificate'''<br />
* keys/YOURCALL contains, within some XML, your '''private key'''<br />
<br />
Make copies of those files in another directory, and work on those copies in order to avoid breaking the originals.<br />
<br />
The user and intermediate certificates need to be concatenated to a single file named '''client.crt'''. The user certificate must be first, followed by the intermediate certificate. That can be done by an ascii editor such as Notepad (Wordpad or Word is likely to mess it up in a big way).<br />
<br />
The private key needs to be extracted from the YOURCALL file. The file is a regular ASCII text file, and contains a block which looks something like this (just longer):<br />
<br />
-----BEGIN RSA PRIVATE KEY-----<br />
Proc-Type: 4,ENCRYPTED<br />
DEK-Info: DES-EDE3-CBC,0C7B5495F6A91F31<br />
<br />
0xmWfliK/v9U88MFyYtUbteRoAkfVMK6BllcdID3pZzmdykHaPLZUjXOCUh3vFUX<br />
1bjnYwXpLX/CxgZ6NIxQIk7jMjL3iaP5SkWzCswqi9mCO+zHxuS6PWq7YwbWNFgo<br />
7smNcko1yTp7f/VbS4CZ5kgIF9kCgNaiqdxq+v0IcphQHRR4xjfLpBQ4ckYOi4nC<br />
jqFR1BitwBL4K2JeE9PGUkkUBwvU4oOi9PGChuoxMXs8PwKi/dZTmSWM7kOfMiBw<br />
-----END RSA PRIVATE KEY-----<br />
<br />
Copy-paste that block to a separate file named '''client.key'''.<br />
<br />
== Linux and Mac ==<br />
<br />
* ~/.tqsl/certs/user contains the '''user certificate'''<br />
* ~/.tqsl/certs/authorities contains an '''intermediate certificate'''<br />
* ~/.tqsl/keys/YOURCALL contains, within some XML, your '''private key'''<br />
<br />
The user and intermediate certificates need to be concatenated to a single file named '''client.crt'''. The user certificate must be first, followed by the intermediate certificate. That can be done by a single command:<br />
<br />
cat ~/.tqsl/certs/user ~/.tqsl/certs/authorities > client.crt<br />
<br />
The private key needs to be extracted from the YOURCALL file. The file is a regular ASCII text file, and contains a block which looks something like this (just longer):<br />
<br />
-----BEGIN RSA PRIVATE KEY-----<br />
Proc-Type: 4,ENCRYPTED<br />
DEK-Info: DES-EDE3-CBC,0C7B5495F6A91F31<br />
<br />
0xmWfliK/v9U88MFyYtUbteRoAkfVMK6BllcdID3pZzmdykHaPLZUjXOCUh3vFUX<br />
1bjnYwXpLX/CxgZ6NIxQIk7jMjL3iaP5SkWzCswqi9mCO+zHxuS6PWq7YwbWNFgo<br />
7smNcko1yTp7f/VbS4CZ5kgIF9kCgNaiqdxq+v0IcphQHRR4xjfLpBQ4ckYOi4nC<br />
jqFR1BitwBL4K2JeE9PGUkkUBwvU4oOi9PGChuoxMXs8PwKi/dZTmSWM7kOfMiBw<br />
-----END RSA PRIVATE KEY-----<br />
<br />
Copy-paste that block to a separate file named '''client.key'''. If you're going to open up the original private key file in a text editor, it's a good idea to make a backup copy of that file first in case of an accidental corruption of its contents.<br />
<br />
= Configuring AMPRNet VPN =<br />
<br />
== Windows: OpenVPN ==<br />
<br />
# [http://openvpn.net/index.php/download/community-downloads.html Download the Windows Installer], it's free and open source.<br />
# Run the installer to install it.<br />
# [http://he.fi/amprnet-vpn/amprnet-vpn-win.zip Download the AMPRNet VPN configuration files for Windows]<br />
# Open up the zip file, it contains two files: amprnet-vpn.ovpn and amprnet-vpn-ca.crt.<br />
# In Start menu, under OpenVPN => Shortcuts you'll find an entry named '''OpenVPN configuration file directory'''. Open it, and move the two files from the zip to the configuration file directory. <br />
# Place client.crt and client.key, which were created previously, in the configuration file directory.<br />
# Run the OpenVPN GUI.<br />
<br />
== Linux: OpenVPN ==<br />
<br />
... To be written ...<br />
<br />
== Mac OS X: Tunnelblick ==<br />
<br />
# [http://code.google.com/p/tunnelblick/ Download Tunnelblick], it's free and open source, and works like a charm. It's based on OpenVPN.<br />
# [http://he.fi/amprnet-vpn/amprnet-vpn-tblk.zip Download the AMPRNet VPN configuration for Tunnelblick], it's a zip file containing a directory with a couple files<br />
# Double-click the downloaded zip file to extract it, you'll get a directory named '''amprnet-vpn.tblk'''<br />
# Move the '''private key''' (in a file which was named '''client.key''' in the previous step) to that directory<br />
# Move the certificates (in a file which was named '''client.crt''' in the previous step) to that directory<br />
# Double-click the '''amprnet-vpn.tblk''' directory - this will launch Tunnelblick and install the VPN configuration<br />
<br />
You should now see a "tunnel" icon in the top right corner of the screen. Click it to see a few menu items allowing you to connect and disconnect the VPN.<br />
<br />
If you chose to encrypt your private key with a password (or passphrase) when initially applying for a LoTW certificate and generating the Certificate Request, Tunnelblick will ask you for that passphrase when connecting.<br />
<br />
To rephrase: When Tunnelblick says "A passphrase is required to connect to amprnet-vpn", the passphrase being asked is the one you picked when you first applied for a LoTW certificate. It's not something the VPN operator knows (or should know). Only you have ever been aware of that passphrase (hopefully).</div>Oh7lzbhttps://wiki.ampr.org/w/index.php?title=OH7LZB_VPN&diff=28OH7LZB VPN2013-05-07T22:04:51Z<p>Oh7lzb: /* Windows: OpenVPN */</p>
<hr />
<div>AMPRNet VPN is an experimental method to access the AMPRNet using a VPN from anywhere on the Internet. The VPN is openly available to any amateur radio operators who have successfully applied for an X.509 certificate from one of the following Certificate Authorities:<br />
<br />
* ARRL Logbook of the World (LoTW)<br />
<br />
The CA validates using a relatively strong method that the operator is actually licensed, and gives the operator a certificate to prove that. Other services, such as the AMPRNet VPN can then check that the operator possesses a valid amateur radio operator certificate (and the accompanying private key), without any manual work being performed by the operators of those services.<br />
<br />
If and when other organisations start to give out X.509 certificates, after sufficient amateur radio license validation, the AMPRNet VPN can be configured to accept those in addition to the LoTW. If you're not willing to obtain a LoTW certificate, please set up a CA for your local club or association, document the method of license validation you're using, and I'll be happy to trust your certificates.<br />
<br />
The VPN operator does not have time to run a CA and validate licenses manually, so please don't ask for a certificate from anywhere else than the CAs listed above. Thanks!<br />
<br />
The AMPRNet VPN is only used to access the AMPRNet. While you're connected to the AMPRNet VPN, the VPN client will only transmit packets from you to the AMPRNet via the VPN. Packets from you to the rest of the Internet will not go via the VPN - they'll flow out from your local network connection as before. This is called a [http://en.wikipedia.org/wiki/Split_tunneling split tunnel VPN configuration].<br />
<br />
The setup is still a bit complicated - it can be made easier and more automatic with a little additional software in a later phase.<br />
<br />
= Extracting the certificate from LoTW =<br />
<br />
LoTW uses a custom file format (.TQ*) to exchange certificates, but after the LoTW certificate process is done and the TrustedQSL software has your certificates, they can be easily copied from TrustedQSL's directories. You'll need three files: your '''user certificate''', an '''intermediate certificate''' that was used to sign it, and your '''private key'''. The only secret piece of information is the private key - you should not reveal it to anyone at any point, as they could then use services on your behalf, using your callsign.<br />
<br />
== Windows ==<br />
<br />
* C:\Documents and Settings\your-username\Application Data\TrustedQSL contains two directories, '''certs''' and '''keys'''.<br />
* certs/user contains the '''user certificate'''<br />
* certs/authorities contains an '''intermediate certificate'''<br />
* keys/YOURCALL contains, within some XML, your '''private key'''<br />
<br />
Make copies of those files in another directory, and work on those copies in order to avoid breaking the originals.<br />
<br />
The user and intermediate certificates need to be concatenated to a single file named '''client.crt'''. The user certificate must be first, followed by the intermediate certificate. That can be done by an ascii editor such as Notepad (Wordpad or Word is likely to mess it up in a big way).<br />
<br />
The private key needs to be extracted from the YOURCALL file. The file is a regular ASCII text file, and contains a block which looks something like this (just longer):<br />
<br />
-----BEGIN RSA PRIVATE KEY-----<br />
Proc-Type: 4,ENCRYPTED<br />
DEK-Info: DES-EDE3-CBC,0C7B5495F6A91F31<br />
<br />
0xmWfliK/v9U88MFyYtUbteRoAkfVMK6BllcdID3pZzmdykHaPLZUjXOCUh3vFUX<br />
1bjnYwXpLX/CxgZ6NIxQIk7jMjL3iaP5SkWzCswqi9mCO+zHxuS6PWq7YwbWNFgo<br />
7smNcko1yTp7f/VbS4CZ5kgIF9kCgNaiqdxq+v0IcphQHRR4xjfLpBQ4ckYOi4nC<br />
jqFR1BitwBL4K2JeE9PGUkkUBwvU4oOi9PGChuoxMXs8PwKi/dZTmSWM7kOfMiBw<br />
-----END RSA PRIVATE KEY-----<br />
<br />
Copy-paste that block to a separate file named '''client.key'''.<br />
<br />
== Linux and Mac ==<br />
<br />
* ~/.tqsl/certs/user contains the '''user certificate'''<br />
* ~/.tqsl/certs/authorities contains an '''intermediate certificate'''<br />
* ~/.tqsl/keys/YOURCALL contains, within some XML, your '''private key'''<br />
<br />
The user and intermediate certificates need to be concatenated to a single file named '''client.crt'''. The user certificate must be first, followed by the intermediate certificate. That can be done by a single command:<br />
<br />
cat ~/.tqsl/certs/user ~/.tqsl/certs/authorities > client.crt<br />
<br />
The private key needs to be extracted from the YOURCALL file. The file is a regular ASCII text file, and contains a block which looks something like this (just longer):<br />
<br />
-----BEGIN RSA PRIVATE KEY-----<br />
Proc-Type: 4,ENCRYPTED<br />
DEK-Info: DES-EDE3-CBC,0C7B5495F6A91F31<br />
<br />
0xmWfliK/v9U88MFyYtUbteRoAkfVMK6BllcdID3pZzmdykHaPLZUjXOCUh3vFUX<br />
1bjnYwXpLX/CxgZ6NIxQIk7jMjL3iaP5SkWzCswqi9mCO+zHxuS6PWq7YwbWNFgo<br />
7smNcko1yTp7f/VbS4CZ5kgIF9kCgNaiqdxq+v0IcphQHRR4xjfLpBQ4ckYOi4nC<br />
jqFR1BitwBL4K2JeE9PGUkkUBwvU4oOi9PGChuoxMXs8PwKi/dZTmSWM7kOfMiBw<br />
-----END RSA PRIVATE KEY-----<br />
<br />
Copy-paste that block to a separate file named '''client.key'''. If you're going to open up the original private key file in a text editor, it's a good idea to make a backup copy of that file first in case of an accidental corruption of its contents.<br />
<br />
= Configuring AMPRNet VPN =<br />
<br />
== Windows: OpenVPN ==<br />
<br />
# [http://openvpn.net/index.php/download/community-downloads.html Download the Windows Installer], it's free and open source.<br />
# Run the installer to install it.<br />
# [http://he.fi/amprnet-vpn/amprnet-vpn-win.zip Download the AMPRNet VPN configuration files for Windows]<br />
# Open up the zip file, it contains two files: amprnet-vpn.ovpn and amprnet-vpn-ca.crt.<br />
# In Start menu, under OpenVPN => Shortcuts you'll find an entry named '''OpenVPN configuration file directory'''. Open it, and move the two files from the zip to the configuration file directory. <br />
# Place client.crt and client.key, which were created previously, in the configuration file directory.<br />
# Run the OpenVPN GUI.<br />
<br />
== Linux: OpenVPN ==<br />
<br />
== Mac OS X: Tunnelblick ==<br />
<br />
# [http://code.google.com/p/tunnelblick/ Download Tunnelblick], it's free and open source, and works like a charm. It's based on OpenVPN.<br />
# [http://he.fi/amprnet-vpn/amprnet-vpn-tblk.zip Download the AMPRNet VPN configuration for Tunnelblick], it's a zip file containing a directory with a couple files<br />
# Double-click the downloaded zip file to extract it, you'll get a directory named '''amprnet-vpn.tblk'''<br />
# Move the '''private key''' (in a file which was named '''client.key''' in the previous step) to that directory<br />
# Move the certificates (in a file which was named '''client.crt''' in the previous step) to that directory<br />
# Double-click the '''amprnet-vpn.tblk''' directory - this will launch Tunnelblick and install the VPN configuration<br />
<br />
You should now see a "tunnel" icon in the top right corner of the screen. Click it to see a few menu items allowing you to connect and disconnect the VPN.<br />
<br />
If you chose to encrypt your private key with a password (or passphrase) when initially applying for a LoTW certificate and generating the Certificate Request, Tunnelblick will ask you for that passphrase when connecting.<br />
<br />
To rephrase: When Tunnelblick says "A passphrase is required to connect to amprnet-vpn", the passphrase being asked is the one you picked when you first applied for a LoTW certificate. It's not something the VPN operator knows (or should know). Only you have ever been aware of that passphrase (hopefully).</div>Oh7lzbhttps://wiki.ampr.org/w/index.php?title=OH7LZB_VPN&diff=27OH7LZB VPN2013-05-07T21:50:19Z<p>Oh7lzb: /* Windows */</p>
<hr />
<div>AMPRNet VPN is an experimental method to access the AMPRNet using a VPN from anywhere on the Internet. The VPN is openly available to any amateur radio operators who have successfully applied for an X.509 certificate from one of the following Certificate Authorities:<br />
<br />
* ARRL Logbook of the World (LoTW)<br />
<br />
The CA validates using a relatively strong method that the operator is actually licensed, and gives the operator a certificate to prove that. Other services, such as the AMPRNet VPN can then check that the operator possesses a valid amateur radio operator certificate (and the accompanying private key), without any manual work being performed by the operators of those services.<br />
<br />
If and when other organisations start to give out X.509 certificates, after sufficient amateur radio license validation, the AMPRNet VPN can be configured to accept those in addition to the LoTW. If you're not willing to obtain a LoTW certificate, please set up a CA for your local club or association, document the method of license validation you're using, and I'll be happy to trust your certificates.<br />
<br />
The VPN operator does not have time to run a CA and validate licenses manually, so please don't ask for a certificate from anywhere else than the CAs listed above. Thanks!<br />
<br />
The AMPRNet VPN is only used to access the AMPRNet. While you're connected to the AMPRNet VPN, the VPN client will only transmit packets from you to the AMPRNet via the VPN. Packets from you to the rest of the Internet will not go via the VPN - they'll flow out from your local network connection as before. This is called a [http://en.wikipedia.org/wiki/Split_tunneling split tunnel VPN configuration].<br />
<br />
The setup is still a bit complicated - it can be made easier and more automatic with a little additional software in a later phase.<br />
<br />
= Extracting the certificate from LoTW =<br />
<br />
LoTW uses a custom file format (.TQ*) to exchange certificates, but after the LoTW certificate process is done and the TrustedQSL software has your certificates, they can be easily copied from TrustedQSL's directories. You'll need three files: your '''user certificate''', an '''intermediate certificate''' that was used to sign it, and your '''private key'''. The only secret piece of information is the private key - you should not reveal it to anyone at any point, as they could then use services on your behalf, using your callsign.<br />
<br />
== Windows ==<br />
<br />
* C:\Documents and Settings\your-username\Application Data\TrustedQSL contains two directories, '''certs''' and '''keys'''.<br />
* certs/user contains the '''user certificate'''<br />
* certs/authorities contains an '''intermediate certificate'''<br />
* keys/YOURCALL contains, within some XML, your '''private key'''<br />
<br />
Make copies of those files in another directory, and work on those copies in order to avoid breaking the originals.<br />
<br />
The user and intermediate certificates need to be concatenated to a single file named '''client.crt'''. The user certificate must be first, followed by the intermediate certificate. That can be done by an ascii editor such as Notepad (Wordpad or Word is likely to mess it up in a big way).<br />
<br />
The private key needs to be extracted from the YOURCALL file. The file is a regular ASCII text file, and contains a block which looks something like this (just longer):<br />
<br />
-----BEGIN RSA PRIVATE KEY-----<br />
Proc-Type: 4,ENCRYPTED<br />
DEK-Info: DES-EDE3-CBC,0C7B5495F6A91F31<br />
<br />
0xmWfliK/v9U88MFyYtUbteRoAkfVMK6BllcdID3pZzmdykHaPLZUjXOCUh3vFUX<br />
1bjnYwXpLX/CxgZ6NIxQIk7jMjL3iaP5SkWzCswqi9mCO+zHxuS6PWq7YwbWNFgo<br />
7smNcko1yTp7f/VbS4CZ5kgIF9kCgNaiqdxq+v0IcphQHRR4xjfLpBQ4ckYOi4nC<br />
jqFR1BitwBL4K2JeE9PGUkkUBwvU4oOi9PGChuoxMXs8PwKi/dZTmSWM7kOfMiBw<br />
-----END RSA PRIVATE KEY-----<br />
<br />
Copy-paste that block to a separate file named '''client.key'''.<br />
<br />
== Linux and Mac ==<br />
<br />
* ~/.tqsl/certs/user contains the '''user certificate'''<br />
* ~/.tqsl/certs/authorities contains an '''intermediate certificate'''<br />
* ~/.tqsl/keys/YOURCALL contains, within some XML, your '''private key'''<br />
<br />
The user and intermediate certificates need to be concatenated to a single file named '''client.crt'''. The user certificate must be first, followed by the intermediate certificate. That can be done by a single command:<br />
<br />
cat ~/.tqsl/certs/user ~/.tqsl/certs/authorities > client.crt<br />
<br />
The private key needs to be extracted from the YOURCALL file. The file is a regular ASCII text file, and contains a block which looks something like this (just longer):<br />
<br />
-----BEGIN RSA PRIVATE KEY-----<br />
Proc-Type: 4,ENCRYPTED<br />
DEK-Info: DES-EDE3-CBC,0C7B5495F6A91F31<br />
<br />
0xmWfliK/v9U88MFyYtUbteRoAkfVMK6BllcdID3pZzmdykHaPLZUjXOCUh3vFUX<br />
1bjnYwXpLX/CxgZ6NIxQIk7jMjL3iaP5SkWzCswqi9mCO+zHxuS6PWq7YwbWNFgo<br />
7smNcko1yTp7f/VbS4CZ5kgIF9kCgNaiqdxq+v0IcphQHRR4xjfLpBQ4ckYOi4nC<br />
jqFR1BitwBL4K2JeE9PGUkkUBwvU4oOi9PGChuoxMXs8PwKi/dZTmSWM7kOfMiBw<br />
-----END RSA PRIVATE KEY-----<br />
<br />
Copy-paste that block to a separate file named '''client.key'''. If you're going to open up the original private key file in a text editor, it's a good idea to make a backup copy of that file first in case of an accidental corruption of its contents.<br />
<br />
= Configuring AMPRNet VPN =<br />
<br />
== Windows: OpenVPN ==<br />
<br />
# [http://openvpn.net/index.php/download/community-downloads.html Download the Windows Installer], it's free and open source.<br />
<br />
== Linux: OpenVPN ==<br />
<br />
== Mac OS X: Tunnelblick ==<br />
<br />
# [http://code.google.com/p/tunnelblick/ Download Tunnelblick], it's free and open source, and works like a charm. It's based on OpenVPN.<br />
# [http://he.fi/amprnet-vpn/amprnet-vpn-tblk.zip Download the AMPRNet VPN configuration for Tunnelblick], it's a zip file containing a directory with a couple files<br />
# Double-click the downloaded zip file to extract it, you'll get a directory named '''amprnet-vpn.tblk'''<br />
# Move the '''private key''' (in a file which was named '''client.key''' in the previous step) to that directory<br />
# Move the certificates (in a file which was named '''client.crt''' in the previous step) to that directory<br />
# Double-click the '''amprnet-vpn.tblk''' directory - this will launch Tunnelblick and install the VPN configuration<br />
<br />
You should now see a "tunnel" icon in the top right corner of the screen. Click it to see a few menu items allowing you to connect and disconnect the VPN.<br />
<br />
If you chose to encrypt your private key with a password (or passphrase) when initially applying for a LoTW certificate and generating the Certificate Request, Tunnelblick will ask you for that passphrase when connecting.<br />
<br />
To rephrase: When Tunnelblick says "A passphrase is required to connect to amprnet-vpn", the passphrase being asked is the one you picked when you first applied for a LoTW certificate. It's not something the VPN operator knows (or should know). Only you have ever been aware of that passphrase (hopefully).</div>Oh7lzbhttps://wiki.ampr.org/w/index.php?title=OH7LZB_VPN&diff=26OH7LZB VPN2013-05-07T21:50:00Z<p>Oh7lzb: /* Extracting the certificate from LoTW */</p>
<hr />
<div>AMPRNet VPN is an experimental method to access the AMPRNet using a VPN from anywhere on the Internet. The VPN is openly available to any amateur radio operators who have successfully applied for an X.509 certificate from one of the following Certificate Authorities:<br />
<br />
* ARRL Logbook of the World (LoTW)<br />
<br />
The CA validates using a relatively strong method that the operator is actually licensed, and gives the operator a certificate to prove that. Other services, such as the AMPRNet VPN can then check that the operator possesses a valid amateur radio operator certificate (and the accompanying private key), without any manual work being performed by the operators of those services.<br />
<br />
If and when other organisations start to give out X.509 certificates, after sufficient amateur radio license validation, the AMPRNet VPN can be configured to accept those in addition to the LoTW. If you're not willing to obtain a LoTW certificate, please set up a CA for your local club or association, document the method of license validation you're using, and I'll be happy to trust your certificates.<br />
<br />
The VPN operator does not have time to run a CA and validate licenses manually, so please don't ask for a certificate from anywhere else than the CAs listed above. Thanks!<br />
<br />
The AMPRNet VPN is only used to access the AMPRNet. While you're connected to the AMPRNet VPN, the VPN client will only transmit packets from you to the AMPRNet via the VPN. Packets from you to the rest of the Internet will not go via the VPN - they'll flow out from your local network connection as before. This is called a [http://en.wikipedia.org/wiki/Split_tunneling split tunnel VPN configuration].<br />
<br />
The setup is still a bit complicated - it can be made easier and more automatic with a little additional software in a later phase.<br />
<br />
= Extracting the certificate from LoTW =<br />
<br />
LoTW uses a custom file format (.TQ*) to exchange certificates, but after the LoTW certificate process is done and the TrustedQSL software has your certificates, they can be easily copied from TrustedQSL's directories. You'll need three files: your '''user certificate''', an '''intermediate certificate''' that was used to sign it, and your '''private key'''. The only secret piece of information is the private key - you should not reveal it to anyone at any point, as they could then use services on your behalf, using your callsign.<br />
<br />
== Windows ==<br />
<br />
* C:\Documents and Settings\hessu\Application Data\TrustedQSL contains two directories, '''certs''' and '''keys'''.<br />
* certs/user contains the '''user certificate'''<br />
* certs/authorities contains an '''intermediate certificate'''<br />
* keys/YOURCALL contains, within some XML, your '''private key'''<br />
<br />
Make copies of those files in another directory, and work on those copies in order to avoid breaking the originals.<br />
<br />
The user and intermediate certificates need to be concatenated to a single file named '''client.crt'''. The user certificate must be first, followed by the intermediate certificate. That can be done by an ascii editor such as Notepad (Wordpad or Word is likely to mess it up in a big way).<br />
<br />
The private key needs to be extracted from the YOURCALL file. The file is a regular ASCII text file, and contains a block which looks something like this (just longer):<br />
<br />
-----BEGIN RSA PRIVATE KEY-----<br />
Proc-Type: 4,ENCRYPTED<br />
DEK-Info: DES-EDE3-CBC,0C7B5495F6A91F31<br />
<br />
0xmWfliK/v9U88MFyYtUbteRoAkfVMK6BllcdID3pZzmdykHaPLZUjXOCUh3vFUX<br />
1bjnYwXpLX/CxgZ6NIxQIk7jMjL3iaP5SkWzCswqi9mCO+zHxuS6PWq7YwbWNFgo<br />
7smNcko1yTp7f/VbS4CZ5kgIF9kCgNaiqdxq+v0IcphQHRR4xjfLpBQ4ckYOi4nC<br />
jqFR1BitwBL4K2JeE9PGUkkUBwvU4oOi9PGChuoxMXs8PwKi/dZTmSWM7kOfMiBw<br />
-----END RSA PRIVATE KEY-----<br />
<br />
Copy-paste that block to a separate file named '''client.key'''. <br />
<br />
== Linux and Mac ==<br />
<br />
* ~/.tqsl/certs/user contains the '''user certificate'''<br />
* ~/.tqsl/certs/authorities contains an '''intermediate certificate'''<br />
* ~/.tqsl/keys/YOURCALL contains, within some XML, your '''private key'''<br />
<br />
The user and intermediate certificates need to be concatenated to a single file named '''client.crt'''. The user certificate must be first, followed by the intermediate certificate. That can be done by a single command:<br />
<br />
cat ~/.tqsl/certs/user ~/.tqsl/certs/authorities > client.crt<br />
<br />
The private key needs to be extracted from the YOURCALL file. The file is a regular ASCII text file, and contains a block which looks something like this (just longer):<br />
<br />
-----BEGIN RSA PRIVATE KEY-----<br />
Proc-Type: 4,ENCRYPTED<br />
DEK-Info: DES-EDE3-CBC,0C7B5495F6A91F31<br />
<br />
0xmWfliK/v9U88MFyYtUbteRoAkfVMK6BllcdID3pZzmdykHaPLZUjXOCUh3vFUX<br />
1bjnYwXpLX/CxgZ6NIxQIk7jMjL3iaP5SkWzCswqi9mCO+zHxuS6PWq7YwbWNFgo<br />
7smNcko1yTp7f/VbS4CZ5kgIF9kCgNaiqdxq+v0IcphQHRR4xjfLpBQ4ckYOi4nC<br />
jqFR1BitwBL4K2JeE9PGUkkUBwvU4oOi9PGChuoxMXs8PwKi/dZTmSWM7kOfMiBw<br />
-----END RSA PRIVATE KEY-----<br />
<br />
Copy-paste that block to a separate file named '''client.key'''. If you're going to open up the original private key file in a text editor, it's a good idea to make a backup copy of that file first in case of an accidental corruption of its contents.<br />
<br />
= Configuring AMPRNet VPN =<br />
<br />
== Windows: OpenVPN ==<br />
<br />
# [http://openvpn.net/index.php/download/community-downloads.html Download the Windows Installer], it's free and open source.<br />
<br />
== Linux: OpenVPN ==<br />
<br />
== Mac OS X: Tunnelblick ==<br />
<br />
# [http://code.google.com/p/tunnelblick/ Download Tunnelblick], it's free and open source, and works like a charm. It's based on OpenVPN.<br />
# [http://he.fi/amprnet-vpn/amprnet-vpn-tblk.zip Download the AMPRNet VPN configuration for Tunnelblick], it's a zip file containing a directory with a couple files<br />
# Double-click the downloaded zip file to extract it, you'll get a directory named '''amprnet-vpn.tblk'''<br />
# Move the '''private key''' (in a file which was named '''client.key''' in the previous step) to that directory<br />
# Move the certificates (in a file which was named '''client.crt''' in the previous step) to that directory<br />
# Double-click the '''amprnet-vpn.tblk''' directory - this will launch Tunnelblick and install the VPN configuration<br />
<br />
You should now see a "tunnel" icon in the top right corner of the screen. Click it to see a few menu items allowing you to connect and disconnect the VPN.<br />
<br />
If you chose to encrypt your private key with a password (or passphrase) when initially applying for a LoTW certificate and generating the Certificate Request, Tunnelblick will ask you for that passphrase when connecting.<br />
<br />
To rephrase: When Tunnelblick says "A passphrase is required to connect to amprnet-vpn", the passphrase being asked is the one you picked when you first applied for a LoTW certificate. It's not something the VPN operator knows (or should know). Only you have ever been aware of that passphrase (hopefully).</div>Oh7lzbhttps://wiki.ampr.org/w/index.php?title=OH7LZB_VPN&diff=25OH7LZB VPN2013-05-07T21:18:50Z<p>Oh7lzb: /* Configuring AMPRNet VPN */</p>
<hr />
<div>AMPRNet VPN is an experimental method to access the AMPRNet using a VPN from anywhere on the Internet. The VPN is openly available to any amateur radio operators who have successfully applied for an X.509 certificate from one of the following Certificate Authorities:<br />
<br />
* ARRL Logbook of the World (LoTW)<br />
<br />
The CA validates using a relatively strong method that the operator is actually licensed, and gives the operator a certificate to prove that. Other services, such as the AMPRNet VPN can then check that the operator possesses a valid amateur radio operator certificate (and the accompanying private key), without any manual work being performed by the operators of those services.<br />
<br />
If and when other organisations start to give out X.509 certificates, after sufficient amateur radio license validation, the AMPRNet VPN can be configured to accept those in addition to the LoTW. If you're not willing to obtain a LoTW certificate, please set up a CA for your local club or association, document the method of license validation you're using, and I'll be happy to trust your certificates.<br />
<br />
The VPN operator does not have time to run a CA and validate licenses manually, so please don't ask for a certificate from anywhere else than the CAs listed above. Thanks!<br />
<br />
The AMPRNet VPN is only used to access the AMPRNet. While you're connected to the AMPRNet VPN, the VPN client will only transmit packets from you to the AMPRNet via the VPN. Packets from you to the rest of the Internet will not go via the VPN - they'll flow out from your local network connection as before. This is called a [http://en.wikipedia.org/wiki/Split_tunneling split tunnel VPN configuration].<br />
<br />
The setup is still a bit complicated - it can be made easier and more automatic with a little additional software in a later phase.<br />
<br />
= Extracting the certificate from LoTW =<br />
<br />
LoTW uses a custom file format (.TQ*) to exchange certificates, but after the LoTW certificate process is done and the TrustedQSL software has your certificates, they can be easily copied from TrustedQSL's directories. You'll need three files: your '''user certificate''', an '''intermediate certificate''' that was used to sign it, and your '''private key'''. The only secret piece of information is the private key - you should not reveal it to anyone at any point, as they could then use services on your behalf, using your callsign.<br />
<br />
== Windows ==<br />
<br />
... to be written ...<br />
<br />
== Linux and Mac ==<br />
<br />
* ~/.tqsl/certs/user contains the '''user certificate'''<br />
* ~/.tqsl/certs/authorities contains an '''intermediate certificate'''<br />
* ~/.tqsl/keys/YOURCALL contains, within some XML, your '''private key'''<br />
<br />
The user and intermediate certificates need to be concatenated to a single file named '''client.crt'''. The user certificate must be first, followed by the intermediate certificate. That can be done by a single command:<br />
<br />
cat ~/.tqsl/certs/user ~/.tqsl/certs/authorities > client.crt<br />
<br />
The private key needs to be extracted from the YOURCALL file. The file is a regular ASCII text file, and contains a block which looks something like this (just longer):<br />
<br />
-----BEGIN RSA PRIVATE KEY-----<br />
Proc-Type: 4,ENCRYPTED<br />
DEK-Info: DES-EDE3-CBC,0C7B5495F6A91F31<br />
<br />
0xmWfliK/v9U88MFyYtUbteRoAkfVMK6BllcdID3pZzmdykHaPLZUjXOCUh3vFUX<br />
1bjnYwXpLX/CxgZ6NIxQIk7jMjL3iaP5SkWzCswqi9mCO+zHxuS6PWq7YwbWNFgo<br />
7smNcko1yTp7f/VbS4CZ5kgIF9kCgNaiqdxq+v0IcphQHRR4xjfLpBQ4ckYOi4nC<br />
jqFR1BitwBL4K2JeE9PGUkkUBwvU4oOi9PGChuoxMXs8PwKi/dZTmSWM7kOfMiBw<br />
-----END RSA PRIVATE KEY-----<br />
<br />
Copy-paste that block to a separate file named '''client.key'''. If you're going to open up the original private key file in a text editor, it's a good idea to make a backup copy of that file first in case of an accidental corruption of its contents.<br />
<br />
= Configuring AMPRNet VPN =<br />
<br />
== Windows: OpenVPN ==<br />
<br />
# [http://openvpn.net/index.php/download/community-downloads.html Download the Windows Installer], it's free and open source.<br />
<br />
== Linux: OpenVPN ==<br />
<br />
== Mac OS X: Tunnelblick ==<br />
<br />
# [http://code.google.com/p/tunnelblick/ Download Tunnelblick], it's free and open source, and works like a charm. It's based on OpenVPN.<br />
# [http://he.fi/amprnet-vpn/amprnet-vpn-tblk.zip Download the AMPRNet VPN configuration for Tunnelblick], it's a zip file containing a directory with a couple files<br />
# Double-click the downloaded zip file to extract it, you'll get a directory named '''amprnet-vpn.tblk'''<br />
# Move the '''private key''' (in a file which was named '''client.key''' in the previous step) to that directory<br />
# Move the certificates (in a file which was named '''client.crt''' in the previous step) to that directory<br />
# Double-click the '''amprnet-vpn.tblk''' directory - this will launch Tunnelblick and install the VPN configuration<br />
<br />
You should now see a "tunnel" icon in the top right corner of the screen. Click it to see a few menu items allowing you to connect and disconnect the VPN.<br />
<br />
If you chose to encrypt your private key with a password (or passphrase) when initially applying for a LoTW certificate and generating the Certificate Request, Tunnelblick will ask you for that passphrase when connecting.<br />
<br />
To rephrase: When Tunnelblick says "A passphrase is required to connect to amprnet-vpn", the passphrase being asked is the one you picked when you first applied for a LoTW certificate. It's not something the VPN operator knows (or should know). Only you have ever been aware of that passphrase (hopefully).</div>Oh7lzbhttps://wiki.ampr.org/w/index.php?title=OH7LZB_VPN&diff=24OH7LZB VPN2013-05-07T21:11:10Z<p>Oh7lzb: /* Linux and Mac */</p>
<hr />
<div>AMPRNet VPN is an experimental method to access the AMPRNet using a VPN from anywhere on the Internet. The VPN is openly available to any amateur radio operators who have successfully applied for an X.509 certificate from one of the following Certificate Authorities:<br />
<br />
* ARRL Logbook of the World (LoTW)<br />
<br />
The CA validates using a relatively strong method that the operator is actually licensed, and gives the operator a certificate to prove that. Other services, such as the AMPRNet VPN can then check that the operator possesses a valid amateur radio operator certificate (and the accompanying private key), without any manual work being performed by the operators of those services.<br />
<br />
If and when other organisations start to give out X.509 certificates, after sufficient amateur radio license validation, the AMPRNet VPN can be configured to accept those in addition to the LoTW. If you're not willing to obtain a LoTW certificate, please set up a CA for your local club or association, document the method of license validation you're using, and I'll be happy to trust your certificates.<br />
<br />
The VPN operator does not have time to run a CA and validate licenses manually, so please don't ask for a certificate from anywhere else than the CAs listed above. Thanks!<br />
<br />
The AMPRNet VPN is only used to access the AMPRNet. While you're connected to the AMPRNet VPN, the VPN client will only transmit packets from you to the AMPRNet via the VPN. Packets from you to the rest of the Internet will not go via the VPN - they'll flow out from your local network connection as before. This is called a [http://en.wikipedia.org/wiki/Split_tunneling split tunnel VPN configuration].<br />
<br />
The setup is still a bit complicated - it can be made easier and more automatic with a little additional software in a later phase.<br />
<br />
= Extracting the certificate from LoTW =<br />
<br />
LoTW uses a custom file format (.TQ*) to exchange certificates, but after the LoTW certificate process is done and the TrustedQSL software has your certificates, they can be easily copied from TrustedQSL's directories. You'll need three files: your '''user certificate''', an '''intermediate certificate''' that was used to sign it, and your '''private key'''. The only secret piece of information is the private key - you should not reveal it to anyone at any point, as they could then use services on your behalf, using your callsign.<br />
<br />
== Windows ==<br />
<br />
... to be written ...<br />
<br />
== Linux and Mac ==<br />
<br />
* ~/.tqsl/certs/user contains the '''user certificate'''<br />
* ~/.tqsl/certs/authorities contains an '''intermediate certificate'''<br />
* ~/.tqsl/keys/YOURCALL contains, within some XML, your '''private key'''<br />
<br />
The user and intermediate certificates need to be concatenated to a single file named '''client.crt'''. The user certificate must be first, followed by the intermediate certificate. That can be done by a single command:<br />
<br />
cat ~/.tqsl/certs/user ~/.tqsl/certs/authorities > client.crt<br />
<br />
The private key needs to be extracted from the YOURCALL file. The file is a regular ASCII text file, and contains a block which looks something like this (just longer):<br />
<br />
-----BEGIN RSA PRIVATE KEY-----<br />
Proc-Type: 4,ENCRYPTED<br />
DEK-Info: DES-EDE3-CBC,0C7B5495F6A91F31<br />
<br />
0xmWfliK/v9U88MFyYtUbteRoAkfVMK6BllcdID3pZzmdykHaPLZUjXOCUh3vFUX<br />
1bjnYwXpLX/CxgZ6NIxQIk7jMjL3iaP5SkWzCswqi9mCO+zHxuS6PWq7YwbWNFgo<br />
7smNcko1yTp7f/VbS4CZ5kgIF9kCgNaiqdxq+v0IcphQHRR4xjfLpBQ4ckYOi4nC<br />
jqFR1BitwBL4K2JeE9PGUkkUBwvU4oOi9PGChuoxMXs8PwKi/dZTmSWM7kOfMiBw<br />
-----END RSA PRIVATE KEY-----<br />
<br />
Copy-paste that block to a separate file named '''client.key'''. If you're going to open up the original private key file in a text editor, it's a good idea to make a backup copy of that file first in case of an accidental corruption of its contents.<br />
<br />
= Configuring AMPRNet VPN =<br />
<br />
== Windows: OpenVPN ==<br />
<br />
== Linux: OpenVPN ==<br />
<br />
== Mac OS X: Tunnelblick ==<br />
<br />
# [http://code.google.com/p/tunnelblick/ Download Tunnelblick], it's free and open source, and works like a charm. It's based on OpenVPN.<br />
# [http://he.fi/amprnet-vpn/amprnet-vpn-tblk.zip Download the AMPRNet VPN configuration for Tunnelblick], it's a zip file containing a directory with a couple files<br />
# Double-click the downloaded zip file to extract it, you'll get a directory named '''amprnet-vpn.tblk'''<br />
# Move the '''private key''' (in a file which was named '''client.key''' in the previous step) to that directory<br />
# Move the certificates (in a file which was named '''client.crt''' in the previous step) to that directory<br />
# Double-click the '''amprnet-vpn.tblk''' directory - this will launch Tunnelblick and install the VPN configuration<br />
<br />
You should now see a "tunnel" icon in the top right corner of the screen. Click it to see a few menu items allowing you to connect and disconnect the VPN.<br />
<br />
If you chose to encrypt your private key with a passphrase (or password) when initially applying for a LoTW certificate, Tunnelblick will ask you for that passphrase when connecting.<br />
<br />
To rephrase: When Tunnelblick says "A passphrase is required to connect to amprnet-vpn", the passphrase being asked is the one you picked when you first applied for a LoTW certificate. It's not something the VPN operator knows (or should know). Only you have ever been aware of that passphrase (hopefully).</div>Oh7lzbhttps://wiki.ampr.org/w/index.php?title=OH7LZB_VPN&diff=23OH7LZB VPN2013-05-07T21:08:12Z<p>Oh7lzb: </p>
<hr />
<div>AMPRNet VPN is an experimental method to access the AMPRNet using a VPN from anywhere on the Internet. The VPN is openly available to any amateur radio operators who have successfully applied for an X.509 certificate from one of the following Certificate Authorities:<br />
<br />
* ARRL Logbook of the World (LoTW)<br />
<br />
The CA validates using a relatively strong method that the operator is actually licensed, and gives the operator a certificate to prove that. Other services, such as the AMPRNet VPN can then check that the operator possesses a valid amateur radio operator certificate (and the accompanying private key), without any manual work being performed by the operators of those services.<br />
<br />
If and when other organisations start to give out X.509 certificates, after sufficient amateur radio license validation, the AMPRNet VPN can be configured to accept those in addition to the LoTW. If you're not willing to obtain a LoTW certificate, please set up a CA for your local club or association, document the method of license validation you're using, and I'll be happy to trust your certificates.<br />
<br />
The VPN operator does not have time to run a CA and validate licenses manually, so please don't ask for a certificate from anywhere else than the CAs listed above. Thanks!<br />
<br />
The AMPRNet VPN is only used to access the AMPRNet. While you're connected to the AMPRNet VPN, the VPN client will only transmit packets from you to the AMPRNet via the VPN. Packets from you to the rest of the Internet will not go via the VPN - they'll flow out from your local network connection as before. This is called a [http://en.wikipedia.org/wiki/Split_tunneling split tunnel VPN configuration].<br />
<br />
The setup is still a bit complicated - it can be made easier and more automatic with a little additional software in a later phase.<br />
<br />
= Extracting the certificate from LoTW =<br />
<br />
LoTW uses a custom file format (.TQ*) to exchange certificates, but after the LoTW certificate process is done and the TrustedQSL software has your certificates, they can be easily copied from TrustedQSL's directories. You'll need three files: your '''user certificate''', an '''intermediate certificate''' that was used to sign it, and your '''private key'''. The only secret piece of information is the private key - you should not reveal it to anyone at any point, as they could then use services on your behalf, using your callsign.<br />
<br />
== Windows ==<br />
<br />
... to be written ...<br />
<br />
== Linux and Mac ==<br />
<br />
* ~/.tqsl/certs/user contains the '''user certificate'''<br />
* ~/.tqsl/certs/authorities contains an '''intermediate certificate'''<br />
* ~/.tqsl/keys/YOURCALL contains, within some XML, your '''private key'''<br />
<br />
The user and intermediate certificates need to be concatenated to a single file named '''client.crt'''. That can be done by a single command:<br />
<br />
cat ~/.tqsl/certs/user ~/.tqsl/certs/authorities > client.crt<br />
<br />
The private key needs to be extracted from the YOURCALL file. The file is a regular ASCII text file, and contains a block which looks something like this (just longer):<br />
<br />
-----BEGIN RSA PRIVATE KEY-----<br />
Proc-Type: 4,ENCRYPTED<br />
DEK-Info: DES-EDE3-CBC,0C7B5495F6A91F31<br />
<br />
0xmWfliK/v9U88MFyYtUbteRoAkfVMK6BllcdID3pZzmdykHaPLZUjXOCUh3vFUX<br />
1bjnYwXpLX/CxgZ6NIxQIk7jMjL3iaP5SkWzCswqi9mCO+zHxuS6PWq7YwbWNFgo<br />
7smNcko1yTp7f/VbS4CZ5kgIF9kCgNaiqdxq+v0IcphQHRR4xjfLpBQ4ckYOi4nC<br />
jqFR1BitwBL4K2JeE9PGUkkUBwvU4oOi9PGChuoxMXs8PwKi/dZTmSWM7kOfMiBw<br />
-----END RSA PRIVATE KEY-----<br />
<br />
Copy-paste that block to a separate file named '''client.key'''. If you're going to open up the original private key file in a text editor, it's a good idea to make a backup copy of that file first in case of an accidental corruption of its contents.<br />
<br />
= Configuring AMPRNet VPN =<br />
<br />
== Windows: OpenVPN ==<br />
<br />
== Linux: OpenVPN ==<br />
<br />
== Mac OS X: Tunnelblick ==<br />
<br />
# [http://code.google.com/p/tunnelblick/ Download Tunnelblick], it's free and open source, and works like a charm. It's based on OpenVPN.<br />
# [http://he.fi/amprnet-vpn/amprnet-vpn-tblk.zip Download the AMPRNet VPN configuration for Tunnelblick], it's a zip file containing a directory with a couple files<br />
# Double-click the downloaded zip file to extract it, you'll get a directory named '''amprnet-vpn.tblk'''<br />
# Move the '''private key''' (in a file which was named '''client.key''' in the previous step) to that directory<br />
# Move the certificates (in a file which was named '''client.crt''' in the previous step) to that directory<br />
# Double-click the '''amprnet-vpn.tblk''' directory - this will launch Tunnelblick and install the VPN configuration<br />
<br />
You should now see a "tunnel" icon in the top right corner of the screen. Click it to see a few menu items allowing you to connect and disconnect the VPN.<br />
<br />
If you chose to encrypt your private key with a passphrase (or password) when initially applying for a LoTW certificate, Tunnelblick will ask you for that passphrase when connecting.<br />
<br />
To rephrase: When Tunnelblick says "A passphrase is required to connect to amprnet-vpn", the passphrase being asked is the one you picked when you first applied for a LoTW certificate. It's not something the VPN operator knows (or should know). Only you have ever been aware of that passphrase (hopefully).</div>Oh7lzbhttps://wiki.ampr.org/w/index.php?title=OH7LZB_VPN&diff=22OH7LZB VPN2013-05-07T20:58:54Z<p>Oh7lzb: /* Mac OS X: Tunnelblick */</p>
<hr />
<div>AMPRNet VPN is an experimental method to access the AMPRNet using a VPN from anywhere on the Internet. The VPN is openly available to any amateur radio operators who have successfully applied for an X.509 certificate from one of the following Certificate Authorities:<br />
<br />
* ARRL Logbook of the World (LoTW)<br />
<br />
The CA validates using a relatively strong method that the operator is actually licensed, and gives the operator a certificate to prove that. Other services, such as the AMPRNet VPN can then check that the operator possesses a valid amateur radio operator certificate (and the accompanying private key), without any manual work being performed by the operators of those services.<br />
<br />
If and when other organisations start to give out X.509 certificates, after sufficient amateur radio license validation, the AMPRNet VPN can be configured to accept those in addition to the LoTW. If you're not willing to obtain a LoTW certificate, please set up a CA for your local club or association, document the method of license validation you're using, and I'll be happy to trust your certificates.<br />
<br />
The VPN operator does not have time to run a CA and validate licenses manually, so please don't ask for a certificate from anywhere else than the CAs listed above. Thanks!<br />
<br />
The setup is still a bit complicated - it can be made easier and more automatic with a little additional software in a later phase.<br />
<br />
= Extracting the certificate from LoTW =<br />
<br />
LoTW uses a custom file format (.TQ*) to exchange certificates, but after the LoTW certificate process is done and the TrustedQSL software has your certificates, they can be easily copied from TrustedQSL's directories. You'll need three files: your '''user certificate''', an '''intermediate certificate''' that was used to sign it, and your '''private key'''. The only secret piece of information is the private key - you should not reveal it to anyone at any point, as they could then use services on your behalf, using your callsign.<br />
<br />
== Windows ==<br />
<br />
... to be written ...<br />
<br />
== Linux and Mac ==<br />
<br />
* ~/.tqsl/certs/user contains the '''user certificate'''<br />
* ~/.tqsl/certs/authorities contains an '''intermediate certificate'''<br />
* ~/.tqsl/keys/YOURCALL contains, within some XML, your '''private key'''<br />
<br />
The user and intermediate certificates need to be concatenated to a single file named '''client.crt'''. That can be done by a single command:<br />
<br />
cat ~/.tqsl/certs/user ~/.tqsl/certs/authorities > client.crt<br />
<br />
The private key needs to be extracted from the YOURCALL file. The file is a regular ASCII text file, and contains a block which looks something like this (just longer):<br />
<br />
-----BEGIN RSA PRIVATE KEY-----<br />
Proc-Type: 4,ENCRYPTED<br />
DEK-Info: DES-EDE3-CBC,0C7B5495F6A91F31<br />
<br />
0xmWfliK/v9U88MFyYtUbteRoAkfVMK6BllcdID3pZzmdykHaPLZUjXOCUh3vFUX<br />
1bjnYwXpLX/CxgZ6NIxQIk7jMjL3iaP5SkWzCswqi9mCO+zHxuS6PWq7YwbWNFgo<br />
7smNcko1yTp7f/VbS4CZ5kgIF9kCgNaiqdxq+v0IcphQHRR4xjfLpBQ4ckYOi4nC<br />
jqFR1BitwBL4K2JeE9PGUkkUBwvU4oOi9PGChuoxMXs8PwKi/dZTmSWM7kOfMiBw<br />
-----END RSA PRIVATE KEY-----<br />
<br />
Copy-paste that block to a separate file named '''client.key'''. If you're going to open up the original private key file in a text editor, it's a good idea to make a backup copy of that file first in case of an accidental corruption of its contents.<br />
<br />
= Configuring AMPRNet VPN =<br />
<br />
== Windows: OpenVPN ==<br />
<br />
== Linux: OpenVPN ==<br />
<br />
== Mac OS X: Tunnelblick ==<br />
<br />
# [http://code.google.com/p/tunnelblick/ Download Tunnelblick], it's free and open source, and works like a charm. It's based on OpenVPN.<br />
# [http://he.fi/amprnet-vpn/amprnet-vpn-tblk.zip Download the AMPRNet VPN configuration for Tunnelblick], it's a zip file containing a directory with a couple files<br />
# Double-click the downloaded zip file to extract it, you'll get a directory named '''amprnet-vpn.tblk'''<br />
# Move the '''private key''' (in a file which was named '''client.key''' in the previous step) to that directory<br />
# Move the certificates (in a file which was named '''client.crt''' in the previous step) to that directory<br />
# Double-click the '''amprnet-vpn.tblk''' directory - this will launch Tunnelblick and install the VPN configuration<br />
<br />
You should now see a "tunnel" icon in the top right corner of the screen. Click it to see a few menu items allowing you to connect and disconnect the VPN.<br />
<br />
If you chose to encrypt your private key with a passphrase (or password) when initially applying for a LoTW certificate, Tunnelblick will ask you for that passphrase when connecting.<br />
<br />
To rephrase: When Tunnelblick says "A passphrase is required to connect to amprnet-vpn", the passphrase being asked is the one you picked when you first applied for a LoTW certificate. It's not something the VPN operator knows (or should know). Only you have ever been aware of that passphrase (hopefully).</div>Oh7lzbhttps://wiki.ampr.org/w/index.php?title=OH7LZB_VPN&diff=21OH7LZB VPN2013-05-07T20:46:33Z<p>Oh7lzb: /* Extracting the certificate from LoTW */</p>
<hr />
<div>AMPRNet VPN is an experimental method to access the AMPRNet using a VPN from anywhere on the Internet. The VPN is openly available to any amateur radio operators who have successfully applied for an X.509 certificate from one of the following Certificate Authorities:<br />
<br />
* ARRL Logbook of the World (LoTW)<br />
<br />
The CA validates using a relatively strong method that the operator is actually licensed, and gives the operator a certificate to prove that. Other services, such as the AMPRNet VPN can then check that the operator possesses a valid amateur radio operator certificate (and the accompanying private key), without any manual work being performed by the operators of those services.<br />
<br />
If and when other organisations start to give out X.509 certificates, after sufficient amateur radio license validation, the AMPRNet VPN can be configured to accept those in addition to the LoTW. If you're not willing to obtain a LoTW certificate, please set up a CA for your local club or association, document the method of license validation you're using, and I'll be happy to trust your certificates.<br />
<br />
The VPN operator does not have time to run a CA and validate licenses manually, so please don't ask for a certificate from anywhere else than the CAs listed above. Thanks!<br />
<br />
The setup is still a bit complicated - it can be made easier and more automatic with a little additional software in a later phase.<br />
<br />
= Extracting the certificate from LoTW =<br />
<br />
LoTW uses a custom file format (.TQ*) to exchange certificates, but after the LoTW certificate process is done and the TrustedQSL software has your certificates, they can be easily copied from TrustedQSL's directories. You'll need three files: your '''user certificate''', an '''intermediate certificate''' that was used to sign it, and your '''private key'''. The only secret piece of information is the private key - you should not reveal it to anyone at any point, as they could then use services on your behalf, using your callsign.<br />
<br />
== Windows ==<br />
<br />
... to be written ...<br />
<br />
== Linux and Mac ==<br />
<br />
* ~/.tqsl/certs/user contains the '''user certificate'''<br />
* ~/.tqsl/certs/authorities contains an '''intermediate certificate'''<br />
* ~/.tqsl/keys/YOURCALL contains, within some XML, your '''private key'''<br />
<br />
The user and intermediate certificates need to be concatenated to a single file named '''client.crt'''. That can be done by a single command:<br />
<br />
cat ~/.tqsl/certs/user ~/.tqsl/certs/authorities > client.crt<br />
<br />
The private key needs to be extracted from the YOURCALL file. The file is a regular ASCII text file, and contains a block which looks something like this (just longer):<br />
<br />
-----BEGIN RSA PRIVATE KEY-----<br />
Proc-Type: 4,ENCRYPTED<br />
DEK-Info: DES-EDE3-CBC,0C7B5495F6A91F31<br />
<br />
0xmWfliK/v9U88MFyYtUbteRoAkfVMK6BllcdID3pZzmdykHaPLZUjXOCUh3vFUX<br />
1bjnYwXpLX/CxgZ6NIxQIk7jMjL3iaP5SkWzCswqi9mCO+zHxuS6PWq7YwbWNFgo<br />
7smNcko1yTp7f/VbS4CZ5kgIF9kCgNaiqdxq+v0IcphQHRR4xjfLpBQ4ckYOi4nC<br />
jqFR1BitwBL4K2JeE9PGUkkUBwvU4oOi9PGChuoxMXs8PwKi/dZTmSWM7kOfMiBw<br />
-----END RSA PRIVATE KEY-----<br />
<br />
Copy-paste that block to a separate file named '''client.key'''. If you're going to open up the original private key file in a text editor, it's a good idea to make a backup copy of that file first in case of an accidental corruption of its contents.<br />
<br />
= Configuring AMPRNet VPN =<br />
<br />
== Windows: OpenVPN ==<br />
<br />
== Linux: OpenVPN ==<br />
<br />
== Mac OS X: Tunnelblick ==<br />
<br />
# [http://code.google.com/p/tunnelblick/ Download Tunnelblick], it's free and open source, and works like a charm. It's based on OpenVPN.<br />
# [http://he.fi/amprnet-vpn/amprnet-vpn-tblk.zip Download the AMPRNet VPN configuration for Tunnelblick], it's a zip file containing a directory with a couple files<br />
# Double-click the downloaded zip file to extract it, you'll get a directory named '''amprnet-vpn.tblk'''<br />
# Move the '''private key''' (in a file which was named '''client.key''' in the previous step) to that directory<br />
# Move the certificates (in a file which was named '''client.crt''' in the previous step) to that directory<br />
# Double-click the '''amprnet-vpn.tblk''' directory - this will launch Tunnelblick and install the VPN configuration<br />
<br />
You should now see a "tunnel" icon in the top right corner of the screen. Click it to see a few menu items allowing you to connect and disconnect the VPN.</div>Oh7lzbhttps://wiki.ampr.org/w/index.php?title=OH7LZB_VPN&diff=20OH7LZB VPN2013-05-07T20:45:34Z<p>Oh7lzb: </p>
<hr />
<div>AMPRNet VPN is an experimental method to access the AMPRNet using a VPN from anywhere on the Internet. The VPN is openly available to any amateur radio operators who have successfully applied for an X.509 certificate from one of the following Certificate Authorities:<br />
<br />
* ARRL Logbook of the World (LoTW)<br />
<br />
The CA validates using a relatively strong method that the operator is actually licensed, and gives the operator a certificate to prove that. Other services, such as the AMPRNet VPN can then check that the operator possesses a valid amateur radio operator certificate (and the accompanying private key), without any manual work being performed by the operators of those services.<br />
<br />
If and when other organisations start to give out X.509 certificates, after sufficient amateur radio license validation, the AMPRNet VPN can be configured to accept those in addition to the LoTW. If you're not willing to obtain a LoTW certificate, please set up a CA for your local club or association, document the method of license validation you're using, and I'll be happy to trust your certificates.<br />
<br />
The VPN operator does not have time to run a CA and validate licenses manually, so please don't ask for a certificate from anywhere else than the CAs listed above. Thanks!<br />
<br />
The setup is still a bit complicated - it can be made easier and more automatic with a little additional software in a later phase.<br />
<br />
= Extracting the certificate from LoTW =<br />
<br />
LoTW uses a custom file format (.TQ*) to exchange certificates, but after the LoTW certificate process is done and the TrustedQSL software has your certificates, they can be easily copied from TrustedQSL's directories. You'll need three files: your '''user certificate''', an '''intermediate certificate''' that was used to sign it, and your '''private key'''. The only secret piece of information is the private key - you should not reveal it to anyone at any point, as they could then use services on your behalf, using your callsign.<br />
<br />
== Linux and Mac ==<br />
<br />
* ~/.tqsl/certs/user contains the '''user certificate'''<br />
* ~/.tqsl/certs/authorities contains an '''intermediate certificate'''<br />
* ~/.tqsl/keys/YOURCALL contains, within some XML, your '''private key'''<br />
<br />
The user and intermediate certificates need to be concatenated to a single file named '''client.crt'''. That can be done by a single command:<br />
<br />
cat ~/.tqsl/certs/user ~/.tqsl/certs/authorities > client.crt<br />
<br />
The private key needs to be extracted from the YOURCALL file. The file is a regular ASCII text file, and contains a block which looks something like this (just longer):<br />
<br />
-----BEGIN RSA PRIVATE KEY-----<br />
Proc-Type: 4,ENCRYPTED<br />
DEK-Info: DES-EDE3-CBC,0C7B5495F6A91F31<br />
<br />
0xmWfliK/v9U88MFyYtUbteRoAkfVMK6BllcdID3pZzmdykHaPLZUjXOCUh3vFUX<br />
1bjnYwXpLX/CxgZ6NIxQIk7jMjL3iaP5SkWzCswqi9mCO+zHxuS6PWq7YwbWNFgo<br />
7smNcko1yTp7f/VbS4CZ5kgIF9kCgNaiqdxq+v0IcphQHRR4xjfLpBQ4ckYOi4nC<br />
jqFR1BitwBL4K2JeE9PGUkkUBwvU4oOi9PGChuoxMXs8PwKi/dZTmSWM7kOfMiBw<br />
-----END RSA PRIVATE KEY-----<br />
<br />
Copy-paste that block to a separate file named '''client.key'''. If you're going to open up the original private key file in a text editor, it's a good idea to make a backup copy of that file first in case of an accidental corruption of its contents.<br />
<br />
= Configuring AMPRNet VPN =<br />
<br />
== Windows: OpenVPN ==<br />
<br />
== Linux: OpenVPN ==<br />
<br />
== Mac OS X: Tunnelblick ==<br />
<br />
# [http://code.google.com/p/tunnelblick/ Download Tunnelblick], it's free and open source, and works like a charm. It's based on OpenVPN.<br />
# [http://he.fi/amprnet-vpn/amprnet-vpn-tblk.zip Download the AMPRNet VPN configuration for Tunnelblick], it's a zip file containing a directory with a couple files<br />
# Double-click the downloaded zip file to extract it, you'll get a directory named '''amprnet-vpn.tblk'''<br />
# Move the '''private key''' (in a file which was named '''client.key''' in the previous step) to that directory<br />
# Move the certificates (in a file which was named '''client.crt''' in the previous step) to that directory<br />
# Double-click the '''amprnet-vpn.tblk''' directory - this will launch Tunnelblick and install the VPN configuration<br />
<br />
You should now see a "tunnel" icon in the top right corner of the screen. Click it to see a few menu items allowing you to connect and disconnect the VPN.</div>Oh7lzbhttps://wiki.ampr.org/w/index.php?title=OH7LZB_VPN&diff=19OH7LZB VPN2013-05-07T20:44:05Z<p>Oh7lzb: /* Mac OS X: Tunnelblick */</p>
<hr />
<div>AMPRNet VPN is an experimental method to access the AMPRNet using a VPN from anywhere on the Internet. The VPN is openly available to any amateur radio operators who have successfully applied for an X.509 certificate from one of the following Certificate Authorities:<br />
<br />
* ARRL Logbook of the World (LoTW)<br />
<br />
The CA validates using a relatively strong method that the operator is actually licensed, and gives the operator a certificate to prove that. Other services, such as the AMPRNet VPN can then check that the operator possesses a valid amateur radio operator certificate (and the accompanying private key), without any manual work being performed by the operators of those services.<br />
<br />
If and when other organisations start to give out X.509 certificates, after sufficient amateur radio license validation, the AMPRNet VPN can be configured to accept those in addition to the LoTW. If you're not willing to obtain a LoTW certificate, please set up a CA for your local club or association, document the method of license validation you're using, and I'll be happy to trust your certificates.<br />
<br />
The VPN operator does not have time to run a CA and validate licenses manually, so please don't ask for a certificate from anywhere else than the CAs listed above. Thanks!<br />
<br />
= Extracting the certificate from LoTW =<br />
<br />
LoTW uses a custom file format (.TQ*) to exchange certificates, but after the LoTW certificate process is done and the TrustedQSL software has your certificates, they can be easily copied from TrustedQSL's directories. You'll need three files: your '''user certificate''', an '''intermediate certificate''' that was used to sign it, and your '''private key'''. The only secret piece of information is the private key - you should not reveal it to anyone at any point, as they could then use services on your behalf, using your callsign.<br />
<br />
== Linux and Mac ==<br />
<br />
* ~/.tqsl/certs/user contains the '''user certificate'''<br />
* ~/.tqsl/certs/authorities contains an '''intermediate certificate'''<br />
* ~/.tqsl/keys/YOURCALL contains, within some XML, your '''private key'''<br />
<br />
The user and intermediate certificates need to be concatenated to a single file named '''client.crt'''. That can be done by a single command:<br />
<br />
cat ~/.tqsl/certs/user ~/.tqsl/certs/authorities > client.crt<br />
<br />
The private key needs to be extracted from the YOURCALL file. The file is a regular ASCII text file, and contains a block which looks something like this (just longer):<br />
<br />
-----BEGIN RSA PRIVATE KEY-----<br />
Proc-Type: 4,ENCRYPTED<br />
DEK-Info: DES-EDE3-CBC,0C7B5495F6A91F31<br />
<br />
0xmWfliK/v9U88MFyYtUbteRoAkfVMK6BllcdID3pZzmdykHaPLZUjXOCUh3vFUX<br />
1bjnYwXpLX/CxgZ6NIxQIk7jMjL3iaP5SkWzCswqi9mCO+zHxuS6PWq7YwbWNFgo<br />
7smNcko1yTp7f/VbS4CZ5kgIF9kCgNaiqdxq+v0IcphQHRR4xjfLpBQ4ckYOi4nC<br />
jqFR1BitwBL4K2JeE9PGUkkUBwvU4oOi9PGChuoxMXs8PwKi/dZTmSWM7kOfMiBw<br />
-----END RSA PRIVATE KEY-----<br />
<br />
Copy-paste that block to a separate file named '''client.key'''. If you're going to open up the original private key file in a text editor, it's a good idea to make a backup copy of that file first in case of an accidental corruption of its contents.<br />
<br />
= Configuring AMPRNet VPN =<br />
<br />
== Windows: OpenVPN ==<br />
<br />
== Linux: OpenVPN ==<br />
<br />
== Mac OS X: Tunnelblick ==<br />
<br />
# [http://code.google.com/p/tunnelblick/ Download Tunnelblick], it's free and open source, and works like a charm. It's based on OpenVPN.<br />
# [http://he.fi/amprnet-vpn/amprnet-vpn-tblk.zip Download the AMPRNet VPN configuration for Tunnelblick], it's a zip file containing a directory with a couple files<br />
# Double-click the downloaded zip file to extract it, you'll get a directory named '''amprnet-vpn.tblk'''<br />
# Move the '''private key''' (in a file which was named '''client.key''' in the previous step) to that directory<br />
# Move the certificates (in a file which was named '''client.crt''' in the previous step) to that directory<br />
# Double-click the '''amprnet-vpn.tblk''' directory - this will launch Tunnelblick and install the VPN configuration<br />
<br />
You should now see a "tunnel" icon in the top right corner of the screen. Click it to see a few menu items allowing you to connect and disconnect the VPN.</div>Oh7lzbhttps://wiki.ampr.org/w/index.php?title=OH7LZB_VPN&diff=18OH7LZB VPN2013-05-07T20:36:25Z<p>Oh7lzb: /* Extracting the certificate from LoTW */</p>
<hr />
<div>AMPRNet VPN is an experimental method to access the AMPRNet using a VPN from anywhere on the Internet. The VPN is openly available to any amateur radio operators who have successfully applied for an X.509 certificate from one of the following Certificate Authorities:<br />
<br />
* ARRL Logbook of the World (LoTW)<br />
<br />
The CA validates using a relatively strong method that the operator is actually licensed, and gives the operator a certificate to prove that. Other services, such as the AMPRNet VPN can then check that the operator possesses a valid amateur radio operator certificate (and the accompanying private key), without any manual work being performed by the operators of those services.<br />
<br />
If and when other organisations start to give out X.509 certificates, after sufficient amateur radio license validation, the AMPRNet VPN can be configured to accept those in addition to the LoTW. If you're not willing to obtain a LoTW certificate, please set up a CA for your local club or association, document the method of license validation you're using, and I'll be happy to trust your certificates.<br />
<br />
The VPN operator does not have time to run a CA and validate licenses manually, so please don't ask for a certificate from anywhere else than the CAs listed above. Thanks!<br />
<br />
= Extracting the certificate from LoTW =<br />
<br />
LoTW uses a custom file format (.TQ*) to exchange certificates, but after the LoTW certificate process is done and the TrustedQSL software has your certificates, they can be easily copied from TrustedQSL's directories. You'll need three files: your '''user certificate''', an '''intermediate certificate''' that was used to sign it, and your '''private key'''. The only secret piece of information is the private key - you should not reveal it to anyone at any point, as they could then use services on your behalf, using your callsign.<br />
<br />
== Linux and Mac ==<br />
<br />
* ~/.tqsl/certs/user contains the '''user certificate'''<br />
* ~/.tqsl/certs/authorities contains an '''intermediate certificate'''<br />
* ~/.tqsl/keys/YOURCALL contains, within some XML, your '''private key'''<br />
<br />
The user and intermediate certificates need to be concatenated to a single file named '''client.crt'''. That can be done by a single command:<br />
<br />
cat ~/.tqsl/certs/user ~/.tqsl/certs/authorities > client.crt<br />
<br />
The private key needs to be extracted from the YOURCALL file. The file is a regular ASCII text file, and contains a block which looks something like this (just longer):<br />
<br />
-----BEGIN RSA PRIVATE KEY-----<br />
Proc-Type: 4,ENCRYPTED<br />
DEK-Info: DES-EDE3-CBC,0C7B5495F6A91F31<br />
<br />
0xmWfliK/v9U88MFyYtUbteRoAkfVMK6BllcdID3pZzmdykHaPLZUjXOCUh3vFUX<br />
1bjnYwXpLX/CxgZ6NIxQIk7jMjL3iaP5SkWzCswqi9mCO+zHxuS6PWq7YwbWNFgo<br />
7smNcko1yTp7f/VbS4CZ5kgIF9kCgNaiqdxq+v0IcphQHRR4xjfLpBQ4ckYOi4nC<br />
jqFR1BitwBL4K2JeE9PGUkkUBwvU4oOi9PGChuoxMXs8PwKi/dZTmSWM7kOfMiBw<br />
-----END RSA PRIVATE KEY-----<br />
<br />
Copy-paste that block to a separate file named '''client.key'''. If you're going to open up the original private key file in a text editor, it's a good idea to make a backup copy of that file first in case of an accidental corruption of its contents.<br />
<br />
= Configuring AMPRNet VPN =<br />
<br />
== Windows: OpenVPN ==<br />
<br />
== Linux: OpenVPN ==<br />
<br />
== Mac OS X: Tunnelblick ==</div>Oh7lzbhttps://wiki.ampr.org/w/index.php?title=OH7LZB_VPN&diff=17OH7LZB VPN2013-05-07T20:31:18Z<p>Oh7lzb: /* Extracting the certificate from LoTW */</p>
<hr />
<div>AMPRNet VPN is an experimental method to access the AMPRNet using a VPN from anywhere on the Internet. The VPN is openly available to any amateur radio operators who have successfully applied for an X.509 certificate from one of the following Certificate Authorities:<br />
<br />
* ARRL Logbook of the World (LoTW)<br />
<br />
The CA validates using a relatively strong method that the operator is actually licensed, and gives the operator a certificate to prove that. Other services, such as the AMPRNet VPN can then check that the operator possesses a valid amateur radio operator certificate (and the accompanying private key), without any manual work being performed by the operators of those services.<br />
<br />
If and when other organisations start to give out X.509 certificates, after sufficient amateur radio license validation, the AMPRNet VPN can be configured to accept those in addition to the LoTW. If you're not willing to obtain a LoTW certificate, please set up a CA for your local club or association, document the method of license validation you're using, and I'll be happy to trust your certificates.<br />
<br />
The VPN operator does not have time to run a CA and validate licenses manually, so please don't ask for a certificate from anywhere else than the CAs listed above. Thanks!<br />
<br />
= Extracting the certificate from LoTW =<br />
<br />
LoTW uses a custom file format (.TQ*) to exchange certificates, but after the LoTW certificate process is done and TrustedQSL has your certificates, they can be easily copied from TrustedQSL's directories. You'll need three files:<br />
<br />
Linux and Mac:<br />
<br />
* ~/.tqsl/certs/user contains the '''user certificate'''<br />
* ~/.tqsl/certs/authorities contains an '''intermediate certificate'''<br />
* ~/.tqsl/keys/YOURCALL contains, within some XML, your '''private key'''<br />
<br />
The user and intermediate certificates need to be concatenated to a single file named '''client.crt'''. That can be done by a single command:<br />
<br />
cat ~/.tqsl/certs/user ~/.tqsl/certs/authorities > client.crt<br />
<br />
The private key needs to be extracted from the YOURCALL file. The file is a regular ASCII text file, and contains a block which looks something like this (just longer):<br />
<br />
-----BEGIN RSA PRIVATE KEY-----<br />
Proc-Type: 4,ENCRYPTED<br />
DEK-Info: DES-EDE3-CBC,0C7B5495F6A91F31<br />
<br />
0xmWfliK/v9U88MFyYtUbteRoAkfVMK6BllcdID3pZzmdykHaPLZUjXOCUh3vFUX<br />
1bjnYwXpLX/CxgZ6NIxQIk7jMjL3iaP5SkWzCswqi9mCO+zHxuS6PWq7YwbWNFgo<br />
7smNcko1yTp7f/VbS4CZ5kgIF9kCgNaiqdxq+v0IcphQHRR4xjfLpBQ4ckYOi4nC<br />
jqFR1BitwBL4K2JeE9PGUkkUBwvU4oOi9PGChuoxMXs8PwKi/dZTmSWM7kOfMiBw<br />
-----END RSA PRIVATE KEY-----<br />
<br />
Copy-paste that block to a separate file named '''client.key'''. If you're going to open up the original private key file in a text editor, it's a good idea to make a backup copy of that file first in case of an accidental corruption of its contents.<br />
<br />
= Configuring AMPRNet VPN =<br />
<br />
== Windows: OpenVPN ==<br />
<br />
== Linux: OpenVPN ==<br />
<br />
== Mac OS X: Tunnelblick ==</div>Oh7lzbhttps://wiki.ampr.org/w/index.php?title=OH7LZB_VPN&diff=16OH7LZB VPN2013-05-07T20:14:45Z<p>Oh7lzb: Created page with "AMPRNet VPN is an experimental method to access the AMPRNet using a VPN from anywhere on the Internet. The VPN is openly available to any amateur radio operators who have succ..."</p>
<hr />
<div>AMPRNet VPN is an experimental method to access the AMPRNet using a VPN from anywhere on the Internet. The VPN is openly available to any amateur radio operators who have successfully applied for an X.509 certificate from one of the following Certificate Authorities:<br />
<br />
* ARRL Logbook of the World (LoTW)<br />
<br />
The CA validates using a relatively strong method that the operator is actually licensed, and gives the operator a certificate to prove that. Other services, such as the AMPRNet VPN can then check that the operator possesses a valid amateur radio operator certificate (and the accompanying private key), without any manual work being performed by the operators of those services.<br />
<br />
If and when other organisations start to give out X.509 certificates, after sufficient amateur radio license validation, the AMPRNet VPN can be configured to accept those in addition to the LoTW. If you're not willing to obtain a LoTW certificate, please set up a CA for your local club or association, document the method of license validation you're using, and I'll be happy to trust your certificates.<br />
<br />
The VPN operator does not have time to run a CA and validate licenses manually, so please don't ask for a certificate from anywhere else than the CAs listed above. Thanks!<br />
<br />
= Extracting the certificate from LoTW =<br />
<br />
= Configuring AMPRNet VPN =<br />
<br />
== Windows: OpenVPN ==<br />
<br />
== Linux: OpenVPN ==<br />
<br />
== Mac OS X: Tunnelblick ==</div>Oh7lzb