Wireguard client set up: Difference between revisions

From Wildsong
Jump to navigationJump to search
Brian Wilson (talk | contribs)
mNo edit summary
Brian Wilson (talk | contribs)
mNo edit summary
 
(7 intermediate revisions by the same user not shown)
Line 3: Line 3:
Scenario. You have a Raspberry Pi set up with the latest version of the Pi OS installed.
Scenario. You have a Raspberry Pi set up with the latest version of the Pi OS installed.
You can log in via console. You want to set up remote access via [http://tarra.link tarra.link].
You can log in via console. You want to set up remote access via [http://tarra.link tarra.link].
I ended up writing a script that generated key pairs, and put them in /etc/wireguard/KEYS/.
Then I wrote another that takes those files and generates a set of wg0.conf files, one
for each client site.
The rest of this page is pretty much notes from before I wrote those but most of it is still
useful I think.


=== Preliminary set up ===
=== Preliminary set up ===
Line 42: Line 49:
  cat publickey
  cat publickey


On the server now you could paste it, using the name of the host which in the case is "ren-1".
On the server now you could paste it, using the name of the subnet, in this example
This will create a file containing the key called ren-1.pub in /etc/wireguard/
that would be "rendezvous".
This will create a file containing the key called rendezvous.pub in /etc/wireguard/


  sudo -s
  sudo -s
  echo PASTE_THE_PUBLICKEY_STRING_RIGHT_HERE > /etc/wireguard/ren-1.pub
  echo PASTE_THE_PUBLICKEY_STRING_RIGHT_HERE > /etc/wireguard/rendezvous.pub


'''TO DO = write commands to complete the server set up here.'''
(Or use nano or whatever editor you want on Linux.)


=== Set up the client's config file. ===  
=== Set up the client's config file. ===  


The port number does not matter on this end, there is no firewall between us and tarra. The client has to know tarra's port and the first time it connects to tarra it will tell tarra its port number.
The port number does not matter on this end, there is no firewall between us and tarra. The client has to know tarra's port and the first time it connects to tarra it will tell tarra its port number.
 
Lots of people use nano to edit files. It's definitely easier than vim.


  sudo -s
  sudo -s
Line 69: Line 75:
Some research advised before changing it.
Some research advised before changing it.


<pre>
[Interface]
[Interface]
# Desired address at this end, the Raspberry Pi
# Desired address at this end, the Raspberry Pi
Address = '''44.127.9.10/29'''
Address = 44.127.9.33/28
# Paste the private key generated in the previous step here.
# Paste the private key generated in the previous step here.
PrivateKey = ed4S0jLwfBizpnly40wqFaoAjsk/D7oYwblUZNBd8WE= CHANGE THIS TO YOUR PRIVATE KEY
PrivateKey = ed4S0jLwfBizpnly40wqFaoAjsk/D7oYwblUZNBd8WE= CHANGE THIS TO YOUR PRIVATE KEY
 
[Peer]
[Peer]
Endpoint = 45.76.244.170:51820
Endpoint = 45.76.244.170:51820
# All TARRA AMPR addresses (44.127.9.x)should be sent to tarra at vultr.
# All TARRA AMPR addresses (44.127.9.x)should be sent to tarra at vultr.
# All Internet traffic should be routed over the tunnel (0.0.0.0/0)
# All Internet traffic should be routed over the tunnel (0.0.0.0/0)
# If you leave off the 0.0.0.0/0 you have a "split tunnel"
# If you leave off the 0.0.0.0/0 you have a "split tunnel"
AllowedIPs = 44.127.9.0/24, 0.0.0.0/0
AllowedIPs = 44.127.9.0/24, 0.0.0.0/0
PublicKey = KnD5dfwSMAoUGXySxZtxuvfKMIBf+YKc+hiJifGQWwc=
PublicKey = KnD5dfwSMAoUGXySxZtxuvfKMIBf+YKc+hiJifGQWwc=
PersistentKeepalive = 25
PersistentKeepalive = 25
</pre>


Leaving out the 0.0.0.0/0 part of AllowedIPs is a split tunnel configuration.
Leaving out the 0.0.0.0/0 part of AllowedIPs is a split tunnel configuration.
Line 93: Line 97:
=== Bring up the connection ===
=== Bring up the connection ===


wg-quick up wg0
For each subnet currently defined, there is a script on Tarra, run it. For rendezvous,


I find that it's useful to run the 'wg show' command to see what things look like.
cd /etc/wireguard
On my Pi3 "violet" it looks like this when the link is up.
./wg-rendezvous.sh up
(When the link is down, it shows nothing.)


root@violet:/etc/wireguard# '''wg show'''
You can make a new script if you need to. Copy TEMPLATE.sh and be sure to add the script to
interface: wg0
wg-all.sh to bring it online after a reboot. But there should already be one there...
  public key: GRj/PCkIRbcClXPep5IE2nsg9Lg2WmZDkBSW65yl4jw=
  private key: (hidden)
  listening port: 51820


peer: KnD5dfwSMAoUGXySxZtxuvfKMIBf+YKc+hiJifGQWwc=
From tarra, ping the new node
  preshared key: (hidden)
  endpoint: 45.76.244.170:51820
  allowed ips: 44.127.9.0/24
  latest handshake: 30 seconds ago
  transfer: 11.07 KiB received, 28.07 KiB sent
  persistent keepalive: every 25 seconds


I don't know if your node will be resolving addresses so I show IP addresses here.
ping ren-1.tarra.link
This is the address for ren-1.tarra.link
 
ping 44.127.9.33
 
This is the router end of the tunnel, t3.tarra.link
 
ping 44.127.9.46
 
You should be able to hit the main address at the router, tarra.link
 
ping 44.127.9.254
 
From tarra you should be able to ping the node. You don't need the full name here.


ping ren-1
On the node, you should be able to hit the main address at the router, tarra.link


From your laptop or anywhere on the Internet you should be able to ping the node now,
From your laptop or anywhere on the Internet you should be able to ping the node now,
Line 139: Line 120:


=== Make wireguard run after reboot ===
=== Make wireguard run after reboot (on the client) ===


([https://www.ivpn.net/knowledgebase/linux/linux-autostart-wireguard-in-systemd/ Here are docs])
([https://www.ivpn.net/knowledgebase/linux/linux-autostart-wireguard-in-systemd/ Here are docs])
Line 155: Line 136:
the previous section again to satisfy yourself that it rebooted correctly.
the previous section again to satisfy yourself that it rebooted correctly.


== This is how the Mango link looks ==
root@TARRA:/etc/wireguard# '''wg show'''
interface: wg0
  public key: KnD5dfwSMAoUGXySxZtxuvfKMIBf+YKc+hiJifGQWwc=
  private key: (hidden)
  listening port: 51820
peer: nzbpyIxFtj/MuJp3LBsQTvGVvWqOvDOIAbw1SfK3NU4=
  endpoint: 166.176.59.192:29748
  allowed ips: 10.0.0.0/24
  latest handshake: 39 seconds ago
  transfer: 9.51 MiB received, 9.06 MiB sent
root@TARRA:/etc/wireguard# '''iptables -L -t nat'''
Chain PREROUTING (policy ACCEPT)
target    prot opt source              destination       
DNAT      tcp  --  anywhere            45.76.244.170.vultrusercontent.com  tcp dpt:22222 to:10.0.0.10
DNAT      udp  --  anywhere            45.76.244.170.vultrusercontent.com  udp dpts:2074:2093 to:10.0.0.10
DNAT      tcp  --  anywhere            45.76.244.170.vultrusercontent.com  tcp dpts:15425:15427 to:10.0.0.10
DNAT      tcp  --  anywhere            45.76.244.170.vultrusercontent.com  tcp dpt:12300 to:10.0.0.10
DNAT      udp  --  anywhere            45.76.244.170.vultrusercontent.com  udp dpts:2074:2093 to:10.0.0.10
DNAT      tcp  --  anywhere            45.76.244.170.vultrusercontent.com  tcp dpts:15425:15427 to:10.0.0.10
DNAT      udp  --  anywhere            45.76.244.170.vultrusercontent.com  udp dpts:2074:2093 to:10.0.0.10
DNAT      udp  --  anywhere            45.76.244.170.vultrusercontent.com  udp dpts:5198:5199 to:10.0.0.10
Chain INPUT (policy ACCEPT)
target    prot opt source              destination       
Chain OUTPUT (policy ACCEPT)
target    prot opt source              destination       
Chain POSTROUTING (policy ACCEPT)
target    prot opt source              destination       
MASQUERADE  all  --  anywhere            anywhere


[[Category: Radio]]
[[Category: Radio]]
[[Category: Network]]
[[Category: Network]]
[[Category: System Administration]]
[[Category: System Administration]]

Latest revision as of 02:46, 17 March 2022

This is part of the Repeater linking project I am working on.

Scenario. You have a Raspberry Pi set up with the latest version of the Pi OS installed. You can log in via console. You want to set up remote access via tarra.link.

I ended up writing a script that generated key pairs, and put them in /etc/wireguard/KEYS/. Then I wrote another that takes those files and generates a set of wg0.conf files, one for each client site.

The rest of this page is pretty much notes from before I wrote those but most of it is still useful I think.

Preliminary set up

You should have the ssh server installed and enabled. You can do that in raspi-config under "Interfaces", "SSH". You can change the name of the client in there too, under "System", "Hostname".

The client has to be able to connect to the Internet but it can be on either a static or DHCP dynamic link, it won't matter. Once everything is set up, you will be able to use the Wireguard tunnel connection to get from the Internet to the client even if the DHCP address changes.

CHANGE THE PASSWORD ON THE CLIENT BEFORE EXPOSING IT TO THE INTERNET. Use raspi-config or from the command line, use the 'passwd' command.

Install Wireguard

Working on the client,

sudo apt-get install wireguard -y

Some comments. You don't have to enable packet forwarding, because this is a client node and won't be doing any packet forwarding. You don't have to set up a firewall, that will be handled on tarra. We might decide to set up a firewall later but for now it's just extra complexity. It would not hurt to install iptables and fail2ban just so its there for later.

sudo apt-get install fail2ban

Generate a pair of keys

The keys will be called "privatekey" and "publickey", in the folder /etc/wireguard. First make sure the folder is secured (the chmod command).

Still on the client,

sudo -s
chmod 700 /etc/wireguard
cd /etc/wireguard/
wg genkey | tee privatekey | wg pubkey > publickey

Copy the public key to the server. An easy way is to dump it to the screen and then cut and paste.

cat publickey

On the server now you could paste it, using the name of the subnet, in this example that would be "rendezvous". This will create a file containing the key called rendezvous.pub in /etc/wireguard/

sudo -s
echo PASTE_THE_PUBLICKEY_STRING_RIGHT_HERE > /etc/wireguard/rendezvous.pub

(Or use nano or whatever editor you want on Linux.)

Set up the client's config file.

The port number does not matter on this end, there is no firewall between us and tarra. The client has to know tarra's port and the first time it connects to tarra it will tell tarra its port number.

sudo -s
cd /etc/wireguard
nano wg0.conf

You can 'cat' the private key and copy it so that you can paste it into the wg0.conf file.

cat privatekey

Next use nano to make the file look like this, changing it as needed for your client. I read somewhere that 25 seconds is a good value to use for the keepalive. Over a cellular link (data rates apply) a longer interval might be better?? Some research advised before changing it.

[Interface]
# Desired address at this end, the Raspberry Pi
Address = 44.127.9.10/29
# Paste the private key generated in the previous step here.
PrivateKey = ed4S0jLwfBizpnly40wqFaoAjsk/D7oYwblUZNBd8WE= CHANGE THIS TO YOUR PRIVATE KEY

[Peer]
Endpoint = 45.76.244.170:51820
# All TARRA AMPR addresses (44.127.9.x)should be sent to tarra at vultr.
# All Internet traffic should be routed over the tunnel (0.0.0.0/0)
# If you leave off the 0.0.0.0/0 you have a "split tunnel"
AllowedIPs = 44.127.9.0/24, 0.0.0.0/0
PublicKey = KnD5dfwSMAoUGXySxZtxuvfKMIBf+YKc+hiJifGQWwc=
PersistentKeepalive = 25

Leaving out the 0.0.0.0/0 part of AllowedIPs is a split tunnel configuration. The "split tunnel" config sends traffic for the AMPR net over the tunnel and lets everything else go out to the Internet without using the tunnel. Faster but less secure.

Bring up the connection

For each subnet currently defined, there is a script on Tarra, run it. For rendezvous,

cd /etc/wireguard
./wg-rendezvous.sh up

You can make a new script if you need to. Copy TEMPLATE.sh and be sure to add the script to wg-all.sh to bring it online after a reboot. But there should already be one there...

From tarra, ping the new node

ping ren-1.tarra.link

On the node, you should be able to hit the main address at the router, tarra.link

From your laptop or anywhere on the Internet you should be able to ping the node now,

ping ren-1.tarra.link

You should be able to log into the node over the Internet. You did change the password? Great. Otherwise someone will figure out this is a Raspberry Pi and log in and take control of it in about 5 minutes. I am not exaggerating.

ssh [email protected]

Make wireguard run after reboot (on the client)

(Here are docs)

sudo -s
systemctl enable [email protected]
systemctl daemon-reload
systemctl start wg-quick@wg0

Reboot now to make sure it took. Once you reboot, do this again.

wg show

You should see the link still exists and that there is a connection. Run the tests from the previous section again to satisfy yourself that it rebooted correctly.

This is how the Mango link looks

root@TARRA:/etc/wireguard# wg show
interface: wg0
 public key: KnD5dfwSMAoUGXySxZtxuvfKMIBf+YKc+hiJifGQWwc=
 private key: (hidden)
 listening port: 51820

peer: nzbpyIxFtj/MuJp3LBsQTvGVvWqOvDOIAbw1SfK3NU4=
 endpoint: 166.176.59.192:29748
 allowed ips: 10.0.0.0/24
 latest handshake: 39 seconds ago
 transfer: 9.51 MiB received, 9.06 MiB sent
root@TARRA:/etc/wireguard# iptables -L -t nat
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         
DNAT       tcp  --  anywhere             45.76.244.170.vultrusercontent.com  tcp dpt:22222 to:10.0.0.10
DNAT       udp  --  anywhere             45.76.244.170.vultrusercontent.com  udp dpts:2074:2093 to:10.0.0.10
DNAT       tcp  --  anywhere             45.76.244.170.vultrusercontent.com  tcp dpts:15425:15427 to:10.0.0.10
DNAT       tcp  --  anywhere             45.76.244.170.vultrusercontent.com  tcp dpt:12300 to:10.0.0.10
DNAT       udp  --  anywhere             45.76.244.170.vultrusercontent.com  udp dpts:2074:2093 to:10.0.0.10
DNAT       tcp  --  anywhere             45.76.244.170.vultrusercontent.com  tcp dpts:15425:15427 to:10.0.0.10
DNAT       udp  --  anywhere             45.76.244.170.vultrusercontent.com  udp dpts:2074:2093 to:10.0.0.10
DNAT       udp  --  anywhere             45.76.244.170.vultrusercontent.com  udp dpts:5198:5199 to:10.0.0.10

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         
MASQUERADE  all  --  anywhere             anywhere