Ich versuche, den Wireguard-VPN-Test zum Laufen zu bringen, aber ich stecke fest. Ich bin für alle Vorschläge dankbar, was ich als nächstes überprüfen soll.
Der Server ist ein DO-Droplet, auf dem Ubuntu mit dem Kernel 3.13.0-141 läuft. Der Client ist ein Desktop-KVM-Gast, auf dem Mint mit dem Kernel 4.4.0-112 läuft und eine überbrückte Netzwerkverbindung hinter einem NAT-Router besteht. Der Client kann den Server problemlos anpingen, aber alle anderen Pakettypen scheinen verloren zu gehen. TCPdump zeigt jedoch viele Pakete an, die bei wg0 auf dem Server ankommen. ip_forward und proxy_arp sind wie vorgeschlagen auf dem Server aktiviert.in diesem Beitrag.ufw auf dem Server hat den Tunnelport geöffnet. Der Server führt OpenVPN auch auf anderen Ports aus.
Verwenden von wg-quick mit diesen Konfigurationsdateien.
Klient:
[Interface]
Address = 10.0.0.200
DNS = 8.8.8.8
PrivateKey = UJeiJJvi5NdqiBrgBfsim+ZS4c69M5EP5fUNNIXMy08=
[Peer]
PublicKey = MreTtFUDB5bQfkegxX2cvz3BLC9sybK4y0loTKhVunU=
AllowedIPs = 0.0.0.0/0
Endpoint = 159.203.227.235:51820
sudo wg-quick up ./wg0.conf
[sudo] password for jim:
[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip address add 10.0.0.200 dev wg0
[#] ip link set mtu 1420 dev wg0
[#] ip link set wg0 up
[#] resolvconf -a tun.wg0 -m 0 -x
[#] wg set wg0 fwmark 51820
[#] ip -4 route add 0.0.0.0/0 dev wg0 table 51820
[#] ip -4 rule add not fwmark 51820 table 51820
[#] ip -4 rule add table main suppress_prefixlength 0
Server:
[Interface]
Address = 10.0.0.201
SaveConfig = true
ListenPort = 51820
PrivateKey = 6GBAE7bFjrOfEp1uWiPvoW+5CyfpjsBmK0/vCIWbGl0=
[Peer]
PublicKey = furwAmh4vbKrLAGZG/QDIUT2a1GLi0WxDY6YdQKzIHE=
AllowedIPs = 10.0.0.200/32
sudo wg-quick up ./wg0.conf
[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip link set mtu 1420 dev wg0
[#] ip link set wg0 up
[#] ip route add 10.0.0.200/32 dev wg0
ip route show table all
default via 159.203.224.1 dev eth0
10.0.0.200 dev wg0 scope link
10.12.0.0/16 dev eth0 proto kernel scope link src 10.12.0.5
159.203.224.0/20 dev eth0 proto kernel scope link src 159.203.227.235
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1
broadcast 10.12.0.0 dev eth0 table local proto kernel scope link src 10.12.0.5
local 10.12.0.5 dev eth0 table local proto kernel scope host src 10.12.0.5
broadcast 10.12.255.255 dev eth0 table local proto kernel scope link src 10.12.0.5
broadcast 127.0.0.0 dev lo table local proto kernel scope link src 127.0.0.1
local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1
local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1
broadcast 127.255.255.255 dev lo table local proto kernel scope link src 127.0.0.1
broadcast 159.203.224.0 dev eth0 table local proto kernel scope link src 159.203.227.235
local 159.203.227.235 dev eth0 table local proto kernel scope host src 159.203.227.235
broadcast 159.203.239.255 dev eth0 table local proto kernel scope link src 159.203.227.235
broadcast 172.17.0.0 dev docker0 table local proto kernel scope link src 172.17.0.1
local 172.17.0.1 dev docker0 table local proto kernel scope host src 172.17.0.1
broadcast 172.17.255.255 dev docker0 table local proto kernel scope link src 172.17.0.1
fe80::/64 dev eth0 proto kernel metric 256
fe80::/64 dev veth215195c proto kernel metric 256
fe80::/64 dev docker0 proto kernel metric 256
unreachable default dev lo table unspec proto kernel metric 4294967295 error -101
local ::1 dev lo table local proto none metric 0
local fe80::42:2fff:fec9:400 dev lo table local proto none metric 0
local fe80::601:d8ff:febf:4701 dev lo table local proto none metric 0
local fe80::84ce:13ff:feaf:f628 dev lo table local proto none metric 0
ff00::/8 dev eth0 table local metric 256
ff00::/8 dev veth215195c table local metric 256
ff00::/8 dev docker0 table local metric 256
unreachable default dev lo table unspec proto kernel metric 4294967295 error -101
Antwort1
Ich habe dies mit Hilfe dieses sehr nützlichenBlogeintrag Darin wird auch erläutert, wie ein DNS-Server eingerichtet wird, um zu verhindern, dass Client-DNS-Verkehr aus dem Tunnel nach außen gelangt.
Das Hauptproblem war eine unvollständige Filter-/NAT-Einrichtung auf dem Server. Der Beitrag behandelt die erforderlichen iptables-Befehle. Da ufw bereits für einfache Dinge wie ssh verwendet wurde und ich nicht versuchen wollte, alles in ein Format zu konvertieren, habe ich sie einfach kombiniert. Dies funktionierte für ein neues Droplet mit Ubuntu 16.04. Auch auf meinem ursprünglichen Ubuntu 14.04-System getestet, wo ich eine zusätzliche ufw-Regel hinzufügen musste:
UFW-Route erlaubt In auf WG0 von 10.200.200.2 Out auf Eth0
anscheinend weil aus irgendeinem Grund die Standardrichtlinien für Eingabe und Weiterleitung auf DROP gesetzt waren.