El reenvío de puertos firewalld interrumpe el tráfico saliente en ese puerto.

El reenvío de puertos firewalld interrumpe el tráfico saliente en ese puerto.

Estoy usando una computadora con Linux como puerta de enlace/firewall entre la red más amplia y algunos servidores.

WAN -> [ 192.x | GATEWAY (Linux) | 10.x ]  -> [ 10.0.0.100 | SERVER (Linux) ]

Esta configuración funciona bien como puerta de enlace. Los nodos descendentes pueden conectarse bien a Internet y puedo transferir solicitudes de reenvío 80en la puerta de enlace al 8000servidor con firewall-cmd.

firewall-cmd --zone=external --add-forward-port=port=80:proto=tcp:toaddr=10.0.0.100:toport=8000

Sin embargo, una vez que ejecuto ese comando y se inicia el reenvío de puerto, el servidor ( 10.0.0.100) ya no puede volver a conectarse al WANpuerto activo 80. Eso es un problema porque significa que el servidor no puede alcanzar ningún tráfico HTTP en Internet.

El servidor puede curlcualquier recurso de Internet.exceptosi está en el puerto 80mientras esa regla de reenvío está vigente.

La puerta de enlace solo tiene una NIC física y está en la externalzona, lo que permite el enmascaramiento.

gateway:$ 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 mq state UP group default qlen 1000
    link/ether dc:a6:32:1b:40:9e brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.2/24 brd 192.168.0.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet 10.0.0.1/24 brd 10.0.0.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::dea6:32ff:fe1b:409e/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 dc:a6:32:1b:40:9f brd ff:ff:ff:ff:ff:ff
gateway:$ ip route
default via 192.168.0.1 dev eth0 onlink
10.0.0.0/24 dev eth0 proto kernel scope link src 10.0.0.1
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.2

Probablemente me falta algún elemento fundamental sobre las redes que me impide comprender este problema.

Mi suposición es que la regla de reenvío lo hace asítodoEl tráfico del puerto 80 (entrante o saliente) se está alterando, cuando en realidad solo quiero que el tráfico entrante del 80 se reenvíe al 8000 para mi servidor.

¿Es posible que la configuración de la red sea incorrecta? ¿O hay algo sobre cómo lo estoy usando firewalldque no es válido?

Respuesta1

Tal vez iptableso firewalldpueda usarse en mi escenario para reenviar a máquinas específicas en la subred descendente, pero no pude descubrir cómo hacerlo funcionar.

Puede que esto no sea ideal, pero mi solución fue crear un servicio systemd en mi gatewaymáquina que socatreenvía el tráfico en un puerto específico a una IP específica.

Este es el script que se ejecuta en my gatewaypara reenviar puertos 80y 443para 10.0.0.100.

firewall-cmd --zone=external --add-port=80/tcp
socat TCP4-LISTEN:80,fork TCP4:10.0.0.100:80 &
firewall-cmd --zone=external --add-port=443/tcp
socat TCP4-LISTEN:443,fork TCP4:10.0.0.100:443 &
wait

información relacionada