wireguard-tools: heavily modify messy README

3 files changed, 92 insertions, 50 deletions

diff --git a/wireguard-tools/.signature b/wireguard-tools/.signature
index d33c6fbd9..6ea189dfe 100644
--- a/wireguard-tools/.signature
+++ b/wireguard-tools/.signature
@@ -1,5 +1,6 @@
 untrusted comment: verify with /etc/ports/contrib.pub
-RWSagIOpLGJF343vnmjiPrkZ7iWKeFJsyHE0rvuXrzfQqUBYsS4TqeF6a35aT/tHUvDZ/Zj3mz3gfyhna0jee2nKLidBAVGeLA0=
-SHA256 (Pkgfile) = 17f2aac6980be43a7ed2ef760cd8e810a2de2b7caad19af0849be55daf450830
+RWSagIOpLGJF35EkEWKyXqD74c77vs+Ox4Wy074C9n6ywhvhbLMvOzSNc+kS8XPHInvyEtqyFK6/qZNNsBrMHxW5TPDT5Y9Y/gs=
+SHA256 (Pkgfile) = 48cdfa51789ba03be1b67f300d215301e1559c20143aa674a481cc3c13792b1d
 SHA256 (.footprint) = d283d75961bbb0a088b71aba318def5a86976ed952b2f3cb9f6542b061b89a47
 SHA256 (wireguard-tools-1.0.20210315.tar.xz) = af001d5492be6bf58ef0bebe04b446b6f50eb53e1226fab679cc34af40733a22
