staging.inyokaproject.org

Hallo zusammen,

seit einiger Zeit habe eine virtuelle Ubuntu Maschine (noch mit 16.04) als VPN Gateway mit OpenVPN laufen. Die VM baut mittels OpenVPN eine VPN Verbindung mit dem VPN Anbieter (aktuell ProtonVPN) auf, alle anderen Clients im Haus können sich darüber verbinden, indem als Gateway die VM hinterlegt wird. Das habe ich vor über einem Jahr aufgesetzt und habe keine Ahnung mehr wie ich die IP Tables bearbeitet habe, damit alles ausschließlich über die VPN Verbindung geroutet wird. Jetzt läuft das nicht mehr stabil und ich würde gerne auf Wireguard wechseln.

Wireguard habe ich bereits installiert und die Verbindung läuft zuverlässig auf der VM. Allerdings kann ich nun nicht mehr mit allen anderen Geräten darauf über die VM zugreifen. Vermutlich, weil noch alle eingehenden Daten über Openvpn geroutet werden sollen, darüber aber keine Verbindung mehr besteht?

In dem Atemzug habe ich dann aber auch eine neue VM mit Ubuntu 22.10 aufgesetzt. Wireguard-Verbindung steht, auch kann jungfräulich über die VM geroutet werden (ip-forwarding ist aktiv), allerdings werden alle Verbindungen von den Geräten nicht durch die Wireguard-Verbindung sondern durch die Fritz.Box geroutet.

Sorry, bin bei Linux echt relativ unerfahren. Setze mir alles dann mittels Google zusammen, aber man findet zig Seiten mit den Erklärungen, wie man Ubuntu als VPN Server aufsetzen kann, aber nicht, wie man Ubuntu als VPN Client aufsetzt und diese Verbindung als Gateway / Router / Access Points für weitere Geräte nutzen kann.

Hoffe, mir kann jemand helfen. Anbei noch eine grobe Zeichnung, wie ich mir das vorstelle. Wie gesagt, mit OpenVPN hat das jetzt Jahre super funktioniert. Nachdem ich da eher unbedarft bin und das eben schon länger her ist, habe ich auch keine Ahnung mehr wie und was ich jetzt für WG ändern müsste.

Danke euch!

seit einiger Zeit habe eine virtuelle Ubuntu Maschine (noch mit 16.04) als VPN Gateway mit OpenVPN laufen

Dann setze diese bitte mit 22.04 neu auf, denn 16.04 ist seit Jahren EoL. Wenn das getan ist:

ip route show
ip -6 route show

Ja, das habe ich bereits mit 22.10, da ich eh upgraden wollte, das aber aufgrund der geringen zugewiesenen Festplattengröße (5gb) nicht geklappt habe. Hatte die 16.04 daher als ESM laufen um diese mit Patches zu versorgen.

aber wie gesagt, habe eine neue mit 22.10 aufgesetzt, die aber bis auf wireguard und dem gesetzten ipv4 forwarding noch jungfräulich ist.

ip route show

default via 192.168.178.1 dev enp1s0 proto static 
192.168.178.0/24 dev enp1s0 proto kernel scope link src 192.168.178.112 

ip -6 route show

::1 dev lo proto kernel metric 256 pref medium
fe80::/64 dev enp1s0 proto kernel metric 256 pref medium

wenn ich über Ubuntu meine externe IP abrufe (zB über curl ifconfig.me), bekomme ich die externe des VPN Anbieters wiedergegeben.

kurzes Update: habe es nochmal weiter versucht. Oben habe ich noch erwähnt, dass ich die VM prinzipiell als Gateway nutzen kann, die Verbindung über die normale und nicht VPN Verbindung weitergeleitet wird - das kann ich nicht mehr reproduzieren. Egal mit welchem Gerät ich es versuche, sobald ich die VM als Gateway hinterlege, ist die Verbindung tot. Über die VM selbst besteht die VPN Verbindung allerdings stabil.

Koko80 schrieb:

wenn ich über Ubuntu meine externe IP abrufe (zB über curl ifconfig.me), bekomme ich die externe des VPN Anbieters wiedergegeben.

OK, dann poste mal von der Stelle, an der Du curl benutzt, die Ausgaben von:

ip -4 r g 9.9.9.9
mtr -4nr -c 1 1.1.1.1

Koko80 schrieb:

Egal mit welchem Gerät ich es versuche, sobald ich die VM als Gateway hinterlege, ist die Verbindung tot. Über die VM selbst besteht die VPN Verbindung allerdings stabil.

