Tengo este cliente vpn que toca la tabla de enrutamiento y luego sigue observándolo para salir si se toca.
Es el tipo de configuración necesaria para un punto final, como una computadora portátil.
Quiero usar una PC pequeña como punto final vpn y enrutar a través de ella para otras máquinas en mi LAN (192.168.0.0/24).
Como no puedo tocar la tabla de enrutamiento y todos los paquetes son forzados a través de vpns dispositivo tun0, estaba pensando que iptables podría ayudarme a enviar paquetes POSTROUTE a la red 192.168.0.0 de regreso al dispositivo eth1. ya está en la red de destino, y no sé si el paquete ya se resolvió o no sucederá hasta que llegue a la iface.
¿Alguna pista?
Respuesta aceptada:
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 darte algunas instrucciones, ignorando deliberadamente que no puedes modificar tu tabla de enrutamiento (comprenderás por qué al leer mi sugerencia):
Según el cliente VPN y dónde se conecta a la FIB (base de información directa) del kernel, es posible que tenga suerte en que el monitoreo de la FIB o, usando su tabla de enrutamiento de expresión, por la VPN solo ocurre para el local y main tablas de reglas 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 de la FIB, usando
ip route show table <name>
Con un poco de suerte, podría intentar construir una regla que coincida con sus requisitos y darle preferencia en la tabla de búsqueda de reglas. Por ejemplo (hice algo para darle una ventaja), agreguemos una nueva regla con mayor preferencia que main a 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ía las tres tablas de reglas predeterminadas local , main y default , del cual normalmente solo ves el main tabla al invocar 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 específicas de enrutamiento, no está claro qué es exactamente lo que está tratando de lograr. Asegúrese de vaciar la memoria caché de enrutamiento cuando juegue con las tablas de reglas:
ip route flush cache
Tenga en cuenta que al usar la arquitectura iproute2, básicamente puede filtrar y modificar prácticamente cualquier entrada de FIB; incluso se pueden hacer entradas de reglas basadas en fwmarks y/o clasificadores u32, como sigue (ejemplo tomado del libro 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
Debido a que las cosas se vuelven locas en las entradas de las tablas de reglas, hace muchos años había preparado un pequeño fragmento de bash para que mi sistema volviera 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 de la existencia, todavía solo unas pocas personas parecen saber que hay un universo más allá del clásico “roto” herramientas como ifconfig o netstat .