Problema con Debian con configuración de red para Openvpn
DesconectadoBuenas a todos, por normas he tenido que crear un nuevo tema para mi consulta. Les cuento, estoy trabajando con debian 5.0 sólo el sistema base para una configuración de Openvpn con dos interfaces de red, una para la red local LAN y otra interfaz para internet. Configuro todo bien, todo funciona perfecto, hasta que pasan unos 30 minutos y la red se cae, debo reiniciar el equipo o reiniciar los servicios de red para que vuelva a la normalidad.
eth0
10.6.127.168
255.255.255.0
10.6.127.1
sin DNS
eth1
200.111.96.X
255.255.255.248
200.111.96.X
DNS 200.72.1.5 200.72.1.11
Las únicas configuraciones que he hecho han sido permitir el reenvío de puertos ipv4 y agregar esta regla al iptables que por lo que tengo entendido es para que enmascare los pedidos a la red interna. 10.1.1.0 es la subred de donde se le asignan ips a los clientes provenientes de la internet.
iptables -t nat -A POSTROUTING -s 10.1.1.0/24 -o eth0 -j MASQUERADE
instalé openvpn según este artículo.
PS: Pasó algo extraño que mientras redactaba el tema, la VPN se conectó misteriosamente pero sigo sin ping al servidor. Pienso que debe ser un problema de rutas talvez, donde las interfaces no saben como trabajar con los flujos.
Espero sus comentarios.
Saludos =)
- Inicie sesión o regístrese para enviar comentarios
- 1875 lecturas
Ya te comenté en http://www.esdebian.org/foro/39251/debian-2-tarjetas-red-ip-publica-e-ip..., pero sigo sin saber de dónde sale esa red 10.1.1.0/24 ¿Podrías deleitarnos en modo gráfico cómo se encuentra estructurada tu red?
Saludos
A ver, para configurar un servidor VPN se le asigna una subred de direcciones a los equipos remotos, que en mi caso viene siendo 10.1.1.0/24, como podría también haber sido 192.168.1.0/24, entonces cada equipo remoto que se conecta desde internet para poder navegar por la red local del complejo, se conecta al servidor VPN con una dirección asignada dentro de la subred 10.1.1.0/24. Eso es con respecto a la configuración del /etc/openvpn/server.conf
Ahora creo que por ahí no va precisamente el problema, ya que al reiniciar los servicios de red puedo conectarme por openvpn hacia la red local sin ningún problema. Creo que quizás me estoy equivocando en la configuración de las interfaces. Este es mi archivo interfaces:
auto lo
iface lo inet loopback
allow-hotplug eth1
iface eth1 inet static
adress 200.111.96.X
netmask 255.255.255.248
network 200.111.96.0
broadcast 200.111.96.255
gateway 200.111.96.X
dns-nameservers 200.72.1.5 200.72.1.11
iface eth0 inet static
adress 10.6.127.168
netmask 255.255.255.0
gateway 10.6.127.1
Destaco que tengo un script que se ejecuta al inicio de debian para levantar la interfaz eth0.
Por otra parte, en syslog veo estos registros a la hora de la caída.
inactivity timeout (--ping-restart), restarting
[soft, ping-restart] received, client-instance restarting
El diagrama es algo parecido a esto:
Las subredes 10.6.X.0 son VLANS
Saludos.
A ver, para configurar un servidor VPN se le asigna una subred de direcciones a los equipos remotos, que en mi caso viene siendo 10.1.1.0/24, como podría también haber sido 192.168.1.0/24, entonces cada equipo remoto que se conecta desde internet para poder navegar por la red local del complejo, se conecta al servidor VPN con una dirección asignada dentro de la subred 10.1.1.0/24. Eso es con respecto a la configuración del /etc/openvpn/server.conf
Ahora creo que por ahí no va precisamente el problema, ya que al reiniciar los servicios de red puedo conectarme por openvpn hacia la red local sin ningún problema. Creo que quizás me estoy equivocando en la configuración de las interfaces. Este es mi archivo interfaces:
auto lo
iface lo inet loopback
allow-hotplug eth1
iface eth1 inet static
adress 200.111.96.X
netmask 255.255.255.248
network 200.111.96.0
broadcast 200.111.96.255
gateway 200.111.96.X
dns-nameservers 200.72.1.5 200.72.1.11
iface eth0 inet static
adress 10.6.127.168
netmask 255.255.255.0
gateway 10.6.127.1
Destaco que tengo un script que se ejecuta al inicio de debian para levantar la interfaz eth0.
Por otra parte, en syslog veo estos registros a la hora de la caída.
inactivity timeout (--ping-restart), restarting
[soft, ping-restart] received, client-instance restarting
El diagrama es algo parecido a esto:
Las subredes 10.6.X.0 son VLANS
Saludos.
Y dónde entra en este esquema tu regla de iptables:
iptables -t nat -A POSTROUTING -s 10.1.1.0/24 -o eth0 -j MASQUERADEporque no veo ninguna red 10.1.1.0
Otra vez, 10.1.1.0/24 es un espacio de direcciones virtuales asignado para que el servidor VPN reparta a los usuarios remotos. Cuando me conecto por ejemplo a la red local como usuario remoto desde internet, la VPN me asigna 10.1.1.14. Tan difícil es de entender.
Otra vez, 10.1.1.0/24 es un espacio de direcciones virtuales asignado para que el servidor VPN reparta a los usuarios remotos. Cuando me conecto por ejemplo a la red local como usuario remoto desde internet, la VPN me asigna 10.1.1.14. Tan difícil es de entender.
Ok, la red 10.1.1.0 es la cara hacia afuera de tu vpn y la cara hacia adentro es la 200.111.96.x es la cara interna?
Algo mas claro aún, eth0 es la conexión a la LAN, eth1 es la conexión a internet y tun0 es la interfaz virtual que hace que vpn funcione y tomará un valor de 10.1.1.0. Por lo tanto, la dirección del servidor hacia internet es 200.111.96.X, la dirección del servidor para la LAN 10.6.127.168 y la dirección que toma el usuario remoto será parte de la subred 10.1.1.0. Entonces en la LAN mi usuario remoto tiene dirección ip 10.1.1.14.
Algo mas claro aún, eth0 es la conexión a la LAN, eth1 es la conexión a internet y tun0 es la interfaz virtual que hace que vpn funcione y tomará un valor de 10.1.1.0. Por lo tanto, la dirección del servidor hacia internet es 200.111.96.X, la dirección del servidor para la LAN 10.6.127.168 y la dirección que toma el usuario remoto será parte de la subred 10.1.1.0. Entonces en la LAN mi usuario remoto tiene dirección ip 10.1.1.14.
OK, eth0 es LAN (10.6.127.x)
iptables -t nat -A POSTROUTING -s 10.1.1.0/24 -o eth0 -j MASQUERADEestás nateando todo origen 10.1.1.x a eth0
eth1 es WAN (200.111.96.x)
podrías poner tu server.conf?
Bien, creo que el problema puede deberse tanto a un error en la regla MASQUERADE de Iptables como en el /etc/openvpn/server.conf.
Como he reiterado, modificaría dicha regla, pero esta vez en el siguiente sentido:
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADEcon ello permitimos la salida a internet a través de la interfaz eth1 desde cualquier origen.
Ahora, para que los clientes Road Warriors puedan ver la red interna del servidor, debes comprobar que se encuentra configurada la línea que a continuación relaciono en tu /etc/openvpn/server.conf:
push "route dirección_de_red máscara_de_subred"No obstante y como te dice el usuario ratakruel, no estaría de más que postearas el contenido del archivo de configuracíon del server openvpn.
Por último, en tu estructura de red, no logro comprender el motivo de crear una vlan para un sólo host, a menos que quieras aislarlos del resto de equipos
¿Los dispositivos de acceso (los más cercanos a las máquinas) son todo switches? ¿Y el de núcleo o distribución (el más cercano a la nube), también es un switch o se trata de un router?
Saludos
Yo tengo openvpn en Etch desde hace dos años y toda va como la seda, la unica diferencia es que yo no tengo montado vlan, y en mi caso el servidor que hace de openvpn no es el gateway por defecto. Varias cosas que comentarte.
No entiendo por que tienes que hacer nat, la gente se conecta desde internet a la ip publica por el puerto udp de la vpn, y en el router(no sé si es ahí donde segmentas la red en vlanes) redireccionar a la ip de tu servidor de vpn. No necesitas nada mas.... sí!!!! pòrque con solo esto solo accedes al servidor, si quieres acceder a terceros en la lan tienen que saber para el tráfico de vuelta(lan->vpn->pc remoto) por donde tienen que pasar, para eso yo tengo en el servicio dhcp que informa de dos gateways, uno de ellos es el de salida a internet y el segundo el propio servidor vpn, vamos el camino de vuelta, el dichoso camino de vuelta que siempre olvidamos!!!!!!!
Evidentemente la conexión tiene que ser correcta,,,, y si no te fias puedes tirar de netcat, para probar el trafico udp en dicho puerto entre dos equipos remotos.
Estimados, en el esquema donde hay un host por VLAN es representativo, ya que existen cerca de 600 equipos en la red local repartidos en esos 4 segmentos. Acabo de corregir la regla como dice quilloquepasa
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADEy voy a ver los resultados.Les dejo mi server.conf
port 1194proto tcp
dev tun
persist-tun
ca ca.crt
cert servidor.crt
key servidor.key
dh dh1024.pem
#Direcciones que se asignaran a los clientes
server 10.1.1.0 255.255.255.0
ifconfig-pool-persist ipp.txt
#Ruta para que los clientes alcancen la red local del server
push "route 10.6.127.0 255.255.255.0"
push "route 10.6.128.0 255.255.255.0"
push "route 10.6.129.0 255.255.255.0"
push "route 10.6.130.0 255.255.255.0"
#Para que los clientes se visualicen entre ellos
#Debe ir junto con la opci�n routeback en el shorewall
client-to-client
keepalive 20 600
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
verb 3
Cambie mi protocolo a TCP ya que UDP no tiene control de flujo ni cosas por estilo. Pero aún la caída persiste.
ZorroPlateado tu servidor VPN ¿mantiene un flujo constante de información entre los clientes y el servidor? o ¿pasan tiempos en que no existe tráfico en la red?, pregunto esto ya que en algunos foros de Openvpn comentan que el error que les comentaba y las caídas de la conexión se debían a la inactividad de la red VPN.
saludos y gracias por los comentarios.