Supongamos que tengo la máquina A como puerta de enlace. La máquina A tiene una interfaz con 2 IP.
La configuración de netplan para la Máquina A es así:
renderer: networkd
ethernets:
eth0:
dhcp4: no
addresses:
- 192.168.1.1/24
- 192.168.1.2/24
Ahora quiero que las reglas REDIRECT de iptables se comporten de manera diferente dependiendo de si la Máquina B configuró su puerta de enlace como 192.168.1.1 o 192.168.1.2.
Este es el comando de iptables que estoy intentando ejecutar en la Máquina A:
iptables --table nat --append PREROUTING --some-parameter 192.168.1.1 --protocol tcp --jump REDIRECT --to-ports 9991
iptables --table nat --append PREROUTING --some-parameter 192.168.1.2 --protocol tcp --jump REDIRECT --to-ports 9992
¿Podría decirnos cuál es el nombre correcto de lo --some-parameter
anterior?
Respuesta1
No hay forma de hacer esto con 192.168.1.1 y 192.168.1.2 en la misma interfaz de red de la puerta de enlace, resolviendo así en la misma dirección MAC. No es una característica no implementada eniptablesque podría implementarse, es una característica que no se puede implementar debido a cómo funcionan las redes IP.
Un cliente que utilice 192.168.1.1 o 192.168.1.2 como puerta de enlace nunca enviará un solo paquete IPv4 con 192.168.1.1 o 192.168.1.2 al emitir paquetes a Internet. Va a:
- consultar su tabla de enrutamiento para un destino determinado
- encontrar que hay una puerta de entrada para este destino
- UsarARPo una entrada en caché para resolver la dirección L2 (dirección MAC Ethernet) necesaria para llegar a la puerta de enlace.
El último paso tendrá solo un destino Ethernet: la dirección MAC única de la NIC de la puerta de enlace: lo mismo para un cliente con la puerta de enlace 192.168.1.1 o para otro cliente con la puerta de enlace 192.168.1.2.
Entonces, cada cliente ahora enviará un paquete a la puerta de enlace con su dirección de origen IPv4; el destino IPv4 previsto en una trama Ethernet tendrá la misma dirección MAC Ethernet de destino en ambos casos. 192.168.1.1/192.168.1.2 está fuera del circuito.
La puerta de enlace ahora ve dos paquetes para enrutar. En ningún caso estos paquetes ya indican si estaban utilizando 192.168.1.1o 192.168.1.2como puerta de enlace: la información no aparece en el cable por lo que la puerta de enlace no puede conocerla en ninguna parte. Si el sistema no tiene información para distinguir los casos, entoncesiptablesTampoco puedo tener esta información inexistente.
Sugerencia de solución alternativa:
Se puede utilizar unMACVLANinterfaz para tener una segunda NIC con su propia dirección MAC separada y asignarle 192.168.1.2/24 en su lugar, lo que hará que los paquetes de los clientes que usan 192.168.1.2 como puerta de enlace lleguen a esta NIC. Este caso es fácil de distinguir coniptables: un -i NICfiltro diferente.
Pero esto crea el problema de enrutamiento de tener varias NIC en la misma LAN y requiere:
reglas avanzadas de enrutamiento de políticas para abordar este caso adecuadamente
por lo que las respuestas no se envían a través de la NIC incorrecta, lo que podría afectar el comportamiento de enrutamiento o las reglas del firewall.
- y además, cualquier servicio UDP consultado en 192.168.1.2 (si 192.168.1.1 es el predeterminado), debe saber cómo responder con la dirección de origen correcta 192.168.1.2 (en lugar de 192.168.1.1 predeterminada): debe ser multitarjeta consciente. TCP no requiere cuidados especiales.
o bien, un espacio de nombres de red adicional para separar la interfaz agregada. Pero con una regla REDIRECT, eso significa que el servicio en el puerto 9992 debe ejecutarse en el espacio de nombres de red adicional. Y este espacio de nombres de red probablemente todavía tenga que comunicarse con Internet utilizando el espacio de nombres de red inicial: también hay que planificar más configuraciones en varios lugares.