Hast Du ein Gerät mit Linux? Wenn ja, wie hinterlegst Du in diesem Gerät (mit Linux), die VM als Gateway? Poste von diesem Gerät die Ausgaben von:

ip -4 r
ip -4 r g 1.1.1.1 

von der VM:

9.9.9.9 dev wg0 table 51820 src 10.2.0.2 uid 1000 
    cache 

Start: 2022-11-27T17:02:06+0000
HOST: gateway                     Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- ???                       100.0     1    0.0   0.0   0.0   0.0   0.0
  2.|-- 194.126.177.3              0.0%     1   25.8  25.8  25.8  25.8   0.0
  3.|-- ???                       100.0     1    0.0   0.0   0.0   0.0   0.0
  4.|-- 62.67.33.37                0.0%     1   20.8  20.8  20.8  20.8   0.0
  5.|-- 212.162.9.130              0.0%     1   15.2  15.2  15.2  15.2   0.0
  6.|-- 172.70.244.5               0.0%     1   14.8  14.8  14.8  14.8   0.0
  7.|-- 1.1.1.1                    0.0%     1   14.7  14.7  14.7  14.7   0.0

vom Gerät

default via 192.168.178.112 dev eth0 
169.254.0.0/16 dev eth0 
192.168.178.0/24 dev eth0  src 192.168.178.55 

1.1.1.1 via 192.168.178.112 dev eth0  src 192.168.178.55 

Hinterlege die .112 als Gateway in der manuellen IP Konfiguration. Entweder über GUI, oder bspw über der gateway der /etc/network/interface

Koko80 schrieb:

vom Gerät

default via 192.168.178.112 dev eth0 
169.254.0.0/16 dev eth0 
192.168.178.0/24 dev eth0  src 192.168.178.55 

1.1.1.1 via 192.168.178.112 dev eth0  src 192.168.178.55 

Hinterlege die .112 als Gateway in der manuellen IP Konfiguration.

BTW: interfaces-Datei sollte man mit systemd nicht mehr benutzen und GUI ist auch nicht so professionell.

Hast Du in der VM, bei den relevanten Interfaces (lan, wg, ...) source-NAT (MASQUERADE) konfiguriert? Mit tcpdump an den NICs in der VM und dem geeigneten Filter, kannst Du schauen, ob und welche Datenpakete vom Gerät (Richtung Internet) kommen und welchen Weg sie gehen bzw. wie weit sie kommen und ob bzw. wie der Rückweg funktioniert.

Das ist jetzt der Punkt, an dem ich nur noch Bahnhof verstanden habe 😉

Nein, ich habe nichts dergleichen in der VM mit Ubuntu 22.10 konfiguriert, rein Wireguard installiert, das mit der entsprechenden Konf versehen und net.ipv4.ip_forward aktiviert. Laut einer der leider sehr spärlich verfügbaren Schritt-für-Schritt-Anleitungen sollte es das gewesen sein - ist es aber nicht.

Koko80 schrieb:

Nein, ich habe nichts dergleichen in der VM mit Ubuntu 22.10 konfiguriert, ...

Wie sind in der VM die Ausgaben von:

ip a
sudo iptables -nvx -L -t nat

?

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 52:54:00:cb:f3:b0 brd ff:ff:ff:ff:ff:ff
    inet 192.168.178.112/24 brd 192.168.178.255 scope global enp1s0
       valid_lft forever preferred_lft forever
    inet6 fe80::5054:ff:fecb:f3b0/64 scope link 
       valid_lft forever preferred_lft forever
3: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
    link/none 
    inet 10.2.0.2/32 scope global wg0
       valid_lft forever preferred_lft forever

und

Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination         

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination        

Koko80 schrieb:

2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 52:54:00:cb:f3:b0 brd ff:ff:ff:ff:ff:ff
    inet 192.168.178.112/24 brd 192.168.178.255 scope global enp1s0
3: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
    link/none 
    inet 10.2.0.2/32 scope global wg0

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination        

Dann teste mal mit:

sudo iptables -t nat -I POSTROUTING 1 -o enp1s0 -j MASQUERADE
sudo iptables -t nat -I POSTROUTING 2 -o wg0 -j MASQUERADE

Ist alles unverändert.

Koko80 schrieb:

Ist alles unverändert.

Wie sind die Ausgaben von:

sudo iptables -nvx -L
sudo iptables -nvx -L POSTROUTING -t nat

?

Du könntest auch mit tcpdump auf den Interfaces in der VM schauen, ob vom Gerät das via VPN ins Internet will/soll, Daten ankommen.

