☰

El servidor OpenVPN no puede hacer ping a los clientes

tag-icon • tag-icon routing openvpn
El servidor OpenVPN no puede hacer ping a los clientes

Tengo OpenVPN configurado en un servidor Debian. Los clientes pueden conectarse y pueden hacer ping y acceder a recursos (compartimientos compartidos de Samba e intranet) en el servidor.

Sin embargo, el servidor no puede hacer ping al cliente, simplemente se agota el tiempo de espera.

Diagrama

Client OpenVPN assigned IP: 10.67.15.26
   ↓ UDP on 1194
Internet
   ↓
Router port-forwards 1194 to server
   ↓ 
Server LAN IP: 10.67.5.1

Configuración del servidor OpenVPN (bits relevantes)

port 1194
proto udp
dev tun
server 10.67.15.0 255.255.255.0
push "route 10.67.5.0 255.255.255.0"

tabla de enrutamiento del servidor

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.67.15.2      0.0.0.0         255.255.255.255 UH    0      0        0 tun0
10.67.15.0      10.67.15.2      255.255.255.0   UG    0      0        0 tun0
10.67.5.0       0.0.0.0         255.255.255.0   U     0      0        0 eth1
0.0.0.0         10.67.5.254     0.0.0.0         UG    0      0        0 eth1

cortafuegos del servidor

Deshabilité temporalmente el firewall del servidor, todas las políticas de las cadenas se ACEPTAN y todos los indicadores de reenvío están configurados:

1 : /proc/sys/net/ipv4/conf/all/forwarding
1 : /proc/sys/net/ipv4/conf/default/forwarding
1 : /proc/sys/net/ipv4/conf/lo/forwarding
1 : /proc/sys/net/ipv4/conf/eth1/forwarding
1 : /proc/sys/net/ipv4/conf/tun0/forwarding
1 : /proc/sys/net/ipv4/ip_forward

Casos de prueba:

cliente: ping 10.67.5.1funciona, al igual que otros recursos.

servidor: ping 10.67.15.26se agota el tiempo de espera.

Respuesta1

Al comparar dos clientes diferentes, pude identificar y solucionar 2 problemas.

Problema 1: enrutamiento

Por alguna razón (y no estoy seguro de haber resuelto esto), la tabla de enrutamiento del servidor seguía olvidando la ruta hacia/desde su LAN (10.67.5.0/24). Esto provocaba que todo el tráfico LAN saliente pasara por su puerta de enlace principal, que no se enrutará a la LAN OpenVPN (10.67.15.0/24). Esto provocaba que el tráfico de la red OpenVPN destinado a la LAN fallara en la puerta de enlace principal; por lo tanto, se enviaron pings, pero se abandonó la respuesta.

Editar:Lamentablemente, no sé qué provocó que se abandonara esta ruta; como puede ver, estaba en la tabla de enrutamiento de arriba. Intenté agregar un comando de ruta en /etc/network/interfaces, pero luego terminé con dos rutas idénticas duplicadas, así que lo eliminé nuevamente.Era miconstructor de fwconfiguración que estaba provocando que se descartara esta ruta: al configurar el adaptador eth1, había proporcionado una máscara de red /32 (es decir, un host) en lugar de /24 (para la LAN).

Al probar un cliente Debian, pude resolverlo; después de esto, funcionó, pero el cliente de Windows 7 no.

Problema 2: firewall/configuración de Windows 7

Hubo dos problemas con la configuración de Windows.

Windows debe tener el perfil privado "Trabajo" configurado para el adaptador TAP

El crédito por esta sección es para kalwi.

Actualización a partir del 2020-06-11

Puede cambiar una interfaz a privada usando los siguientes dos comandos de PowerShell:

# this first one will let you see the available connections, 
# find the interface index of the one you would like to change
Get-NetConnectionProfile
Set-NetConnectionProfile -InterfaceIndex NN -NetworkCategory Private

En el "Centro de redes y recursos compartidos" deberías ver (al menos) 2 "redes activas". Tenía la red inalámbrica y luego una "Red no identificada". Este último es el dispositivo OpenVPN TAP y tenía un ícono de banco en el parque, lo que significa que fue tratado como público, no confiable. Para poder cambiar esto, debe agregar una puerta de enlace predeterminada para el adaptador.

Iniciar una terminal DOS/Cygwincomo administrador. (Inicie Orb> busque CMD> haga clic derecho en él> ejecute como administrador).

Entonces hazlo route print -4. Verá una lista de interfaces. Cada línea comienza con un número y a la derecha verás el nombre. Identifique el número de interfaz del adaptador TAP-Win32. El mío tenía 17.

Ahora agrega la ruta:

route -p add 0.0.0.0 mask 0.0.0.0 1.2.3.4 metric 500 if 17

Donde 1.2.3.4 debe ser la IP de su puerta de enlace OpenVPN (revelada en la columna Puerta de enlace en el resultado del comando anterior) y 17 debe ser su número de interfaz TAP. La -popción hace que la ruta sea permanente. Lo hice sin esto primero, para probar.Esto supone que la IP de la puerta de enlace OpenVPN del cliente no cambiará entre conexiones..

Una vez que haya hecho eso, debería aparecer un cuadro de diálogo que le pedirá que clasifique la nueva red. ElegirTrabajar.

En este punto, pude enviar tráfico desde la LAN de mi empresa al cliente (probado con netcat), sin embargo, los pings seguían sin respuesta.

Dígale a Windows que permita pings (ICMPv4)

Inicie Orb > Firewall de Windows con seguridad avanzada. Luego vaya a Reglas de entrada y Nueva regla...

  • Regla personalizada
  • Todos los programas
  • Protocolo: ICMPv4
  • Permitir la conexión
  • Aplicar al perfil privado
  • Nombralo.

Finalmente se devolvieron los pings.

información relacionada