wireguard-tools: heavily modify messy README
This commit is contained in:
parent
0558e5719d
commit
f48c314f2a
@ -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
|
||||
|
||||
@ -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}
|
||||
|
||||
@ -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 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 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 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}" ] || {
|
||||
|
||||
Loading…
Reference in New Issue
Block a user