Oh, jetzt hat sich doch was getan (edit: kam vom PostUp und PreDown-Eintrag in der Wireguard-conf. Die soll sicherstellen, dass nur Geräte aus dem 192.168.178.0/24 Subnet Zugriff haben sollen; ohne die beiden Einträge ist die Chain OUTPUT auch wieder komplett leer wie vorher)

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination         
    9990   698908 ACCEPT     all  --  *      *       0.0.0.0/0            192.168.178.0/24    
     278    34424 ACCEPT     all  --  *      *       192.168.178.0/24     0.0.0.0/0           
       0        0 REJECT     all  --  *      !wg0    0.0.0.0/0            0.0.0.0/0            mark match ! 0xca6c ADDRTYPE match dst-type !LOCAL reject-with icmp-port-unreachable

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination   

mit "tcpdump net 192.168.178.55" kam folgendes. Am "Client" (.55) habe ich web.de angepingt. Es kommt also an der VM etwas an, wird da aber verschluckt?

tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on enp1s0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
19:22:27.876114 IP 192.168.178.55.39309 > 192.168.178.112.domain: 19663+ A? google.com. (28)
19:22:27.876159 IP 192.168.178.112 > 192.168.178.55: ICMP 192.168.178.112 udp port domain unreachable, length 64
19:22:32.964573 ARP, Request who-has 192.168.178.55 tell 192.168.178.112, length 28
19:22:32.966724 ARP, Reply 192.168.178.55 is-at 00:1d:ec:0f:e2:64 (oui Unknown), length 46
19:22:37.877901 IP 192.168.178.55.46250 > 192.168.178.112.domain: 12996+ A? google.com. (28)
19:22:37.877938 IP 192.168.178.112 > 192.168.178.55: ICMP 192.168.178.112 udp port domain unreachable, length 64
19:22:47.878423 IP 192.168.178.55.33584 > 192.168.178.112.domain: 42812+ A? google.com. (28)
19:22:47.878463 IP 192.168.178.112 > 192.168.178.55: ICMP 192.168.178.112 udp port domain unreachable, length 64
19:22:52.896531 ARP, Request who-has 192.168.178.112 tell 192.168.178.55, length 46
19:22:52.896546 ARP, Reply 192.168.178.112 is-at 52:54:00:cb:f3:b0 (oui Unknown), length 28
19:22:54.186805 IP 192.168.178.55.59327 > 192.168.178.112.domain: 22989+ A? web.de. (24)
19:22:54.186805 IP 192.168.178.55.59327 > 192.168.178.112.domain: 33390+ AAAA? web.de. (24)
19:22:54.186841 IP 192.168.178.112 > 192.168.178.55: ICMP 192.168.178.112 udp port domain unreachable, length 60
19:22:54.186854 IP 192.168.178.112 > 192.168.178.55: ICMP 192.168.178.112 udp port domain unreachable, length 60
19:22:54.207473 IP 192.168.178.55 > bs.web.de: ICMP echo request, id 16172, seq 0, length 64
19:22:55.207772 IP 192.168.178.55 > bs.web.de: ICMP echo request, id 16172, seq 1, length 64
19:22:56.207745 IP 192.168.178.55 > bs.web.de: ICMP echo request, id 16172, seq 2, length 64
19:22:57.208220 IP 192.168.178.55 > bs.web.de: ICMP echo request, id 16172, seq 3, length 64
19:22:57.883031 IP 192.168.178.55.60059 > 192.168.178.112.domain: 16711+ A? google.com. (28)
19:22:57.883073 IP 192.168.178.112 > 192.168.178.55: ICMP 192.168.178.112 udp port domain unreachable, length 64

Koko80 schrieb:

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination         
    9990   698908 ACCEPT     all  --  *      *       0.0.0.0/0            192.168.178.0/24    
     278    34424 ACCEPT     all  --  *      *       192.168.178.0/24     0.0.0.0/0           
       0        0 REJECT     all  --  *      !wg0    0.0.0.0/0            0.0.0.0/0            mark match ! 0xca6c ADDRTYPE match dst-type !LOCAL reject-with icmp-port-unreachable

Wer hat diese Regeln in der OUTPUT chain konfiguriert und warum? Welche Auswirkung/Folgen hat das entfernen dieser Regeln?

Das war ich, als ich die WIreguard-conf aufgesetzt habe. Habe die Einträge testweise gerade mal in der wireguard-conf aktiv gesetzt, ob es ggf. was bringt. Sorry, hatte vergessen sie für den Beitrag wieder rauszunehmen. Habe sie wieder rausgenommen und die Tabelle ist wieder leer. tcpdump ist unverändert - mit oder ohne Einträge.

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination