4 votos

¿Cómo puedo obligar a todo el tráfico de internet a través de una VPN PPTP, pero todavía permiten a los gobiernos locales de acceso a la lan?

Tengo un servidor con Linux Mint 12 que quiero seguir conectado a una VPN de PPTP todo el tiempo. El servidor VPN es bastante fiable, pero cae en una ocasión tan sólo quiero hacer para que toda la actividad en internet está desactivada si la conexión VPN está roto.

También me gustaría encontrar una manera de reiniciar automáticamente, pero que no es tan grande de un problema ya que esto sucede muy rara vez.

También quiero siempre ser capaz de conectarse a la caja de mi lan, independientemente de si el VPN es o no.

He aquí lo que mis ifconfig parece que con el VPN conectado correctamente:

eth0      Link encap:Ethernet  HWaddr 00:22:15:21:59:9a  
          inet addr:192.168.0.171  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: fe80::222:15ff:fe21:599a/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:37389 errors:0 dropped:0 overruns:0 frame:0
          TX packets:29028 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:37781384 (37.7 MB)  TX bytes:19281394 (19.2 MB)
          Interrupt:41 Base address:0x8000 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:1446 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1446 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:472178 (472.1 KB)  TX bytes:472178 (472.1 KB)

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:10.10.11.10  P-t-P:10.10.11.9  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:14 errors:0 dropped:0 overruns:0 frame:0
          TX packets:23 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:1368 (1.3 KB)  TX bytes:1812 (1.8 KB)

He aquí un script de iptables he encontrado en otro lugar que parecía ser para el problema que estoy tratando de resolver, pero la herida hasta el bloqueo de todos los accesos, pero no estoy seguro de lo que tengo para cambiar:

#!/bin/bash

#Set variables
IPT=/sbin/iptables
VPN=`ifconfig|perl -nE'/dr:(\S+)/&&say$1'|grep 10.`
LAN=192.168.0.0/24

#Flush rules
$IPT -F
$IPT -X

#Default policies and define chains
$IPT -P OUTPUT DROP
$IPT -P INPUT DROP
$IPT -P FORWARD DROP

#Allow input from LAN and tun0 ONLY
$IPT -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
$IPT -A INPUT -i lo -j ACCEPT
$IPT -A INPUT -i tun0 -m conntrack --ctstate NEW -j ACCEPT
$IPT -A INPUT -s $LAN -m conntrack --ctstate NEW -j ACCEPT
$IPT -A INPUT -j DROP

#Allow output from lo and tun0 ONLY
$IPT -A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
$IPT -A OUTPUT -o lo -j ACCEPT
$IPT -A OUTPUT -o tun0 -m conntrack --ctstate NEW -j ACCEPT
$IPT -A OUTPUT -d $VPN -m conntrack --ctstate NEW -j ACCEPT
$IPT -A OUTPUT -j DROP
exit 0

Gracias por tu ayuda.

3voto

mgorven Puntos 19205

Esas reglas iptables no permitir el tráfico hacia el servidor VPN, por lo que el VPN no puede ser establecido. Usted necesita las siguientes reglas en la OUTPUT de la cadena antes de la final DROP de regla, donde 1.2.3.4 es la dirección IP del servidor VPN. Estos permiten que las conexiones TCP al puerto 1723 (el canal de control PPTP) y paquetes GRE (el canal de datos).

iptables --append OUTPUT --destination 1.2.3.4 --protocol tcp --dport 1723 --jump ACCEPT
iptables --append OUTPUT --destination 1.2.3.4 --protocol gre --jump ACCEPT

2voto

mgorven Puntos 19205

Existen dos enfoques para esto, enrutamiento basado y firewall de base.

Enrutamiento de enfoque

La típica tabla de enrutamiento de un equipo no está conectado a una VPN se ve algo como esto:

10.23.11.0/24 dev eth0
default via 10.23.11.1

La primera es la ruta a los hosts en la LAN, y la segunda ruta envía todo lo demás a la puerta de enlace predeterminada. Cuando está conectado a una VPN la tabla de enrutamiento se ve algo como esto (donde 1.2.3.4 es del servidor de VPN IP pública, y 10.8.0.1 es del servidor de VPN IP privada):

10.23.11.0/24 dev eth0
1.2.3.4 via 10.23.11.1
default via 10.8.0.1

La primera ruta es la misma, y la tercera ruta es lo envía todo a través de la VPN. Nota a la segunda regla, sin embargo: se dice que para llegar al servidor VPN IP pública paquetes deben ser enviados a través de la puerta de enlace predeterminada. Esto es para que el catéter de paquetes creado por el cliente VPN realmente alcanzar el servidor; si esta ruta no está en su lugar los paquetes creados por el cliente VPN sería enviada a través de la VPN de nuevo, y nunca llegar al servidor.

Ahora, si la tercera ruta es removida, los paquetes destinados a cualquier lugar en Internet, aparte de que el servidor VPN no habría una ruta coincidente, y así, el anfitrión nunca enviar. Por lo tanto queremos que la tabla de enrutamiento a este aspecto cuando el VPN no está conectado:

10.23.11.0/24 dev eth0
1.2.3.4 via 10.23.11.1

Los Hosts en la LAN todavía puede ser alcanzado, y el servidor VPN todavía puede ser alcanzado (ya que tenemos que ser capaces de iniciar el VPN), pero todo lo demás no será derrotado. Conseguir esta configuración puede ser un poco complicado, especialmente si usted está usando DHCP. Una configuración estática en Debian serían las siguientes en /etc/network/interfaces sin embargo:

auto eth0
iface eth0 inet static
    address 10.23.11.10
    netmask 255.255.255.0
    up ip route add 1.2.3.4 via 10.23.11.1

Tenga en cuenta que no hay ninguna gateway declaración, ya que esto es lo que instala la ruta por defecto.

La desventaja de este enfoque es que los no-tráfico de la VPN con el servidor VPN está permitido a cabo sin cifrar. Si ejecuta otros servicios en el servidor VPN y la necesidad de asegurarse de que están protegidos, entonces usted tendrá que utilizar el firewall de enfoque.

Edit: @JamesRyan sugiere que este enfoque es frágil porque con una ruta por defecto podría ser añadido de forma automática o de forma accidental. Otro enfoque es el de agregar un blackhole ruta, que envía el tráfico en algún lugar que no es la ruta más. Esto no funcionará con un agregado automáticamente ruta predeterminada sin embargo, debido a que ya utiliza la más alta prioridad métrica de 0. La ruta predeterminada todavía debe ser eliminado, pero algo como la siguiente puede ser añadida.

default via 127.255.255.255

Firewall de enfoque

La idea aquí es para bloquear todo el tráfico saliente en la interfaz física aparte de la tunelizados tráfico creado por el cliente VPN y el tráfico destinado a la red LAN. El tráfico para permitir que el VPN depende del protocolo utilizado. PPTP utiliza el puerto TCP 1723 como un canal de control, y GRE como el actual túnel. OpenVPN utiliza el puerto UDP 1194. Las reglas de firewall sería algo como esto:

iptables --append OUTPUT --out-interface eth0 --destination 10.23.11.0/24 --jump ACCEPT
iptables --append OUTPUT --out-interface eth0 --destination 1.2.3.4 --protocol tcp --dport 1723 --jump ACCEPT
iptables --append OUTPUT --out-interface eth0 --destination 1.2.3.4 --protocol gre --jump ACCEPT
iptables --append OUTPUT --out-interface eth0 --jump REJECT

La primera regla acepta el tráfico de la LAN. La segunda y tercera reglas de aceptar el tráfico de la VPN con el servidor VPN. La cuarta regla rechaza todo el tráfico de salir de la interfaz física.

La otra cosa que usted puede necesitar para aceptar es el DNS si utiliza un servidor DNS no en la LAN, debido a que el cliente VPN probablemente se necesita para hacer una búsqueda de DNS con el fin de encontrar el servidor VPN. La siguiente regla se inserta antes del REJECT permitiría tráfico de DNS público de Google el servicio de DNS.

iptables --append OUTPUT --out-interface eth0 --destination 8.8.8.8 --protocol udp --dport 53 --jump ACCEPT

1voto

JamesRyan Puntos 6644

Añadir otra ruta por defecto con una métrica superior apuntando a null interfaz. Cuando el VPN no está disponible la 2ª ruta de la patada en y eliminar el tráfico

0voto

mulaz Puntos 7774

Este no es un iptables queston - usted no necesita iptables para que.

Acaba de establecer el valor predeterminado es la ruta para ir a través de la VPN, y listo. Usted puede también agregar otra ruta predeterminada con un peor métrica, cuando el VPN es hacia abajo.

Su LAN está conectado directamente, por lo que tiene prioridad por encima de la puerta de enlace predeterminada.

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: