☰

OpenVPN-Routing: mehrere Standardeinträge. OpenVPN-Client: iptables. DNS-Probleme

tag-icon • tag-icon domain-name-system iptables routing openvpn dnsmasq
OpenVPN-Routing: mehrere Standardeinträge. OpenVPN-Client: iptables. DNS-Probleme

Ich verwende einen OpenVPN-Server (Debian 8) aus Datenschutzgründen bei der Nutzung von öffentlichem WLAN. Daher soll der gesamte Netzwerkverkehr des Clients über die VPN-Verbindung abgewickelt werden. Die Server- und Client-Konfiguration ist unten angegeben.

Serverkonfiguration:

port 1194
proto tcp
dev tun

ca /etc/openvpn/ca.crt
cert /etc/openvpn/server.crt    
key /etc/openvpn/server.key
dh /etc/openvpn/dh.pem
tls-auth /etc/openvpn/tlsauth.key 0

user nobody
group nogroup

server 10.11.12.0 255.255.255.0

ifconfig-pool-persist ipp.txt
keepalive 10 120

push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"

persist-key
persist-tun

comp-lzo
status openvpn-status.log
verb 3

Client-Konfiguration:

client
remote X.X.X.X 1194
proto tcp

dev tun

resolv-retry-infinite

nobind

user nobody
group nogroup

persist-key
persist-tun

ca /etc/openvpn/ca.crt
cert /etc/openvpn/client.crt    
key /etc/openvpn/client.key
tls-auth /etc/openvpn/tlsauth.key 0

comp-lzo 0
verb 2

Wenn der VPN-Dienst auf dem Client gestartet wird, wird die Routing-Tabelle wie unten angegeben geändert.

Routing-Tabelle (192.168.178.0/24 bezeichnet das öffentliche WLAN):

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.11.12.13     128.0.0.0       UG    0      0        0 tun0
0.0.0.0         192.168.178.1   0.0.0.0         UG    1024   0        0 wlan0
10.11.12.1      10.11.12.13     255.255.255.255 UGH   0      0        0 tun0
10.11.12.13     0.0.0.0         255.255.255.255 UH    0      0        0 tun0
128.0.0.0       10.11.12.13     128.0.0.0       UG    0      0        0 tun0
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 wlan0
192.168.178.0   0.0.0.0         255.255.255.0   U     0      0        0 wlan0
X.X.X.X         192.168.178.1   255.255.255.255 UGH   0      0        0 wlan0

Der relevante Abschnitt des Syslogs beim Starten von OpenVPN:

ovpn-client[3395]: OpenVPN 2.3.4 i586-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Dec  1 2014
ovpn-client[3395]: library versions: OpenSSL 1.0.1k 8 Jan 2015, LZO 2.08    
ovpn-client[3395]: WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
ovpn-client[3395]: Control Channel Authentication: using '/etc/openvpn/tlsauth.key' as a OpenVPN static key file
ovpn-client[3395]: Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
ovpn-client[3395]: Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
ovpn-client[3396]: NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay
ovpn-client[3396]: Attempting to establish TCP connection with [AF_INET]X.X.X.X:1194 [nonblock]
ovpn-client[3396]: TCP connection established with [AF_INET]X.X.X.X:1194
ovpn-client[3396]: TCPv4_CLIENT link local: [undef]
ovpn-client[3396]: TCPv4_CLIENT link remote: [AF_INET]X.X.X.X:1194
ovpn-client[3396]: VERIFY OK: depth=1, [...]
ovpn-client[3396]: VERIFY OK: depth=0, [...]
ovpn-client[3396]: Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
ovpn-client[3396]: Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
ovpn-client[3396]: Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
ovpn-client[3396]: Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
ovpn-client[3396]: Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA
ovpn-client[3396]: [VPN-Server] Peer Connection Initiated with [AF_INET]X.X.X.X:1194
ovpn-client[3396]: TUN/TAP device tun0 opened
ovpn-client[3396]: do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
ovpn-client[3396]: /sbin/ip link set dev tun0 up mtu 1500
NetworkManager[556]: <info> (tun0): carrier is OFF
NetworkManager[556]: <info> (tun0): new Tun device (driver: 'unknown' ifindex: 15)
NetworkManager[556]: <info> (tun0): exported as /org/freedesktop/NetworkManager/Devices/14
ovpn-client[3396]: /sbin/ip addr add dev tun0 local 10.11.12.14 peer 10.11.12.13
NetworkManager[556]: <info> (tun0): link connected
ovpn-client[3396]: ERROR: Linux route add command failed: external program exited with error status: 2
ovpn-client[3396]: GID set to nogroup
ovpn-client[3396]: UID set to nobody
ovpn-client[3396]: Initialization Sequence Completed
NetworkManager[556]: <info> (tun0): device state change: unmanaged -> unavailable (reason 'connection-assumed') [10 20 41]
NetworkManager[556]: <info> (tun0): device state change: unavailable -> disconnected (reason 'connection-assumed') [20 30 41]
NetworkManager[556]: <info> Activation (tun0) starting connection 'tun0'
NetworkManager[556]: <info> Activation (tun0) Stage 1 of 5 (Device Prepare) scheduled...
NetworkManager[556]: <info> devices added (path: /sys/devices/virtual/net/tun0, iface: tun0)
NetworkManager[556]: <info> device added (path: /sys/devices/virtual/net/tun0, iface: tun0): no ifupdown configuration found.
NetworkManager[556]: <info> Activation (tun0) Stage 1 of 5 (Device Prepare) started...
NetworkManager[556]: <info> (tun0): device state change: disconnected -> prepare (reason 'none') [30 40 0]
NetworkManager[556]: <info> Activation (tun0) Stage 2 of 5 (Device Configure) scheduled...
NetworkManager[556]: <info> Activation (tun0) Stage 1 of 5 (Device Prepare) complete.
NetworkManager[556]: <info> Activation (tun0) Stage 2 of 5 (Device Configure) starting...
NetworkManager[556]: <info> (tun0): device state change: prepare -> config (reason 'none') [40 50 0]
NetworkManager[556]: <info> Activation (tun0) Stage 2 of 5 (Device Configure) successful.
NetworkManager[556]: <info> Activation (tun0) Stage 3 of 5 (IP Configure Start) scheduled.
NetworkManager[556]: <info> Activation (tun0) Stage 2 of 5 (Device Configure) complete.
NetworkManager[556]: <info> Activation (tun0) Stage 3 of 5 (IP Configure Start) started...
NetworkManager[556]: <info> (tun0): device state change: config -> ip-config (reason 'none') [50 70 0]
NetworkManager[556]: <info> Activation (tun0) Stage 5 of 5 (IPv4 Configure Commit) scheduled...
NetworkManager[556]: <info> Activation (tun0) Stage 3 of 5 (IP Configure Start) complete.
NetworkManager[556]: <info> Activation (tun0) Stage 5 of 5 (IPv4 Commit) started...
NetworkManager[556]: <info> (tun0): device state change: ip-config -> ip-check (reason 'none') [70 80 0]
NetworkManager[556]: <info> Activation (tun0) Stage 5 of 5 (IPv4 Commit) complete.
NetworkManager[556]: <info> (tun0): device state change: ip-check -> secondaries (reason 'none') [80 90 0]
NetworkManager[556]: <info> (tun0): device state change: secondaries -> activated (reason 'none') [90 100 0]
NetworkManager[556]: <info> Activation (tun0) successful, device activated.

Meine Fragen sind:

  1. Stimmt die Routingtabelle? Bei mir sieht sie aufgrund der beiden Standardeinträge etwas komisch aus. Außerdem wird beim Aufzeichnen des Datenverkehrs auf dem öffentlichen WLAN-Router (mit tcpdump) nicht der gesamte Datenverkehr über VPN geleitet.

  2. Was sagt der Fehler ( ERROR: Linux route add command failed: external program exited with error status: 2) im Syslog? Hängt er vielleicht mit der ersten Frage zusammen?

Edit: Danke für die Antwort, Michal. Um den Multicast-/Lokal-/...-Verkehr zu reduzieren, plane ich zusätzlich, iptables zu verwenden, um auch diesen Verkehr zu unterbinden.

Ich versuche, die iptables-Regeln wie folgt anzuwenden:

#!/bin/bash

GATEWAY="192.168.178.1"

iptables -F

# Allow loopback device (internal communication)
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

# Allow DHCP communication with gateway
iptables -A INPUT -i wlan0 -p udp -s $GATEWAY/32 --dport 67:68 --sport 67:68 -j ACCEPT
iptables -A OUTPUT -o wlan0 -p udp -d $GATEWAY/32 --dport 67:68 --sport 67:68 -j ACCEPT

# Allow ICMP communication with gateway
iptables -A INPUT -i wlan0 -p icmp -s $GATEWAY/32 -j ACCEPT
iptables -A OUTPUT -o wlan0 -p icmp -d $GATEWAY/32 -j ACCEPT

#Allow VPN establishment
iptables -A OUTPUT -p tcp --dport 1194 -j ACCEPT
iptables -A INPUT -p tcp --sport 1194 -j ACCEPT

#Accept all TUN connections (tun = VPN tunnel)
iptables -A OUTPUT -o tun+ -j ACCEPT
iptables -A INPUT -i tun+ -j ACCEPT

#Set default policies to drop all communication unless specifically allowed
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

Meiner Meinung nach sollten diese Regeln ausreichen, um eine IP-Adresse vom Gateway zu erhalten, eine Verbindung zum OpenVPN-Server herzustellen und den gesamten Datenverkehr über diese Verbindung abzuwickeln. DNS funktioniert jedoch nicht, obwohl es auch die VPN-Verbindung verwenden soll. Warum funktioniert das nicht?

Nächste Änderung: Richten Sie einen lokalen Nameserver ( dnsmasq) auf dem VPN-Server ein. Die Serverkonfiguration wurde geändert in

push "dhcp-option DNS 10.11.12.1"

anstatt

push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"

Beim Ausführen dig +short serverfault.com @10.11.12.1auf dem VPN-Server selbst konnte der Hostname erfolgreich abgerufen werden. Wird der Befehl auf einem anderen Host ausgeführt, der kein VPN verwendet ( dig +short stackoverflow.com @X.X.X.X), konnte der Hostname ebenfalls erfolgreich abgerufen werden. Wird der Befehl jedoch auf einem Client ausgeführt, der mit dem VPN verbunden ist ( dig +short stackoverflow.com @10.11.12.1), schlägt der Befehl fehl ( ;; connection timed out; no servers could be reached). Warum? Iptables ist so eingestellt, dass alles akzeptiert wird.

Antwort1

  1. Die Routing-Tabelle sieht in Ordnung aus. Sehen Sie sich die Metrikspalte an. Die Route mit der niedrigsten Metrik wird bevorzugt. Ihre Routing-Tabelle enthält jetzt zwei Standardrouten und 10.11.12.13 wird aufgrund der niedrigeren Metrik gegenüber 192.168.178.1 bevorzugt. Was den Datenverkehr auf der physischen Schnittstelle betrifft: Dies ist auch normal, da Sie Abhördienste haben, die auf Broadcast-/Multicast-Datenverkehr reagieren. Dieser Datenverkehr kann nicht über die VPN-Schnittstelle laufen. Dies ist auch ein Zeichen für einige Anwendungen, die das lokale Netzwerk verwenden, um Dinge zu beschleunigen, zum Beispiel: Dropbox, Teamviewer, UPnP, Microsoft Network Neighborhood und viele, viele andere Funktionen.
  2. Das liegt höchstwahrscheinlich daran, dass /sbin/route oder /usr/sbin/route keine Berechtigung hatten, etwas zu tun, weil Sie in Ihren Konfigurationsdateien die Anweisung verwendet haben, die Dienstberechtigungen von OpenVPN auf den Benutzer nobody zu setzen. Nach der erneuten Verbindung kann es solche Dinge melden. Insbesondere, wenn Sie die Konfiguration des Servers ändern und den Client nicht manuell mit vollen Berechtigungen neu starten. Das ist auch normal.

PS. Sie benötigen „resolv-retry-infinite“ nicht, wenn Sie „remote“ mit IP-Adresse verwenden, das ergibt keinen Sinn.

BEARBEITEN: iptables-Konfiguration Ich gehe davon aus, dass dies die Iptables-Konfiguration des Clients ist.

  1. Sie sollten auch die NAT-Tabelle leeren:

iptables -F -t nat

  1. Aus zwei Gründen benötigen Sie keine Regeln für die DHCP-Kommunikation:
    • DHCP-Dienste verwenden normalerweise so genannte Raw Sockets, die nicht von iptables abgedeckt werden (als ich es das letzte Mal überprüft habe, haben dhcpd und dhcpcd sie verwendet).
    • Der DHCP-Mechanismus ist im OpenVPN-Protokoll implementiert, daher gibt es keine eigentliche DHCP-Kommunikation, ich meine DHCP-Anforderung, DHCP-Angebot, DHCP-ACK, DHCP-Paket.
  2. Die Verwendung von OpenVPN im TCP-Modus ist keine gute Idee:http://sites.inka.de/bigred/devel/tcp-tcp.html
  3. Bitte bearbeiten Sie Ihre Frage und teilen Sie mir mit, ob:
    • können Sie vom Client aus (Tunnelkommunikation) den VPN-Server (VPN-IP-Adresse) anpingen?
    • zeig mir netstat -l -u -n -p vom Server (wir müssen wissen, ob Ihr dnsmasq-Daemon auf der Tun-Schnittstelle lauscht),
    • können Sie 8.8.8.8 anpingen, nachdem das VPN eingerichtet wurde?

verwandte Informationen