OpenVpn - todo Ok salvo en mi propia casa

Archivado
Pues veréis, he configurado una vpn para la empresa(una empresa pequeña sea dicho) que al parecer funciona bastante bien, a nadie le da fallo, todo el mundo consigue conectarse... todo el mundo salvo yo ironicamente. al principio pensaba que era por algun fallo de configuración ya que todos usan windows y yo linux, sin embargo, he probado con mi portatil, tambien linux y puedo acceder a la red vpn de mi empresa desde otras redes.... salvo la mia.

Alguien que entienda un poco y me de una pista para continuar investigando? se queda pillado en el punto
Fri Sep 18 19:44:28 2020 Initialization Sequence Completed


Muchas gracias
@alohl669

Si no funciona ni win2 ni en linux desde tu casa tal vez sea el router o modem, tendrás que abrir el puerto.

Puedes hacer una prueba conectando la PC al internet del teléfono y ver si funciona.



Es todo por ahora
Luces escribió:@alohl669

Si no funciona ni win2 ni en linux desde tu casa tal vez sea el router o modem, tendrás que abrir el puerto.

Puedes hacer una prueba conectando la PC al internet del teléfono y ver si funciona.



Es todo por ahora

Con el telefono entro(con la red movil del telefono), lo que nunca me habia planteado es abrir un puerto de salida en el router
Es muy complicado ayudarte si no das más datos. OpenVPN? Wireguard? Un log ayudaría bastante, lo que has pegado es demasiado genérico. Da a entender que la conexión llega a buen puerto pero no llega a establecerse.

Así a bote pronto yo me inclinaría a pensar que has instalado mal los certificados (en el caso de que lo hayas hecho a mano claro, como te dije no especificas qué estás usando para la conexión).
En linux no sirve con pegar los certificados en la carpeta, luego hay que modificar permisos.
Esto encajaría con mi primera premisa: la conexión llega a su destino pero al dar error por certificados no puede "pasar".

Lo de abrir puertos y demás en el router no es necesario siendo un cliente, no tiene sentido alguno (siempre teniendo en cuenta que tu red sea normalita, aunque si la has tocado de alguna forma tú mismo deberías de saberlo).
verdezito escribió:Lo de abrir puertos y demás en el router no es necesario siendo un cliente, no tiene sentido alguno (siempre teniendo en cuenta que tu red sea normalita, aunque si la has tocado de alguna forma tú mismo deberías de saberlo).

Eso me cuadra mas.

verdezito escribió:Así a bote pronto yo me inclinaría a pensar que has instalado mal los certificados (en el caso de que lo hayas hecho a mano claro, como te dije no especificas qué estás usando para la conexión).
En linux no sirve con pegar los certificados en la carpeta, luego hay que modificar permisos.
Esto encajaría con mi primera premisa: la conexión llega a su destino pero al dar error por certificados no puede "pasar".

Pues podría ser una buena pista el tema de los permisos, por lo menos es algo nuevo que no me esperaba, las diferencias que he encontrado de linux a windows en realidad no es tema de permisos sino de hecho entre diferentes distros de linux, ya que en algunas es necesario indicar en el certificado la ruta del update-resolv-conf, sin embargo en el mismo ordenador linux en distintas redes si establece la conexión y en la mia no.

verdezito escribió:Es muy complicado ayudarte si no das más datos. OpenVPN? Wireguard? Un log ayudaría bastante, lo que has pegado es demasiado genérico. Da a entender que la conexión llega a buen puerto pero no llega a establecerse.


Correcto, ahi tienes toda la razón, he dado poca info.

Para crear la vpn he usado openVPN y he seguido un buen tutorial de nuestros amigos de digital ocean, todo lo que he visto de vpns sin enteder mucho siempre tiene su complicación, sin embargo en este caso se hace bastante comprensible y llevadero.

Como todo en la vida las condiciones no son exactas y no he trabajado con ubuntu server, sino con centos 7 para el servidor VPN(abriendo los puertos en firewald y gestionando los permisos de SELinux) y debian9.12 para la CA.
La parte del servidor parece bastante correcta pues el único problema lo he tenido yo y solo desde la red local de mi casa. el resto de clientes no han tenido ningún problema, hasta ahora han funcionado los dos últimos clientes de la versión community de openvpn desde windows.

