He observado un comportamiento un tanto extraño que no logro entender del todo. Entonces configuré una conexión OpenVPN como se muestra en el siguiente gráfico. (Es una configuración TUN y de cliente a cliente). Mis pensamientos se dirigen a la ruta del ping en este escenario: mi conexión openvpn
from client: 192.168.200.102 to LAN: 10.198.0.16
En general, no es sorprendente que este ping sea exitoso, pero según tengo entendido, en caso de que cambie la configuración de iptables en el servidor a
-P FORWARD DROP
y luego incluso
net.ipv4.ip_forward = 0.
el tráfico nunca debe llegar al destino con la configuración anterior. Aunque el tráfico tiene éxito, nunca llega a la interfaz LAN. La cuestión es que no puedo ver el tráfico (al ejecutar el analizador de paquetes de red de datos tcpdump) que llega a la interfaz LAN eth0 10.198.0.16. Más bien parece que la interfaz tun responde automáticamente al tráfico, como si la IP de la LAN estuviera vinculada a la interfaz tun, consulte a continuación:
sudo tcpdump -i tun0 tcpdump: 16:34:21.391381 IP 192.168.200.102 > 10.198.0.16: ICMP echo request, id 14, seq 1885, length 64 16:34:21.391514 IP 10.198.0.16 > 192.168.200.102: ICMP echo reply, id 14, seq 1885, length 64
¿Qué está pasando aquí? Hasta donde tengo entendido, la solicitud proveniente del Cliente va a la interfaz tun en el servidor y eventualmente seráREENVIADOpor el kernel a eth0, ¿estoy en lo cierto? ¿Eso normalmente sería visible ejecutando: sudo tcpdump -i tun0o sudo tcpdump -i eth0?
La razón por la que soy tan exigente con esto es que lo considero un riesgo para la seguridad si no hay una manera de implementar reglas para evitar que los Clientes accedan a la LAN en el servidor. ¿Qué me falta aquí? ¿Existe un proceso OpenVPN que reenvíe paquetes a la interfaz eth0 (según lo previsto para la configuración de cliente a cliente)?
Para que pueda ayudarme mejor a solucionar mi problema, adjunté algunos diagnósticos a continuación.
Para el servidor
ip addr`1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether b8:27:eb:5c:a6:e6 brd ff:ff:ff:ff:ff:ff inet 10.198.0.16/24 brd 10.198.0.255 scope global eth0 valid_lft forever preferred_lft forever inet6 fe80::ba27:ebff:fe5c:a6e6/64 scope link valid_lft forever preferred_lft forever 3: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether b8:27:eb:09:f3:b3 brd ff:ff:ff:ff:ff:ff 4: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 500 link/none inet 192.168.200.1/24 scope global tun0 valid_lft forever preferred_lft forever inet6 fe80::87cd:fedd:92fc:cde/64 scope link stable-privacy valid_lft forever preferred_lft forever
`
ip routedefault via 10.198.0.1 dev eth0 proto static 10.198.0.0/24 dev eth0 proto kernel scope link src 10.198.0.16 192.168.200.0/24 dev tun0 proto kernel scope link src 192.168.200.1 192.168.178.0/24 via 192.168.200.1 dev tun0 scope linkserver openvpn.conftls-server mode server dev tun local 10.198.0.16 proto tcp-server port 1234 user openvpn group openvpn ca /etc/openvpn/cacert.pem cert /etc/openvpn/servercert.pem key /etc/openvpn/serverkey dh /etc/openvpn/dh2048.pem ifconfig-pool 192.168.200.2 192.168.200.103 255.255.255.0 client-config-dir /etc/openvpn/ccd ifconfig 192.168.200.1 255.255.255.0 keepalive 10 120 comp-lzo client-to-client push "topology subnet" topology "subnet" log /var/log/openvpn.log
Para el cliente
ip addr1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: enp0s31f6: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000 link/ether 38:af:d7:a0:52:ec brd ff:ff:ff:ff:ff:ff 3: wlp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 00:28:f8:8d:1c:6f brd ff:ff:ff:ff:ff:ff inet 192.168.178.79/24 brd 192.168.178.255 scope global dynamic noprefixroute wlp2s0 valid_lft 859868sec preferred_lft 859868sec inet6 2a0a:a540:d54:0:bd79:eb10:5e26:548a/64 scope global temporary dynamic valid_lft 7190sec preferred_lft 3590sec inet6 2a0a:a540:d54:0:6086:b044:dff:2694/64 scope global dynamic mngtmpaddr noprefixroute valid_lft 7190sec preferred_lft 3590sec inet6 fe80::ad5c:6e18:87fa:dff4/64 scope link noprefixroute valid_lft forever preferred_lft forever 4: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 100 link/none inet 192.168.200.102/24 brd 192.168.200.255 scope global tun0 valid_lft forever preferred_lft forever inet6 fe80::5dfc:6b3a:3c4d:e9a4/64 scope link stable-privacy valid_lft forever preferred_lft foreverip routedefault via 192.168.178.1 dev wlp2s0 proto dhcp metric 600 169.254.0.0/16 dev wlp2s0 scope link metric 1000 10.198.0.0/24 via 192.168.200.1 dev tun0 192.168.200.0/24 dev tun0 proto kernel scope link src 192.168.200.102 192.168.178.0/24 dev wlp2s0 proto kernel scope link src 192.168.178.79 metric 600client openvpn.confdev tun client nobind remote 11.22.33.44 proto tcp port 1234 ca /etc/openvpn/cacert.pem cert /etc/openvpn/user_cert.pem key /etc/openvpn/user comp-lzo verb 3 keepalive 10 120 log /var/log/openvpn.logccd for clientiroute 192.168.178.0 255.255.255.0
Respuesta1
El tráfico entre la VPN y el resto de la red, por supuesto, pasa tun0. Para este tráfico, FORWARDla cadena se consulta como de costumbre y puedes controlar quién puede conectarse y dónde. Si ip_forwardno está habilitado, el tráfico no se reenviará.
Cuando client-to-clientno se usa, el tráfico entre clientes usa la misma ruta: aparece en el sistema operativo del servidor desde tun0la interfaz, se enruta correctamente usando la tabla de enrutamiento del sistema operativo, atraviesa el firewall y la única diferencia es que decide que el destino está detrás tun0, por lo que el paquete se salió a través de él.
No es muy eficiente porque el proceso OpenVPN está en el espacio del usuario, mientras que tun0 está en el espacio del kernel, y da como resultado al menos dos cambios de contexto para cada paquete.
Sin embargo, cuando client-to-clientse utiliza, los paquetes entre clientes no aparecen en , no se consulta la cadena tun0de firewall del servidor y el control no influye en su reenvío. El propio proceso OpenVPN se convierte en un enrutador, con su propia tabla de enrutamiento, independiente del sistema operativo anfitrión. Puede verlo con el comando de la interfaz de administración o volcarlo en el archivo de estado. Puede controlar las rutas dentro de este "enrutador" con una directiva (creo que significa "ruta interna"), que solo es válida en el archivo del cliente o en la configuración dinámica generada por script.FORWARDip_forwardstatusiprouteclient-config-dir
Lo más fácil es no pensar en la VPN como algo especial. Una vez establecido el túnel, olvídese de él, ahora es solo una interfaz regular adicional en cada computadora (servidor y clientes), con todas esas interfaces conectadas a algún enrutador simple y regular. Y considere el enrutamiento y el firewall habituales.
Finalmente noté que hiciste ping a la dirección deel servidor VPN en síaunque asignado a otra interfaz. Este paquete esno va a ser reenviadode todos modos, debido a que su destino es el servidor mismo, ip_forwardno influye en cómo se procesa este paquete, y está atravesando INPUTla cadena del firewall y la respuesta lo atravesará OUTPUT(por ejemplo, no FORWARDencadenará como lo harían si no estuvieran destinados al sistema mismo). El paquete ingresará al sistema tun0(y será visto allí), pero no lo verá eth0porque no se enviará. Se procesará localmente. Lo mismo ocurre con las respuestas.
No importa (para el código relacionado con el enrutamiento) en qué parte del sistema está asignada la dirección (qué interfaz) o qué dirección del sistema utiliza para acceder a ella. Lo que importa es si pertenece al sistema o no.
El problema de seguridad relacionado es que algunas personas piensan que si vinculan el servicio a alguna dirección IP asignada a alguna interfaz, cortan el acceso a este servicio a través de otras interfaces.Esto está mal.Si otros sistemas que viven detrás de otras interfaces tienen una ruta hacia la IP a la que está vinculado el servicio, aún asíserá capazpara acceder al servicio. Esta no es una forma correcta de asegurar el servicio; la configuración adecuada del firewall es.
Otro problema relacionado es que algunas personas usan ping -I <local-address> <address-to-ping>o incluso ping -I <interface> <address-to-ping>piensan que seleccionan directamente qué interfaz se emitirán los pings. De nuevo, esto está mal. De esta manera sólo podrás seleccionar cuálDirección de la fuentetendrán pings, pero no la interfaz para enviarlos; la interfaz será seleccionada por el código de enrutamiento estrictamente de acuerdo con la tabla de enrutamiento basándose únicamente en la dirección de destino del paquete (supongo que no se realizó ninguna configuración de VRF o RPDB, pero eso es algo avanzado y las personas que lo configuraron conocen esta característica de todos modos). ).