☰

Enrutamiento OpenVPN: múltiples entradas predeterminadas. Cliente OpenVPN: iptables. Problemas de DNS

tag-icon • tag-icon domain-name-system iptables routing openvpn dnsmasq
Enrutamiento OpenVPN: múltiples entradas predeterminadas. Cliente OpenVPN: iptables. Problemas de DNS

Estoy ejecutando un servidor OpenVPN (Debian 8) por motivos de privacidad cuando uso wifi público. Por lo tanto, todo el tráfico de red del cliente debe manejarse a través de la conexión VPN. La configuración del servidor y del cliente se proporciona a continuación.

Configuración del servidor:

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

Configuración del cliente:

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

Cuando se inicia el servicio VPN en el cliente, la tabla de enrutamiento se modifica como se indica a continuación.

Tabla de enrutamiento (192.168.178.0/24 indica wifi pública):

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

La sección relevante del syslog al iniciar 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.

Mis preguntas son:

  1. ¿Es correcta la tabla de enrutamiento? Para mí, parece algo extraño debido a las dos entradas predeterminadas. Además, al registrar el tráfico en el enrutador wifi público (usando tcpdump), no todo el tráfico se enruta a través de VPN.

  2. ¿Qué dice el error ( ERROR: Linux route add command failed: external program exited with error status: 2) en el syslog? ¿Quizás esté relacionado con la primera pregunta?

Editar: Gracias por la respuesta, Michal. Para reducir el tráfico de multidifusión/local/..., también planeo usar iptables para reducir ese tráfico.

Estoy intentando utilizar las reglas de iptables de la siguiente manera:

#!/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

En mi opinión, estas reglas deberían ser suficientes para obtener una IP asignada por la puerta de enlace, establecer una conexión con el servidor OpenVPN y manejar todo el tráfico a través de esa conexión. Pero DNS no funciona, aunque también se supone que utiliza la conexión VPN. ¿Por qué eso no funciona?

Siguiente edición: configure un servidor de nombres local ( dnsmasq) en el servidor VPN. La configuración del servidor cambió a

push "dhcp-option DNS 10.11.12.1"

en lugar de

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

Cuando se ejecuta dig +short serverfault.com @10.11.12.1en el servidor VPN, el nombre de host se pudo recuperar correctamente. Si el comando se ejecuta en un host diferente que no utiliza VPN ( dig +short stackoverflow.com @X.X.X.X), el nombre del host también podría recuperarse exitosamente. Sin embargo, cuando el comando se ejecuta en un cliente conectado a la VPN ( dig +short stackoverflow.com @10.11.12.1), el comando falla ( ;; connection timed out; no servers could be reached). ¿Por qué? Iptables está configurado para ACEPTAR todo.

Respuesta1

  1. La tabla de enrutamiento se ve bien, mire la columna de métricas. Se preferirá la ruta con la métrica más baja. Su tabla de enrutamiento contiene ahora dos rutas predeterminadas y se preferirá 10.11.12.13 a 192.168.178.1 debido a una métrica más baja. Sobre el tráfico en la interfaz física; Esto también es normal porque tiene servicios de escucha que responden al tráfico de transmisión/multidifusión. Este tráfico no puede pasar a través de la interfaz VPN. Esto también es una señal de que algunas aplicaciones utilizan la red local para acelerar las cosas, por ejemplo: Dropbox, Teamviewer, Upnp, Microsoft Network Neighborhood y muchas otras funcionalidades.
  2. Lo más probable es que 'porque /sbin/route o /usr/sbin/route no hayan tenido permiso para hacer algo, porque usó una directiva en sus archivos de configuración para eliminar los privilegios de servicio de openvpn al usuario nadie, después de volver a conectarse puede gritar sobre esas cosas . Especialmente cuando cambia la configuración del servidor y no reinicia el cliente manualmente con todos los privilegios. Eso también es normal.

PD. No necesita resolv-retry-infinite si usa control remoto con dirección IP, no tiene sentido.

EDITAR: configuración de iptables Supongo que esa es la configuración de iptables de Cleint.

  1. También deberías vaciar la tabla NAT:

iptables -F -t nat

  1. No necesita reglas para la comunicación DHCP por dos razones:
    • Los servicios DHCP generalmente usan los llamados sockets sin formato que no están cubiertos por iptables (la última vez que lo revisé, dhcpd, dhcpcd los estaban usando),
    • El mecanismo DHCP se implementa en el protocolo OpenVPN, por lo que no existe ninguna comunicación DHCP real, es decir, solicitud DHCP, oferta DHCP, ACK DHCP, paquete DHCP.
  2. Usar OpenVPN en modo TCP es una mala idea:http://sites.inka.de/bigred/devel/tcp-tcp.html
  3. Edite su pregunta y dígame si:
    • ¿Puede hacer ping al servidor VPN (dirección IP VPN) desde el cliente (comunicación de túnel)?
    • muéstrame netstat -l -u -n -p desde el servidor (necesitamos saber si tu demonio dnsmasq está escuchando en la interfaz tun),
    • ¿Puedes hacer ping a 8.8.8.8 después de que se estableció la VPN?

información relacionada