En mi caso, tengo un portatil con kubuntu 18.04, el cliente de openvpn es el utlimo hasta la fecha disponible en los repositorios de la distribución. Ese portatil consigue conectarse desde una red de datos de telefonia movil sin problemas y desde la red local de un pariente. Sin embargo con el mismo certificado y las mismas condiciones(solo cambia la red) no lo he conseguido desde mi propia red local.

Ahora mismo no tengo ese portatil a mano, pero si una distribución basada en este caso en ubuntu 20.04 como pc de escritorio en mi casa con el mismo error y mismo certificado. he aqui el log:

[sudo] contraseña para alohl669:
Fri Sep 18 21:39:52 2020 OpenVPN 2.4.7 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Sep  5 2019
Fri Sep 18 21:39:52 2020 library versions: OpenSSL 1.1.1f  31 Mar 2020, LZO 2.10
Fri Sep 18 21:39:52 2020 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Fri Sep 18 21:39:52 2020 Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
Fri Sep 18 21:39:52 2020 Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
Fri Sep 18 21:39:52 2020 TCP/UDP: Preserving recently used remote address: [AF_INET]229.165.15.11:9988
Fri Sep 18 21:39:52 2020 Socket Buffers: R=[212992->212992] S=[212992->212992]
Fri Sep 18 21:39:52 2020 UDP link local: (not bound)
Fri Sep 18 21:39:52 2020 UDP link remote: [AF_INET]229.165.15.11:9988
Fri Sep 18 21:39:52 2020 NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay
Fri Sep 18 21:39:52 2020 TLS: Initial packet from [AF_INET]229.165.15.11:9988, sid=3f884jf1 5b7fedb5
Fri Sep 18 21:39:52 2020 VERIFY OK: depth=1, CN=jajejica
Fri Sep 18 21:39:52 2020 VERIFY KU OK
Fri Sep 18 21:39:52 2020 Validating certificate extended key usage
Fri Sep 18 21:39:52 2020 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Fri Sep 18 21:39:52 2020 VERIFY EKU OK
Fri Sep 18 21:39:52 2020 VERIFY OK: depth=0, CN=jajejivpn
Fri Sep 18 21:39:52 2020 Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
Fri Sep 18 21:39:52 2020 [jajejivpn] Peer Connection Initiated with [AF_INET]229.165.15.11:9988
Fri Sep 18 21:39:53 2020 SENT CONTROL [jajejivpn]: 'PUSH_REQUEST' (status=1)
Fri Sep 18 21:39:53 2020 PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1 bypass-dhcp,dhcp-option DNS 208.67.222.222,dhcp-option DNS 208.67.220.220,route 10.8.0.1,topology net30,ping 10,ping-restart 120,ifconfig 10.8.0.6 10.8.0.5,peer-id 0,cipher AES-256-GCM'
Fri Sep 18 21:39:53 2020 OPTIONS IMPORT: timers and/or timeouts modified
Fri Sep 18 21:39:53 2020 OPTIONS IMPORT: --ifconfig/up options modified
Fri Sep 18 21:39:53 2020 OPTIONS IMPORT: route options modified
Fri Sep 18 21:39:53 2020 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Fri Sep 18 21:39:53 2020 OPTIONS IMPORT: peer-id set
Fri Sep 18 21:39:53 2020 OPTIONS IMPORT: adjusting link_mtu to 1624
Fri Sep 18 21:39:53 2020 OPTIONS IMPORT: data channel crypto options modified
Fri Sep 18 21:39:53 2020 Data Channel: using negotiated cipher 'AES-256-GCM'
Fri Sep 18 21:39:53 2020 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Fri Sep 18 21:39:53 2020 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Fri Sep 18 21:39:53 2020 ROUTE_GATEWAY 192.168.1.1/255.255.255.0 IFACE=enp4s0 HWADDR=b4:2e:99:34:2b:ec
Fri Sep 18 21:39:53 2020 TUN/TAP device tun0 opened
Fri Sep 18 21:39:53 2020 TUN/TAP TX queue length set to 100
Fri Sep 18 21:39:53 2020 /sbin/ip link set dev tun0 up mtu 1500
Fri Sep 18 21:39:53 2020 /sbin/ip addr add dev tun0 local 10.8.0.6 peer 10.8.0.5
Fri Sep 18 21:39:53 2020 /etc/openvpn/update-resolv-conf tun0 1500 1552 10.8.0.6 10.8.0.5 init
Fri Sep 18 21:39:53 2020 /sbin/ip route add 229.165.15.11/32 via 192.168.1.1
RTNETLINK answers: File exists
Fri Sep 18 21:39:53 2020 ERROR: Linux route add command failed: external program exited with error status: 2
Fri Sep 18 21:39:53 2020 /sbin/ip route add 0.0.0.0/1 via 10.8.0.5
Fri Sep 18 21:39:53 2020 /sbin/ip route add 128.0.0.0/1 via 10.8.0.5
Fri Sep 18 21:39:53 2020 /sbin/ip route add 10.8.0.1/32 via 10.8.0.5
Fri Sep 18 21:39:53 2020 GID set to nogroup
Fri Sep 18 21:39:53 2020 UID set to nobody
Fri Sep 18 21:39:53 2020 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Fri Sep 18 21:39:53 2020 Initialization Sequence Completed



