staging.inyokaproject.org

hallo zusammen

bin auf der Suche nach den korrekten rules für folgendes szenario: openvpn client auf ubuntu server 22.04 installiert. dieser soll als internet gateway für alle devices im selben netzsegment dienen. der fwd von ip4 paketen soll jedoch ausschliesslich über den vpn tunnel funktionieren.

Mein Thema: wenn die openvpn verbindung aktiv ist, ist alles wie gewollt. Ist diese jedoch down, wird über das standard gateway (welches nicht getunnelt/geschützt ist) weitergeleitet, was nicht passieren soll.sollte der tunnel down sein, soll jegliche weiterleitung geblockt werden.

interfaces: ens3 lokales netz tun0 openvpn connection.

hat mir einer einen tipp für die nötigen iptables rules?

jamsys schrieb:

sollte der tunnel down sein, soll jegliche weiterleitung geblockt werden.

Funktioniert die Namensauflösung (DNS) und der Zugang zu einem Zeitserver, auf deinem Ubuntu-Server, auch über den VPN-Tunnel oder über das default-gateway? Poste mal mit aktiver VPN-Verbindung, die Ausgaben von:

ip a
ip r
ip n s

Hast Du auf deinem Ubuntu-Server das IPv6 evtl. deaktiviert? Hast Du mit aktiver VPN-Verbindung schon mal ein IPv6-Leak-Test gemacht?

ip a

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
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 52:54:00:cd:9e:64 brd ff:ff:ff:ff:ff:ff
    altname enp0s3
    inet 192.168.11.13/24 brd 192.168.11.255 scope global ens3
       valid_lft forever preferred_lft forever
    inet6 2003:fd:5f07:bf00:5054:ff:fecd:9e64/64 scope global dynamic mngtmpaddr noprefixroute
       valid_lft 6959sec preferred_lft 1558sec
    inet6 fe80::5054:ff:fecd:9e64/64 scope link
       valid_lft forever preferred_lft forever
3: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 500
    link/none
    inet 10.8.1.4/24 scope global tun0
       valid_lft forever preferred_lft forever

ip r

0.0.0.0/1 via 10.8.1.1 dev tun0
default via 192.168.11.1 dev ens3 proto static
10.8.1.0/24 dev tun0 proto kernel scope link src 10.8.1.4
79.142.69.230 via 192.168.11.1 dev ens3
128.0.0.0/1 via 10.8.1.1 dev tun0
192.168.11.0/24 dev ens3 proto kernel scope link src 192.168.11.13

ip n s

192.168.11.1 dev ens3 lladdr 44:4e:6d:1e:f7:0d REACHABLE
192.168.11.74 dev ens3 lladdr e0:d4:e8:ec:7a:ca REACHABLE
192.168.11.229 dev ens3 lladdr 6e:29:ac:c4:41:19 STALE
fe80::9ec7:a6ff:fe9d:8ae6 dev ens3 lladdr 9c:c7:a6:9d:8a:e6 router STALE
fe80::464e:6dff:fe1e:f70d dev ens3 lladdr 44:4e:6d:1e:f7:0d router STALE

/etc/sysctl.conf

...
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1
net.ipv6.conf.tun0.disable_ipv6 = 1
net.ipv4.ip_forward = 1

jamsys schrieb:

ip r

0.0.0.0/1 via 10.8.1.1 dev tun0
default via 192.168.11.1 dev ens3 proto static
10.8.1.0/24 dev tun0 proto kernel scope link src 10.8.1.4
79.142.69.230 via 192.168.11.1 dev ens3
128.0.0.0/1 via 10.8.1.1 dev tun0
192.168.11.0/24 dev ens3 proto kernel scope link src 192.168.11.13

Die Ursache für dein "Problem" ist die 2. default-route mit dem gateway 192.168.11.1, die Du nicht brauchst, weil für den Zugang zur IP-Adresse des VPN-servers (79.142.69.230) eine definierte route über das gateway 192.168.11.1 auch vorhanden ist.

Die Frage nach DNS und nach Zeitserver hast Du aber nicht beantwortet. Versuch mal _temporär_ als Test, mit:

sudo iptables -I OUTPUT 1 -o ens3 -d 192.168.11.0/24 -j ACCEPT
sudo iptables -I OUTPUT 2 -o ens3 ! -d 79.142.69.230 -j REJECT

iptables werde ich mal probieren.

hatte bislang einen Ubuntu 18.04 Openvpn Server. Im update-resolv-conf hatte ich folgende drei befehle drin. Diese werden nun aber unter 22.04 komischerweise nicht mehr gesetzt. das update-resolv-conf wird beim aufbau der openvpn verbindung aufgerufen, die commands aber nicht gesetzt. wenn ich sie manuell setze sehe ich sie wenn ich "sudo iptables -t nat -L" aufrufe.

Nehme an, dass Deine Frage mit DNS hiermit beantwortet ist? Wüsste nicht wie ich die route von ntp oder dns requests aktive abfragen kann.

sudo iptables -t nat -A POSTROUTING -o ens3 -j MASQUERADE
sudo iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE
sudo iptables -t nat -A PREROUTING --source 192.168.11.0/24 --protocol udp --in-interface ens3 --dport 53 --jump DNAT --to-destination 103.86.96.100

der dritte befehl ist für dns requests via vpn. die Masquerades for ens3 und tun0 sind mir selbst gar nicht so klar.

ich habe also noch mehrere issues

1. update-resolve-conf iptables commands werden nicht automatisch gesetzt. dort würde ich Deine iptables commands ergänzen

2. wenn ich die openvpn server config ändere ändert sich auch die ip, somit brauche ich einen mechanismus wie ich die ip im iptables befehl basierend auf der ip des vpn servers automatisch ziehen kann.

jamsys schrieb:

sudo iptables -t nat -A PREROUTING --source 192.168.11.0/24 --protocol udp --in-interface ens3 --dport 53 --jump DNAT --to-destination 103.86.96.100

Wie sind mit und ohne VPN, die Ausgaben von:

host heise.de
host heise.de 103.86.96.100
date

?

mit vpn, mit und ohne die alten iptables rules AUCH ohne vpn, die gleichen ergebnisse

1) host heise.de heise.de has address 193.99.144.80 heise.de has IPv6 address 2a02:2e0:3fe:1001:302:: heise.de mail is handled by 10 relay.heise.de.

2) host heise.de 102.86.96.100

keine Antwort!

3) date Fri Jan 6 12:30:57 UTC 2023

jamsys schrieb:

mit vpn, mit und ohne die alten iptables rules AUCH ohne vpn, die gleichen ergebnisse

OK, dann jetzt im verbose mode, damit man sieht welcher DNS-Server mit und ohne VPN benutzt wird:

host -t a -v berlin.de | grep -i from

Mit VPN und iptables rules

host -t a -v berlin.de | grep -i from
Received 43 bytes from 127.0.0.53#53 in 23 ms

ohne VPN und iptables rules gelöscht

Received 43 bytes from 127.0.0.53#53 in 0 ms

–> beide vom localhost

cat /etc/resolv.conf

# This is /run/systemd/resolve/stub-resolv.conf managed by man:systemd-resolved(8).
# Do not edit.
#
# This file might be symlinked as /etc/resolv.conf. If you're looking at
# /etc/resolv.conf and seeing this text, you have followed the symlink.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "resolvectl status" to see details about the uplink DNS servers
# currently in use.
#
# Third party programs should typically not access this file directly, but only
# through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a
# different way, replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 127.0.0.53
options edns0 trust-ad
search .

jamsys schrieb:

Mit VPN und iptables rules

host -t a -v berlin.de | grep -i from
Received 43 bytes from 127.0.0.53#53 in 23 ms

ohne VPN und iptables rules gelöscht

Received 43 bytes from 127.0.0.53#53 in 0 ms

Dann muss man sich resolved und timesyncd anschauen. Wie sind die Ausgaben von:

resolvectl status
cat /etc/systemd/resolved.conf
timedatectl status
cat /etc/systemd/timesyncd.conf

?

resolvectl status

Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub

Link 2 (ens3)
    Current Scopes: DNS
         Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 8.8.8.8
       DNS Servers: 8.8.8.8 8.8.4.4 fe80::9ec7:a6ff:fe9d:8ae6%21997 fd00::464e:6dff:fe1e:f70d 2003:fd:5f07:bf00:464e:6dff:fe1e:f70d

Link 8 (tun0)
Current Scopes: none
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

cat /etc/systemd/resolved.conf

#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it under the
#  terms of the GNU Lesser General Public License as published by the Free
#  Software Foundation; either version 2.1 of the License, or (at your option)
#  any later version.
#
# Entries in this file show the compile time defaults. Local configuration
# should be created by either modifying this file, or by creating "drop-ins" in
# the resolved.conf.d/ subdirectory. The latter is generally recommended.
# Defaults can be restored by simply deleting this file and all drop-ins.
#
# Use 'systemd-analyze cat-config systemd/resolved.conf' to display the full config.
#
# See resolved.conf(5) for details.

