En un sistema Linux, que actúa como puerta de enlace en mi LAN, intenté enrutar el tráfico usando iproute2. Además, antes del enrutamiento es necesario realizar la NAT, ya que la máquina Linux está conectada a un dispositivo que permite la conexión a Internet y tiene 2 direcciones IP 172.16.61.1
y172.16.62.100
Tengo 2 tarjetas de red con la siguiente configuración:
DEVICE=eth3
ONBOOT=yes
BOOTPROTO=none
TYPE=Ethernet
NETMASK=255.255.255.0
IPADDR=192.168.1.150
USERCTL=no
IPV6INIT=no
PEERDNS=yes
DEVICE=eth4
ONBOOT=yes
BOOTPROTO=none
TYPE=Ethernet
NETMASK=255.255.255.0
IPADDR=172.16.61.2
USERCTL=no
IPV6INIT=no
PEERDNS=yes
GATEWAY=172.16.61.1
y uso las siguientes instrucciones para la traducción de ip a través de iptables
/sbin/iptables -t nat -A POSTROUTING -s 192.168.1.0/255.255.255.0 -j SNAT --to-source 172.16.61.2
Usando la configuración antes mencionada, todas las computadoras pertenecientes a la red 192.168.1.0/24 que tengan 192.168.1.150 como puerta de enlace podrán conectarse a Internet.
Si intento usar iproute2 para configurar la puerta de enlace, elimino la puerta de enlace predeterminada de eth4, que asume la siguiente configuración:
DEVICE=eth4
ONBOOT=yes
BOOTPROTO=none
TYPE=Ethernet
NETMASK=255.255.255.0
IPADDR=172.16.61.2
USERCTL=no
IPV6INIT=no
PEERDNS=yes
Y realicé los siguientes pasos:
1. In /etc/iproute2/rt_tables I have added the line
1 ruta61
2. /sbin/ip route add 172.16.61.0/24 via 172.16.61.1 table route61 proto static
3. /sbin/ip route add default via 172.16.61.1 table route61 proto static
4. /sbin/ip rule add from 172.16.61.0/24 pref 15000 table route61
La salida de /sbin/ip route show table route61
es
172.16.61.0/24 via 172.16.61.1 dev eth4 proto static
default via 172.16.61.1 dev eth4 proto static
La salida de /sbin/ip rule show
es
0: from all lookup local
15000: from 172.16.61.0/24 lookup route61
32766: from all lookup main
32767: from all lookup default
pero en este caso no funciona, ¿en qué me equivoco?
También intenté usarlo /etc/sysconfig/network-scripts/ifup-routes eth4
sin éxito.
Lo que necesito es entender por qué no puedo hacer que funcione el "enrutamiento basado en tablas", ya que tendré que usarlo en un contexto con múltiples puertas de enlace.
Actualizar
Para probar lo sugerido por Dirkt, eliminé la puerta de enlace predeterminada.
route del -net 0.0.0.0 gw 172.16.61.1 netmask 0.0.0.0 dev eth4
y usé:
ip rule add from 192.168.1.0/24 pref 15000 table route61
lo que ocurre es
- la pc que usa 192.168.1.150 como GW, que es la pc objeto de esta publicación, puede conectarse a internet
- Ya no puedo conectarme a GW a menos que elimine la instrucción
ip rule add from 192.168.1.0/24 pref 15000 table route61
Con el enrutamiento posterior, los paquetes provenientes de 192.168.1.0/24 no deberían asumir 172.16.61.2 como dirección de origen.
Si uso o elimino GW predeterminado usando route add -net 0.0.0.0 gw 172.16.61.1 netmask 0.0.0.0 dev eth4
OR route del -net 0.0.0.0 gw 172.16.61.1 netmask 0.0.0.0 dev eth4
y hago:
ip route get 216.58.205.78 from 192.168.1.5
TengoRTNETLINK answers: Invalid argument
si lo uso ip route get 216.58.205.78 from 172.16.61.2
tengo216.58.205.78 from 172.16.61.2 via 172.16.61.1 dev eth4
Después route add -net 0.0.0.0 gw 172.16.61.1 netmask 0.0.0.0 dev eth4
si lo hago:
nc -v 216.58.205.78 443
Tengo
Connection to 216.58.205.78 443 port [tcp/https] succeeded!
Si elimino el GW predeterminado, route del -net 0.0.0.0 gw 172.16.61.1 netmask 0.0.0.0 dev eth4
nc se conecta solo si especifico la IP de origen:
nc -v 216.58.205.78 443 -s 172.16.61.2
Respuesta1
Si lo entiendo correctamente, tiene 192.168.1.0/24
activado eth3
y desea enrutarlo y realizar NAT a algo detrás eth4
, donde no se especifica qué hay exactamente detrás eth4
, si hace DHCP y si necesita direcciones estáticas o no.
(El caso habitual es que tenga algún tipo de enrutador detrás eth4
, que ejecuta DHCP y proporciona direcciones).
Primero, la forma habitual de lograrlo es habilitar el reenvío y hacer
iptables -t nat -A POSTROUTING -o $EXTIF -j MASQUERADE
¿Dónde $EXTIF
está su interfaz externa ( eth4
)? Es con cualquier dirección que esté activada , por lo que es resistente a la reasignación de direcciones MASQUERADE
. Y si no menciona los protocolos, todo se vuelve NAT, que suele ser lo que desea.SNAT
eth4
En segundo lugar, no hay ninguna razón para realizar enrutamiento basado en tablas (a menos que haya detalles adicionales que no haya explicado). Así que olvídese de las tablas, y si no hay ningún DHCP detrás eth4
que distribuya la información de la puerta de enlace para la ruta predeterminada, simplemente haga
ip route default via 172.16.61.1
Suponiendo que eth4
ya tiene una dirección 172.16.61.*/24
, esto es suficiente (la 172.16.61.0/24
ruta se establece cuando configura la dirección IP).
Pero lo mejor es dejar esto en DHCP, si está habilitado en su enrutador (supongo que sería BOOTPROTO=dhcp
, si es Red Hat).
Si el problema es la política de enrutamiento: desea enrutar los paquetes salientes que ingresan a 192.168.1.0/24
través de una ruta predeterminada en la tabla route61
, por lo que debe hacer
ip rule add from 192.168.1.0/24 pref 15000 table route61
y no from 172.16.61.0/24
.
Dicho esto, no estoy realmente seguro de cómo interactúa NAT con el enrutamiento de políticas. Identificaciónasumirlos paquetes que regresan se denatan primero y luego las reglas de la tabla principal los enrutarán correctamente, pero yo nunca lo he intentado.
Depurar, ip route get X.X.X.X from Y.Y.Y.Y
puede ser útil, al igual que tcpdump
en ambas interfaces, como ya lo hizo en la otra pregunta que mencionó.
También será más fácil intentar esto primero sin tablas. Una vez que eso funcione, sabrás que nada más se interpondrá en tu camino y podrás probar con tablas.
Respuesta2
Usando una nueva tabla de enrutamiento, debe agregar incluso rutas conectadas: en su lugar, 172.16.61.0/24 via 172.16.61.1 dev eth4 proto static
debería tener proto scope link
la IP de origen especificada y se perderá la ruta 192.168.1.0/24. La decisión de enrutamiento se realiza antes de la salida/post enrutamiento nat, por lo que ip rule add from
debe usar la IP de origen original. .
# Configure tables
echo '2 table61' >> /etc/iproute2/rt_tables
echo '3 table62' >> /etc/iproute2/rt_tables
# routing decision is performed before output / post routing nat
ip rule add from 192.168.1.5 lookup table62
ip rule add from 192.168.1.0/24 lookup table61
ip route add 192.168.1.0/24 dev eth3 proto kernel scope link src 192.168.1.150 table table61
ip route add 172.16.61.0/24 dev eth4 proto kernel scope link src 172.16.61.2 table table61
ip route add default via 172.16.61.1 table table61
ip route add 192.168.1.0/24 dev eth3 proto kernel scope link src 192.168.1.150 table table62
ip route add 172.16.62.0/24 dev eth4 proto kernel scope link src 172.16.62.100 table table62
ip route add default via 172.16.62.254 table table62
Además, es posible que haya mezclado sus preguntas en mi cabeza. Si no funciona de inmediato, ¿podría agregar lo siguiente a su pregunta?
ip a
ip r show table table61
ip r show table table62
ip rule show
iptables -L -n -v
iptables -t nat -L -n -v