Aquí se queda pillado y no da la resolución.... Vale, aqui hago una pausa, porque hay un error con el que ya me he peleado, hay una linea "RTNETLINK answers: File exists" que podría ser indicativo de algo, ya me he peleado antes con esto, meses atrás, pero con el covid volviendo a pegar he retomado el tema, ese error "RTNETLINK answers: File exists" solo ocurria despues del primero intento fallido. por lo que he guardado el borrador de la respuesta y he reiniciado el pc para tener un log mas limpito sin ese error. No obstante lo dejo por si puediera aportar pistas extras. Este es el log sin ese error con el pc reiniciado:

alohl669@asimov:~$ sudo openvpn --config .ssh/ahl.ovpn
[sudo] contraseña para alohl669:
Fri Sep 18 22:02:20 2020 OpenVPN 2.4.7 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Sep  5 2019
Fri Sep 18 22:02:20 2020 library versions: OpenSSL 1.1.1f  31 Mar 2020, LZO 2.10
Fri Sep 18 22:02:20 2020 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Fri Sep 18 22:02:20 2020 Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
Fri Sep 18 22:02:20 2020 Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
Fri Sep 18 22:02:20 2020 TCP/UDP: Preserving recently used remote address: [AF_INET]229.165.15.11:9988
Fri Sep 18 22:02:20 2020 Socket Buffers: R=[212992->212992] S=[212992->212992]
Fri Sep 18 22:02:20 2020 UDP link local: (not bound)
Fri Sep 18 22:02:20 2020 UDP link remote: [AF_INET]229.165.15.11:9988
Fri Sep 18 22:02:20 2020 NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay
Fri Sep 18 22:02:20 2020 TLS: Initial packet from [AF_INET]229.165.15.11:9988, sid=f2cd2265 cc75eba1
Fri Sep 18 22:02:20 2020 VERIFY OK: depth=1, CN=jajejica
Fri Sep 18 22:02:20 2020 VERIFY KU OK
Fri Sep 18 22:02:20 2020 Validating certificate extended key usage
Fri Sep 18 22:02:20 2020 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Fri Sep 18 22:02:20 2020 VERIFY EKU OK
Fri Sep 18 22:02:20 2020 VERIFY OK: depth=0, CN=jajejivpn
Fri Sep 18 22:02:20 2020 Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
Fri Sep 18 22:02:20 2020 [jajejivpn] Peer Connection Initiated with [AF_INET]229.165.15.11:9988
Fri Sep 18 22:02:21 2020 SENT CONTROL [jajejivpn]: 'PUSH_REQUEST' (status=1)
Fri Sep 18 22:02:21 2020 PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1 bypass-dhcp,dhcp-option DNS 208.67.222.222,dhcp-option DNS 208.67.220.220,route 10.8.0.1,topology net30,ping 10,ping-restart 120,ifconfig 10.8.0.6 10.8.0.5,peer-id 0,cipher AES-256-GCM'
Fri Sep 18 22:02:21 2020 OPTIONS IMPORT: timers and/or timeouts modified
Fri Sep 18 22:02:21 2020 OPTIONS IMPORT: --ifconfig/up options modified
Fri Sep 18 22:02:21 2020 OPTIONS IMPORT: route options modified
Fri Sep 18 22:02:21 2020 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Fri Sep 18 22:02:21 2020 OPTIONS IMPORT: peer-id set
Fri Sep 18 22:02:21 2020 OPTIONS IMPORT: adjusting link_mtu to 1624
Fri Sep 18 22:02:21 2020 OPTIONS IMPORT: data channel crypto options modified
Fri Sep 18 22:02:21 2020 Data Channel: using negotiated cipher 'AES-256-GCM'
Fri Sep 18 22:02:21 2020 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Fri Sep 18 22:02:21 2020 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Fri Sep 18 22:02:21 2020 ROUTE_GATEWAY 192.168.1.1/255.255.255.0 IFACE=enp4s0 HWADDR=b4:2e:99:34:2b:ec
Fri Sep 18 22:02:21 2020 TUN/TAP device tun0 opened
Fri Sep 18 22:02:21 2020 TUN/TAP TX queue length set to 100
Fri Sep 18 22:02:21 2020 /sbin/ip link set dev tun0 up mtu 1500
Fri Sep 18 22:02:21 2020 /sbin/ip addr add dev tun0 local 10.8.0.6 peer 10.8.0.5
Fri Sep 18 22:02:21 2020 /etc/openvpn/update-resolv-conf tun0 1500 1552 10.8.0.6 10.8.0.5 init
Fri Sep 18 22:02:21 2020 /sbin/ip route add 229.165.15.11/32 via 192.168.1.1
Fri Sep 18 22:02:21 2020 /sbin/ip route add 0.0.0.0/1 via 10.8.0.5
Fri Sep 18 22:02:21 2020 /sbin/ip route add 128.0.0.0/1 via 10.8.0.5
Fri Sep 18 22:02:21 2020 /sbin/ip route add 10.8.0.1/32 via 10.8.0.5
Fri Sep 18 22:02:21 2020 GID set to nogroup
Fri Sep 18 22:02:21 2020 UID set to nobody
Fri Sep 18 22:02:21 2020 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Fri Sep 18 22:02:21 2020 Initialization Sequence Completed

Puedes usar este script, que te genera todo y con la seguridad actualizada en ese tema.

Tambien, es buena practica abrir un puerto en el router, UDP de preferencia.

"RTNETLINK answers: File exists" parece ser que es algo relacionado con la interfaz para el vpn



PD: tengo mi servidor en casa y me conecto desde cualquier lugar.
1985a escribió:Puedes usar este script, que te genera todo y con la seguridad actualizada en ese tema.

Tambien, es buena practica abrir un puerto en el router, UDP de preferencia.

PD: tengo mi servidor en casa y me conecto desde cualquier lugar.

Está interesante, solo que el problema no esta del lado del servidor, sino del cliente.
Haz un ip a show para ver si la interfaz vpn tiene alguna direccion ip asignada, de esa que configuraste.
Tambien, ip r show para ver el gateway
A ver si entiendo bien:

Montas una VPN, y funciona desde cualquier red pública, excepto desde la subred en la que está montado ¿Verdad? ¿O la red de tu casa no es la red en la que está el server VPN?

Si fuera el primer caso, ¿Atacas al server por la subred pública o por la privada? Lo comento porque un error muy típico es que desde una LAN no se pueda atacar a su propia IP pública. Para eso el router tiene que ser capaz de hacer NAT Loopback, y no todos lo hacen.

Si fuera el segundo caso, es decir el cliente que falla está, al igual que los clientes que funcionan, en una red distinta que el server, los fallos pueden ser varios. En principio no debería ser un problema de red/puertos/etc, porque eso solo lleva configuración especial en el lado servidor y los demás funcionan. Yo revisaría lo típico:

- Verificar en el log del server que la petición del cliente llega
- revisar los certificados
- si se comparte el rango lan del server, verificar que la red lan de servidor y cliente no solapan. Aunque se entregue a cliente un ip de rango 10.8.x.x, se le entrega también la ruta hacia la red 192.168.x.x en la que está el servidor, que no puede coincidir con la del cliente. Por ejemplo si tienes la típica 192.168.1.x de Movistar en la dos sitios, debes cambiarla en uno de ellos (lo mejor es cambiarla en el server y poner algo tipo 192.168.200.x para que no solape con la de ningún cliente).

openVPN, si uno no se mete en opciones avanzadas, es sencillo de configurar, tiene poco más que mirar.....
Dracot escribió:A ver si entiendo bien:

Montas una VPN, y funciona desde cualquier red pública, excepto desde la subred en la que está montado ¿Verdad? ¿O la red de tu casa no es la red en la que está el server VPN?

