Tengo este cliente VPN que toca la tabla de enrutamiento y luego sigue mirándola para salir si la tocan. Es el tipo de configuración necesaria para un terminal, como una computadora portátil.
Quiero usar una PC pequeña como punto final de VPN y enrutarla a otras máquinas en mi LAN (192.168.0.0/24).
Como no puedo tocar la tabla de enrutamiento y todos los paquetes se fuerzan a través del tun0
dispositivo VPN, estaba pensando iptables
que podría ayudarme a POSTRRUTAR paquetes a la red 192.168.0.0 de regreso al eth1
dispositivo.
Sin embargo, no estoy seguro de cómo funcionaría esto, porque una vez que sale eth1
debería resolver el IPtoMAC porque ya está en la red de destino, y no sé si el paquete ya se resolvió o no sucederá hasta que llegue. la cara.
¿Alguna pista?
Respuesta1
Como no ha proporcionado más información, no estoy seguro de cuál es la mejor respuesta.
Así que aquí va mi intento de darle algunas instrucciones, ignorando intencionalmente que no puede modificar su tabla de enrutamiento (comprenderá por qué leyendo mi sugerencia):
Dependiendo del cliente VPN ydóndese conecta a la FIB (base de información directa) del kernel, es posible que tenga algo de suerte porque el monitoreo de la FIB o, usando su tabla de enrutamiento de expresiones, por parte de la VPN solo ocurre para las tablas de reglas local
y main
. Puede verificar sus reglas de enrutamiento usando
ip rule show
Para cada una de las cadenas detrás de la etiqueta "búsqueda" (que son las entradas de la tabla de reglas), puede consultar la información de enrutamiento correspondiente desde la FIB, usando
ip route show table <name>
Con un poco de suerte, podría intentar crear una regla que coincida con sus requisitos y darle preferencia en la tabla de búsqueda de reglas. Por ejemplo (inventé algo para darle una ventaja), agreguemos una nueva regla con mayor preferencia que main
para ciertos flujos:
ip rule add from 192.168.1.0/24 to 10.10.212.1/30 iif eth0 oif eth2 lookup 888 pref 12000
ip rule show
0: from all lookup local
12000: from 192.168.1.0/24 to 10.10.212.1/30 iif eth0 oif eth2 lookup 888
32766: from all lookup main
32767: from all lookup default
En un sistema Linux estándar (Ubuntu en el caso de esta publicación), verá las tres tablas de reglas predeterminadas local
, main
y default
, de las cuales normalmente solo verá la main
tabla cuando invoque, netstat -rn
por ejemplo.
Ahora queremos completar las entradas FIB en la tabla de búsqueda 888 con nuevas entradas de enrutamiento:
ip route add default via 10.37.129.4 dev eth2 table 888
Veamos cómo se ven nuestras entradas de enrutamiento en la tabla 888:
ip route show table 888
default via 10.37.129.4 dev eth2
Creo que entiendes la idea. Ahora, con respecto a sus necesidades de enrutamiento específicas, no está claro qué es exactamente lo que está tratando de lograr. Asegúrese de vaciar la caché de enrutamiento cuando juegue con tablas de reglas:
ip route flush cache
Tenga en cuenta que al utilizar la arquitectura iproute2 básicamente puede filtrar y modificar prácticamente cualquier entrada FIB; Las entradas de reglas incluso se pueden realizar basándose en fwmarks y/o clasificadores u32, como se muestra a continuación (ejemplo tomado dellibro de enrutamiento de políticas):
tc filter add dev eth1 parent ffff: protocol ip prio 1 u32 \
match ip src 10.1.1.0/24 classid :1
ip rule add fwmark 1 table 1 prio 15000 realms 3/4
ip route add default via 192.168.1.1 table 1 src 192.168.1.254
ip route flush cache
Para que las cosas se vuelvan locas en las entradas de las tablas de reglas, hace muchos años preparé un pequeño fragmento de bash para devolver mi sistema al estado original de las reglas de enrutamiento:
: ${KEEP:="local main default"}
while read prio rule; do
continue=0
for keep in ${KEEP}; do
if [ "${rule//lookup ${keep}/}" != "${rule}" ]; then
continue=1
fi
done
if [ ${continue} -eq 0 ]; then
ip rule del prio ${prio%%:*} ${rule//all/0/0}
fi
done < <(ip rule show)
Sorprendentemente, parece que después de más de 10 años de iproute2
existencia, sólo unas pocas personas parecen saber que existe un universo más allá del clásico."roto"herramientas como ifconfig
o netstat
.