Información de contexto
Estoy usando un sistema Linux para enrutar el tráfico de un pequeño bloque de direcciones IPv4 públicas (habilitando el reenvío de IP en
sysctrl.conf).El enrutador se está conectando al ISP
eth1mediante PPPoE.La dirección del par local utilizada para ppp es una dirección IP configurada manualmente que fue especificada por el ISP. La dirección del par local es
10.0.0.10.La dirección del par remoto utilizada para ppp también es una dirección IP configurada manualmente que fue especificada por el ISP. La dirección del par remoto es
10.0.0.9.La ruta predeterminada del enrutador es
10.0.0.9a través de10.0.0.10.El enrutador está conectado a un conmutador Ethernet a través de
eth0.eth0está configurado para utilizar una de las direcciones públicas.El conmutador conecta todos los demás hosts públicos. Cada host conectado utiliza una dirección IP pública.
10.0.0.9
ISP ----------+
| 10.0.0.10 X.X.X.X
+------------- (eth1) ROUTER (eth0) --------------- SWTICH
|
+-- X.X.X.Y
+-- X.X.X.Z
...
Mi problema
Todo funciona como se esperaba excepto los programas que se ejecutan en el enrutador. Cualquier aplicación que ejecuto en el enrutador se utiliza 10.0.0.10como dirección IP de origen al iniciar conexiones a Internet. Esto es comprensible ya que eth1es donde está disponible Internet. Sin embargo, debido a que la dirección no se puede enrutar públicamente, apt, pingy otros programas no funcionan. Si configuro explícitamente la dirección de origen en aplicaciones que la admiten (es decir, ping), las aplicaciones funcionan.
Mi pregunta
¿Cómo puedo configurar el enrutador para enrutar paquetes desconocidos a través de eth1/ 10.0.0.9y al mismo tiempo utilizar la dirección IP pública eth0como fuente predeterminada al iniciar nuevas conexiones?
Respuesta1
Nota: Consideraré que la LAN de su enrutador es 192.0.2.0/24 y su IP de LAN eneth0es 192.0.2.1/24, para poder dar explicaciones concretas y una solución.
Su ISP, para ahorrar algunas direcciones IP públicas, le asignó IP privadas para fines de enrutamiento interno. Eso está bien porque esta IP nunca debe verse en el exterior (y sería eliminada rápidamente porReenvío de ruta inversa estrictoa lo largo de la ruta si alguna vez conecta el cable más allá del enrutador de su ISP, o si no, dado que no es enrutable, nunca recibirá una respuesta). Pero esto hace que su configuración sea más compleja para evitar que esta IP se utilice en todos los casos excepto en la conectividad al ISP, desde su enrutador.
Probablemente tengas algo similar a esto (puede que sea ligeramente diferente, no importa):
# ip route
default via 10.0.0.9 dev ppp0
10.0.0.9 dev ppp0 proto kernel scope link src 10.0.0.10
192.0.2.0/24 dev eth0 proto kernel scope link src 192.0.2.1
Es posible, por ejemplo, que tenga en su lugar default via 10.0.0.9 dev ppp0 src 10.0.0.10, o que via 10.0.0.9ni siquiera aparezca, ya que es un enlace de capa 3 en lugar de un enlace de capa 2, por lo que viano es necesario (pero aún así se acepta). Simplemente adapte la configuración a continuación en consecuencia.
Actualmente, el kernel elige la IP aparentemente más adecuada, la que está configurada en el mismo lado para acceder a Internet, ya que nada le dice lo contrario (o le dice explícitamente que use la IP que no desea):
# ip route get 8.8.8.8
8.8.8.8 via 10.0.0.9 dev ppp0 src 10.0.0.10 uid 0
cache
Sólo necesita reemplazar el comportamiento de enrutamiento cuando el kernel verifica cómo acceder a Internet e indica una dirección IP de origen preferida específica. Tenga en cuenta que podría perder la conectividad en caso de errores y problemas imprevistos. Tenga acceso alternativo (consola) si es posible:
# ip route replace default via 10.0.0.9 dev ppp0 src 192.0.2.1
# ip route get 8.8.8.8
8.8.8.8 via 10.0.0.9 dev ppp0 src 192.0.2.1 uid 0
cache
Eso es todo, su enrutador enrutará como de costumbre, pero cuando necesite elegir una IP saliente originada localmente, seleccionará 192.0.2.1 a menos que se indique explícitamente lo contrario (por ejemplo: el proceso vincula explícitamente la IP de origen en su socket).
Esta ruta debe configurarse nuevamente cada vez que se baja y se levanta el enlace. Depende de usted integrar esto en algún script pppoe, una vez que el vínculo esté completamente establecido.
Tenga en cuenta también que el nombre de la interfazppp0podría cambiar appp1o cualquier otro nombre. Depende de usted lidiar con esto en sus scripts de configuración.
Métodos alternativos para establecer esta misma configuración de ruta:
agregar una métrica más baja, cuando se establece una métrica inicialmente
Si se configuró la métrica original (es decir, no era 0, digamos que era 100), puede agregar una ruta predeterminada alternativa con una métrica más baja en lugar de reemplazar la anterior:
# ip route add default via 10.0.0.9 dev ppp0 src 192.0.2.1 metric 50regla de enrutamiento dedicada
Si teme la interacción de varias herramientas involucradas en pppoe que podrían eliminar la ruta anterior, puede instalar esta configuración en una tabla de enrutamiento alternativa y darle prioridad en las reglas de enrutamiento, con una copia parcial de la tabla principal para evitar interrupciones. Esto aún tendrá que rehacerse después de cada desconexión/reconexión, porque la ruta seguirá desapareciendo. Aquí
iif loes especial y realmente significa "paquete saliente originado localmente" en lugar de entrante, y 109 es un valor de tabla elegido arbitrariamente:# ip rule add iif lo lookup 109 # needed only once # ip route add table 109 10.0.0.9 dev ppp0 proto kernel scope link src 10.0.0.10 # to keep using 10.0.0.10 for local link, just in case # ip route add table 109 192.0.2.0/24 dev eth0 src 192.0.2.1 # will disappear if eth0 is brought down # ip route add table 109 default via 10.0.0.9 dev ppp0 src 192.0.2.1 # will disappear if ppp0 is brought downSi agregó otras entradas de enrutamiento en la tabla principal, es probable que también tenga que copiarlas arriba.
# ip route get 8.8.8.8 8.8.8.8 via 10.0.0.9 dev ppp0 table 109 src 192.0.2.1 uid 0 cachereglas de enrutamiento con ruta simplificada
Se pueden mantener las rutas en la tabla principal y anular solo la ruta predeterminada con un supresor basado en prefijo en la regla: esto evita tener que copiartodorutas: uno puede simplemente copiar y cambiar la ruta predeterminada.
Reemplace 2. con (indicando los valores de preferencia, aún poniéndolos en orden descendente como sucedería sin indicarlos):
# ip rule add pref 32765 iif lo lookup 109 # needed only once # ip rule add pref 32764 iif lo lookup main suppress_prefixlength 0 # needed only once # ip rule 0: from all lookup local 32764: from all iif lo lookup main suppress_prefixlength 0 32765: from all iif lo lookup 109 32766: from all lookup main 32767: from all lookup default # ip route add table 109 default via 10.0.0.9 dev ppp0 src 192.0.2.1 # will disappear if ppp0 is brought downLa tabla de enrutamiento principal se usará primero para cualquier cosa que no sea la ruta predeterminada, luego, para el tráfico saliente originado localmente, la ruta predeterminada se proporciona en la tabla de enrutamiento 109. Cualquier otra cosa continuará y buscará nuevamente en la tabla principal la ruta predeterminada como habitual.
La ventaja sobre 2. es que no es necesario duplicar rutas (no predeterminadas) de la tablaprincipalen la tabla 109 más. Abajo, tablaprincipalproporciona el resultado para una ruta no predeterminada, al contrario del segundo método:
# ip route get 8.8.8.8 8.8.8.8 via 10.0.0.9 dev ppp0 table 109 src 192.0.2.1 uid 0 cache # ip route get 192.0.2.2 192.0.2.2 dev eth0 src 192.0.2.1 uid 0 cache
Respuesta2
Tal como dijiste. Los otros clientes en el conmutador con su enrutador como puerta de enlace tienen direcciones IP públicas. Su enrutador no. Tiene una dirección LAN que no será enrutada. Dado que su proveedor de servicios de Internet NO le proporcionó una dirección pública, el enrutador NO podrá salir.
Si tiene otra IP pública, cree una configuración eth virtual en eth1 y enrútela correctamente. Entonces su enrutador también podrá apagarse.