Si fuera el primer caso, ¿Atacas al server por la subred pública o por la privada? Lo comento porque un error muy típico es que desde una LAN no se pueda atacar a su propia IP pública. Para eso el router tiene que ser capaz de hacer NAT Loopback, y no todos lo hacen.

Si fuera el segundo caso, es decir el cliente que falla está, al igual que los clientes que funcionan, en una red distinta que el server, los fallos pueden ser varios. En principio no debería ser un problema de red/puertos/etc, porque eso solo lleva configuración especial en el lado servidor y los demás funcionan. Yo revisaría lo típico:

- Verificar en el log del server que la petición del cliente llega
- revisar los certificados
- si se comparte el rango lan del server, verificar que la red lan de servidor y cliente no solapan. Aunque se entregue a cliente un ip de rango 10.8.x.x, se le entrega también la ruta hacia la red 192.168.x.x en la que está el servidor, que no puede coincidir con la del cliente. Por ejemplo si tienes la típica 192.168.1.x de Movistar en la dos sitios, debes cambiarla en uno de ellos (lo mejor es cambiarla en el server y poner algo tipo 192.168.200.x para que no solape con la de ningún cliente).

openVPN, si uno no se mete en opciones avanzadas, es sencillo de configurar, tiene poco más que mirar.....

Segundo caso. Me pongo a ello
[quote="verdezito"
Lo de abrir puertos y demás en el router no es necesario siendo un cliente, no tiene sentido alguno (siempre teniendo en cuenta que tu red sea normalita, aunque si la has tocado de alguna forma tú mismo deberías de saberlo).[/quote]

@verdezito

Eso estaba pensando pues no puede conectarse ni con linux ni con windows desde la casa, pero según entiendo si se conecta desde otros lados.
Yo creo que puede ser el tema del solapamiento de red LAN: que la conexión como tal la haga pero falle al entregar las rutas desde el server al cliente por solapamiento

A ver si @alohl669 se pasa por aquí y nos saca de la duda de si lo arregló con eso, sigue fallando o era otra cosa
Os saco ya de dudas, era solapamiento de red. he cambiado mi red(ya que es mas pequeña que la de la empresa para hacer las pruebas) a 192.168.10.0(blablabla) y ya tengo conexión. asi que perfect. Estos dias me tocará replantear cosas en la red del trabajo porque efectivamente cuando se diseñó(eran 4 personas) no se pensó en estas cosas y de y si lo dejo estar acabara siendo un problema.
Ok, me alegro que esté resuelto

Saludos!
Si si, muchas gracias a todos!!, os habéis implicado y me habéis echado una mano que no os imagináis.
Imagino que ya no vas a querer cambiar, pero wireguard es algo mas sencillo de instalar y funciona mas rapido que openVPN
messiah escribió:Imagino que ya no vas a querer cambiar, pero wireguard es algo mas sencillo de instalar y funciona mas rapido que openVPN

Lo tengo pendiente para uso personal
Esta bueno siempre usar un VPN para protegerse de su conexion.
Muchas personas lo usan para ver netflix, hay algunos que son opensource que te podes conectar con servidores publicos, pero si podes conectarte a uno mejor.
Por ejemplo queres usar nose servicios como netflix en el exterior y usas vpn o necesitas tener anonimato usas VPN podes pagar uno o sino usar los gratis que en la playstore hay varios gratis
Siempre sirve para seguridad o para acceder algun servicio que no este en tu pais, o para tener pravacidad para vos.
Editado por quimico2008. Razón: Spam
En realidad esas no son las características que busco, una vpn es mucho más que eso, pero a nivel usuario tampoco tiene más sentido que lo que comentas. Protege tu tráfico, efectivamente, también lo hace un túnel ssh o la Red tor, recursos y herramientas para ello no faltan. pero lo interesante de esto, al menos en lo que menciono que necesitaba en este hilo, son los beneficios profesionales que aporta. Por ejemplo gracias a ella puedo conectarme a mi trabajo como si estuviera dentro de las oficinas sin descuidar la seguridad, o puedo conectar a un par de colegas para proyectos personales a mi servidor y acceder todos a los mismos recursos como si estuvieran en mi casa, por poder nos podemos hasta montar una Lan party con juegos que solo admitan modo local!(casi ninguno, lo se)
18 respuestas
Archivado
Volver a Software libre