Cómo entender la tabla de enrutamiento en un cliente OpenVPN

13

Acabo de configurar OpenVPN y está funcionando como se esperaba. Sin embargo, la tabla de enrutamiento del cliente me confunde sin fin. Aquí está la tabla de rutas:

# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.8.0.5        0.0.0.0         255.255.255.255 UH    0      0        0 tun0
10.8.0.1        10.8.0.5        255.255.255.255 UGH   0      0        0 tun0
54.202.18.143   10.0.2.2        255.255.255.255 UGH   0      0        0 eth0
10.0.2.0        0.0.0.0         255.255.255.0   U     1      0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 eth0
0.0.0.0         10.8.0.5        128.0.0.0       UG    0      0        0 tun0
128.0.0.0       10.8.0.5        128.0.0.0       UG    0      0        0 tun0
0.0.0.0         10.0.2.2        0.0.0.0         UG    0      0        0 eth0

Así que diseccionemos línea por línea

  1. Cualquier paquete destinado a 10.8.0.5no tiene puerta de enlace y utilizarátun0
  2. cualquier paquete destinado a 10.8.0.1utilizará 10.8.0.5como puerta de enlace a través detun0
  3. cualquier paquete destinado a 54.202.18.143utilizará 10.0.2.2como puerta de enlace a través deeth0
  4. cualquier paquete destinado a 10.0.2.0/24no tiene puerta de enlace y utilizaráeth0
  5. Vamos a ignorar la parte 169.254.0.0
  6. Todos los demás paquetes (destinados a 0.0.0.0) nos serán utilizados 10.8.0.5como puerta de enlace predeterminada a través de tun0. Entonces esta es la puerta de enlace predeterminada, ¿no?
  7. Cualquier paquete destinado a 128.0.0.0/7utilizará 10.8.0.5como puerta de enlace predeterminada a través detun0
  8. Todos los demás paquetes ( 0.0.0.0) se utilizarán 10.0.2.2como puerta de enlace predeterminada a través deeth0

Preguntas:

  • ¿Tengo 2 puertas de enlace predeterminadas si consideramos los puntos 6 y 8? (sin embargo, solo puede haber 1 puerta de enlace predeterminada, así que sé que estoy equivocado pero no puedo justificarlo) ( probablemente respondido, ver más abajo )
  • Teniendo en cuenta los puntos 1 y 2, todo lo que sucede 10.8.0.1realmente no está utilizando ninguna puerta de enlace a través de tun0. ¿Es esto correcto?
  • Teniendo en cuenta los puntos 3 y 4, todo lo que sucede 54.202.18.143no está utilizando ninguna puerta de enlace eth0. ¿Es esto correcto?

ACTUALIZAR...

Después de leer esto , encontré más información. Las siguientes líneas tienen mucho sentido para mí ahora:

0.0.0.0         10.8.0.5        128.0.0.0       UG    0      0        0 tun0
128.0.0.0       10.8.0.5        128.0.0.0       UG    0      0        0 tun0

Entonces, la primera línea está definiendo 0.0.0.0/128.0.0.0y la segunda está definiendo 128.0.0.0/128.0.0.0. Esencialmente:

0.0.0.0/128.0.0.0 = 0.0.0.0/1 = 0.0.0.0 TO 127.255.255.255
128.0.0.0/128.0.0.0 = 128.0.0.0/1 = 128.0.0.0 TO 255.255.255.255

Entonces, las 2 rutas anteriores cubren todo el rango de direcciones IPv4 [0.0.0.0 TO 255.255.255.255]. OpenVPN es una forma inteligente de agregar una ruta predeterminada sin reemplazar la ruta predeterminada original y esta ruta predeterminada se enrutará a través de tun0.

Entonces creo que tengo una respuesta para mi primera pregunta:

¿Tengo 2 puertas de enlace predeterminadas si consideramos los puntos 6 y 8?

NO, solo hay una puerta de enlace predeterminada y es:

0.0.0.0         10.0.2.2        0.0.0.0         UG    0      0        0 eth0
linux  networking  routing  openvpn 
— slayedbylucifer
fuente
2
La primera 0.0.0.0ruta tiene Genmask, 128.0.0.0que probablemente no la convierta en una ruta predeterminada. Sin embargo, debo decir que no tengo la menor idea de lo que significa esta máscara y para qué sirve la ruta: /
— Martin von Wittich
También ser awarfe que 128.0.0.0 enrutamiento dentro de su red es muy extraño porque es IP pública o reservada i don "t remeber pero en ambos casos esto es extraño..
— Kiwy
La parte 128.0.0.0 proviene de openvpn. se explica aquí
— slayedbylucifer
Debería convertir su "ACTUALIZACIÓN" en una respuesta, ya que es solo esto: una respuesta que me ayudó a comprender exactamente el mismo problema que estaba teniendo :)
— WoJ
@slayedbylucifer la explicación de 128.0.0.0 parece estar inactiva y no hay ningún archivo disponible. ¿Tienes un enlace en línea sobre esto?
— SaAtomic

Respuestas:

4

¿Tengo 2 puertas de enlace predeterminadas si consideramos los puntos 6 y 8? (sin embargo, solo puede haber 1 puerta de enlace predeterminada, así que sé que estoy equivocado pero no puedo justificarlo) (probablemente respondido, ver más abajo)

La sexta línea define el rango 0.0.0.0 - 127.255.255.255 y la séptima línea define el rango 128.0.0.0 - 255.255.255.255.

¿Tengo 2 puertas de enlace predeterminadas si consideramos los puntos 6 y 8?

NO, solo hay una puerta de enlace predeterminada y es:

0.0.0.0         10.0.2.2        0.0.0.0         UG    0      0        0 eth0

Teniendo en cuenta los puntos 1 y 2, todo lo que sucede con 10.8.0.1 no está utilizando realmente ninguna puerta de enlace a través de tun0. ¿Es esto correcto?

No, no es correcto, los paquetes destinados a 10.8.0.1 se enrutarán a 10.8.0.5 (que es accesible por tun0 lan según lo establecido por la primera línea).
tenías razón si la máscara de red no era 255.255.255.255

Teniendo en cuenta los puntos 3 y 4, cualquier cosa que ocurra para 54.202.18.143 realmente no está utilizando ninguna puerta de enlace a través de eth0. ¿Es esto correcto?

No, no es correcto, los paquetes destinados a 54.202.18.143 se enrutarán a 10.0.2.2 (que es otro host en eth0 lan y es accesible por la cuarta línea)

— Arash
fuente
La primera pregunta es respondida por usted mismo. Solo quería que la respuesta estuviera completa, así que la mencioné.
— Arash
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.