[Resolve]
# Some examples of DNS servers which may be used for DNS= and FallbackDNS=:
# Cloudflare: 1.1.1.1#cloudflare-dns.com 1.0.0.1#cloudflare-dns.com 2606:4700:4700::1111#cloudflare-dns.com 2606:4700:4700::1001#cloudflare-dns.com
# Google:     8.8.8.8#dns.google 8.8.4.4#dns.google 2001:4860:4860::8888#dns.google 2001:4860:4860::8844#dns.google
# Quad9:      9.9.9.9#dns.quad9.net 149.112.112.112#dns.quad9.net 2620:fe::fe#dns.quad9.net 2620:fe::9#dns.quad9.net
#DNS=
#FallbackDNS=
#Domains=
#DNSSEC=no
#DNSOverTLS=no
#MulticastDNS=no
#LLMNR=no
#Cache=no-negative
#CacheFromLocalhost=no
#DNSStubListener=yes
#DNSStubListenerExtra=
#ReadEtcHosts=yes
#ResolveUnicastSingleLabel=no

timedatectl status

               Local time: Fri 2023-01-06 20:39:39 UTC
           Universal time: Fri 2023-01-06 20:39:39 UTC
                 RTC time: Fri 2023-01-06 20:39:39
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

/etc/systemd/timesyncd.conf

#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it under the
#  terms of the GNU Lesser General Public License as published by the Free
#  Software Foundation; either version 2.1 of the License, or (at your option)
#  any later version.
#
# Entries in this file show the compile time defaults. Local configuration
# should be created by either modifying this file, or by creating "drop-ins" in
# the timesyncd.conf.d/ subdirectory. The latter is generally recommended.
# Defaults can be restored by simply deleting this file and all drop-ins.
#
# See timesyncd.conf(5) for details.

[Time]
#NTP=
#FallbackNTP=ntp.ubuntu.com
#RootDistanceMaxSec=5
#PollIntervalMinSec=32
#PollIntervalMaxSec=2048

jamsys schrieb:

resolvectl status

Current DNS Server: 8.8.8.8
       DNS Servers: 8.8.8.8 8.8.4.4 fe80::9ec7:a6ff:fe9d:8ae6%21997 fd00::464e:6dff:fe1e:f70d 2003:fd:5f07:bf00:464e:6dff:fe1e:f70d

timedatectl status

               Local time: Fri 2023-01-06 20:39:39 UTC
           Universal time: Fri 2023-01-06 20:39:39 UTC
                 RTC time: Fri 2023-01-06 20:39:39

Konfiguriert ist nichts. Es wird die Standard-Konfiguration benutzt. Und wenn per IPv4 kein Zugang möglich ist, funktioniert evtl. der Zugang per IPv6 (weiter).

Poste mal mit VPN, die Ausgaben von:

ip -6 r g 2606:4700:4700::1111
ping6 -c 3 2606:4700:4700::1111
dig -6 aaaa heise.de +short @2606:4700:4700::1111
host -6 -t aaaa heise.de 2606:4700:4700::1111

EDIT:

Siehe auch: https://en.wikipedia.org/wiki/Happy_Eyeballs

... denn:

Happy Eyeballs solves this problem by determining which transport would be better used for
a particular connection by trying them both in parallel.[3] An application that uses a Happy
Eyeballs algorithm checks both IPv4 and IPv6 connectivity (with a preference for
IPv6) and uses the first connection that is returned.

ip -6 r g 2606:4700:4700::1111

2606:4700:4700::1111 from :: via fe80::464e:6dff:fe1e:f70d dev ens3 proto ra src 2003:fd:5f07:bf00:5054:ff:fecd:9e64 metric 1024 mtu 1492 pref medium

ping6 -c 3 2606:4700:4700::1111

PING 2606:4700:4700::1111 (2606:4700:4700::1111): 56 data bytes
64 bytes from one.one.one.one: icmp_seq=0 ttl=56 time=10.483 ms
64 bytes from one.one.one.one: icmp_seq=1 ttl=56 time=8.774 ms
64 bytes from one.one.one.one: icmp_seq=2 ttl=56 time=9.259 ms

dig -6 aaaa heise.de +short @2606:4700:4700::1111

2a02:2e0:3fe:1001:302::

host -6 -t aaaa heise.de 2606:4700:4700::1111

Using domain server:
Name: 2606:4700:4700::1111
Address: 2606:4700:4700::1111#53
Aliases:

heise.de has IPv6 address 2a02:2e0:3fe:1001:302::

jamsys schrieb:

ip -6 r g 2606:4700:4700::1111

2606:4700:4700::1111 from :: via fe80::464e:6dff:fe1e:f70d dev ens3 proto ra src 2003:fd:5f07:bf00:5054:ff:fecd:9e64 metric 1024 mtu 1492 pref medium

D. h. IPv6 funktioniert immer. Wenn Du IPv4, bei nicht vorhandenem VPN, blockst, wird evtl. IPv6 verwendet (wenn möglich bzw. wenn via IPv6 erreichbar).