+SHA256 (README) = 5ca9ee9a84a3d548d4ebf1238a458fda056205aaa19614bfdd85ec6673baef22
diff --git a/wireguard-tools/Pkgfile b/wireguard-tools/Pkgfile
index 2e5f57790..bfc6fef05 100644
--- a/wireguard-tools/Pkgfile
+++ b/wireguard-tools/Pkgfile
@@ -6,7 +6,7 @@ name=wireguard-tools
 version=1.0.20210315
 release=1
 source=(https://git.zx2c4.com/wireguard-tools/snapshot/\
-wireguard-tools-${version}.tar.xz)
+wireguard-tools-${version}.tar.xz README)
 
 build() {
    cd ${name}-${version}
diff --git a/wireguard-tools/README b/wireguard-tools/README
index 36f9bfc1a..b4f44597a 100644
--- a/wireguard-tools/README
+++ b/wireguard-tools/README
@@ -2,18 +2,18 @@ README for WireGuard
 
   WireGuard is a thrilling VirtualPrivateNetwork option.
 
-  It uses stateless UDP connections, and looks like a server socket,
-  for example in output of "ss -l", but also "iptables -nvL".
-  It uses today's state-of-the-art algorithms, is extremely simple to
-  setup and maintain, and has really nifty properties.
-  As an example, you can load /dev/null as the key to make the VPN
-  unusable, just put back the correct key and it functions again.
-  You can also create a VPN with a single command line (plus firewall).
-
-  It is possible to create point-to-point connections where the
-  endpoints can communicate with each other, but dedicated "servers" can
-  be used forward all traffic to the internet, so that laptops and other
-  end-devices can be boxed in a totally detached environment, having
+  It uses stateless UDP connections, and looks like a server socket, for
+  example in output of "ss -l", but also "iptables -nvL".  It uses today's
+  state-of-the-art algorithms, is extremely simple to setup and maintain, and
+  has really nifty properties.  For example, you can load /dev/null as the key
+  to make the VPN unusable, then just put back the correct key and it
+  functions again.  You can also create a VPN with a single command line (plus
+  firewall).
+
+  It is possible to create point-to-point connections where the endpoints can
+  communicate only with each other, but on the other hand dedicated "servers"
+  can be used to which all traffic can be forwarded, so that laptops and other
+  end-devices can be boxed into a totally detached environment, having
   internet access only through (the) VPN(s).
 
   In all cases you need the kernel option
@@ -34,37 +34,37 @@ README for WireGuard
 
 Simple point-to-point VPN
 
-  To create a simple point-to-point VPN place on the server.
   Say this is a VPN of two boxes plus broadcast, server on 10.0.0.2,
   laptop on 10.0.0.1.  The laptop has no fixed IP:
 
   Server.conf:
     [Interface]
-    PrivateKey = PRIKEY
-    ListenPort = PORT
+    PrivateKey = SERVER-PRIKEY
+    ListenPort = SERVER-PORT
 
     [Peer]
-    PublicKey = PUBKEY
+    PublicKey = LAPTOP-PUBKEY
+    # (Or only 10.0.0.1/32)
     AllowedIPs = 10.0.0.0/30
 
   Laptop.conf:
     [Interface]
-    PrivateKey = PRIKEY
-    ListenPort = PORT
+    PrivateKey = LAPTOP-PRIKEY
+    # (Actually unused)
+    ListenPort = LAPTOP-PORT
 
     [Peer]
-    PublicKey = PUBKEY
-    Endpoint = IP-OF-SERVER:PORT-OF-SERVER
+    PublicKey = SERVER-PUBKEY
+    Endpoint = SERVER-IP:SERVER-PORT
     AllowedIPs = 10.0.0.2/32
 
-  We assume these are the first interfaces and end up as wg0:
+  Assuming these are the first interfaces we ever created:
 
-    # wg setconf Server.conf
+    # wg setconf wg0 Server.conf
 
-  We need some firewall rules.  For this case as shown here no
-  forwarding or masquerading is required, it is _never_ but on the
-  server side!
-  The Laptop should get away with
+  We need some firewall rules.  For the case as shown here no forwarding or
+  masquerading is required -- and it is _never_, but on those peers which play
+  a server rule!  The Laptop should get away with
 
     # ip link add dev wg0 type wireguard
     # ip address add 10.0.0.1/30 dev wg0
@@ -74,28 +74,28 @@ Simple point-to-point VPN
     # ip link set wg0 up
     # ip route add 10.0.0.1 dev wg0
 
-  That is it (beat me if i am wrong)!
-  Different iptables on the server:
+  That is it (beat me if i am wrong)!  Different iptables on the server:
 
     # iptables -I INPUT -i wg0 -j ACCEPT
     # # not even iptables -A OUTPUT -o wg0 -j ACCEPT
     # iptables -A INPUT -p udp --dport SRV-PORT -j ACCEPT
 
-  Finished.  Of course you can track the endpoint as they show up, and
-  update the rules with the exact address of the endpoint(s).
-  Like this the last rule of the server can apply blacklisting rules.
-  This works easily because once a handshake is completed this entire
-  NETFILTER is bypassed (at filter level), and only fewest packets
-  actually show up on --dport SRV-PORT.  A working watchdog below. 
+  Finished.  You could track the endpoint as they show up, and update the
+  rules with the exact address of the endpoint(s).  Like this the last shown
+  rule of the server can apply blacklisting rules.  This works easily because
+  once a handshake is completed the defined ListenPort and thus NETFILTER is
+  bypassed (at filter level), and only fewest packets actually show up on
+  --dport SRV-PORT.  A working watchdog below. 
 
 End-user having access only via VPN
 
   In fact this is easy.  Of course you can create a wg, then a network
-  namespace, then move the wg to that namespace, then add the default
-  route via "dev DEVNAME", and be done with it.  Linux even seems to
-  allow to move the physical hardware to a network namespace, then go
-  the different way with the new wg.
-  Really important differences are:
+  namespace, then move the wg to that namespace via "ip link set wg0 netns
+  NSNAME", then add the default route there via "ip -n NSNAME route add
+  default dev wg0", and be done with it.  Linux even seems to allow to move
+  the physical hardware to a network namespace, then go the reverse way with
+  the new wg, leaving only wg in the base namespace, and the physical devices
+  boxed somewhere else.  Really important differences are:
 
     - The laptop must change the AllowedIPs of the server [Peer] to
 
@@ -105,11 +105,50 @@ End-user having access only via VPN
 
     - The server now needs forwarding and masquerading enabled:
 
-      # sysctl -w net.ipv4.conf.ETH0.forwarding=1
-      # sysctl -w net.ipv4.conf.WG0.forwarding=1
-      # iptables -A FORWARD -i WG0 -o ETH0 -j ACCEPT
-      # iptables -A FORWARD -o WG0 -i ETH0 -j ACCEPT
-      # iptables -t nat -A POSTROUTING -o ETH0 -j MASQUERADE
+        # sysctl -w net.ipv4.conf.ETH0.forwarding=1
+        # sysctl -w net.ipv4.conf.WG0.forwarding=1
+        # iptables -A FORWARD -i WG0 -o ETH0 -j ACCEPT
+        # iptables -A FORWARD -o WG0 -i ETH0 -j ACCEPT
+        # iptables -t nat -A POSTROUTING -o ETH0 -j MASQUERADE
+
+      Exchange WG0/ETH0 with your devices.  You may want to have a final
+      FORWARDING rule like
+
+        # iptables -A FORWARD -j REJECT --reject-with icmp-proto-unreachable
+
+  You may want to create an additional veth pair that links into the
+  namespace, so that a local DNS proxy like dnsmasq could serve the DNS of
+  that VPN network namespace as well as any other namespace ("interface
+  NSNAME" in dnsmasq.conf).  No need to start multiple instances, just share
+  the DNS cache.  Of course that single dnsmasq instance could also have
+  a configured upstream that is reached via VPN, maybe just another channel.
+  Luckily "ip link" and "ip netns" names can coexist, so:
+
+      # Placing this in 10.4.0.8/30
+      ip=ip ns=NSNAME 1=10.4.0.9 2=10.4.0.10 p_domain=53
+      ...
+
+       ${ip} link add ${ns} type veth peer name ${ns}_peer
+       ${ip} link set ${ns}_peer netns ${ns}
+
+       ${ip} addr add ${1}/30 dev ${ns}
+       ${ip} link set ${ns} up
+       #${ip} route add ${1} dev ${ns}
+
+       ${ip} -n ${ns} addr add ${2}/30 dev ${ns}_peer broadcast +
+       ${ip} -n ${ns} link set ${ns}_peer up
+       ${ip} -n ${ns} route add ${1} dev ${ns}_peer
+
+       iptables_rule filter INPUT -A -i ${ns} \
+          -p tcp --dport ${p_domain} -j ${ACC}
+       iptables_rule filter INPUT -A -i ${ns} \
+          -p udp --dport ${p_domain} -j ${ACC}
+       iptables_rule filter INPUT -A -i ${ns} -j REJECT
+
+  So now only DNS is allowed from the network namespace to the base namespace,
+  where dnsmasq is listening on "interface NSNAME" (maybe after a restart).
+  All other traffic generated in NSNAME but to 10.4.0.9 is routed through the
+  WireGuard VPN.
 
 A watchdog
 
@@ -118,8 +157,8 @@ A watchdog
 
     # iptables -A INPUT -p udp --dport PORT -j ACCEPT
 
-  rules that are needed.  Here is one idea, it is pretty fresh but
-  working for some time here.  Imagine a configuration
+  rules that are needed (on servers).  Here is one idea, it is pretty fresh
+  but working for some time here.  Imagine a configuration
 
     : ${RUNDIR:=/run}
 
@@ -133,7 +172,9 @@ A watchdog
        #     Ie address+CIDR netmask plus listen port.  Whether we create it.
     ....
 
-  Then this:
+  In the following, please substitute ACCEPT for f_m1, and INPUT for i_good.
+  I currently use primitive CONNMARK jumps for all my traffic, instead of
+  using the "fwmark" feature of WireGuard to shortcut that for the VPN.
 
 wg_watchdog() {
    [ -n "${WG_WATCHDOG}" ] || {