Tengo un enrutador con DD-WRT v24-sp2 instalado y tengo problemas para acceder a otra dirección IP configurada dentro de la misma subred que mi dirección IP pública. Mi ISP requiere establecer una conexión WAN mediante DHCP, por lo que tanto la IP como la puerta de enlace se asignan automáticamente. La dirección IP asignada a la interfaz WAN también es una dirección IP pública.
Entonces, para ilustrar este ejemplo:
DD-WRT router -> [lan] ip: 192.168.1.1/24
[wan] ip: 12.34.56.78/24 (public IP)
Ahora supongamos que mi vecino usa el mismo ISP con la misma configuración y, por lo tanto, está conectado a la misma 12.34.56.0/24red pública (por ejemplo, con la dirección IP WAN 12.34.56.10) y expone algunos servicios en esa IP pública. El problema que tengo es que no puedo acceder a ese servicio ni siquiera hacer ping a la IP pública de mi vecino desde mi enrutador DD-WRT ni desde ningún dispositivo conectado a este enrutador.
Puedo acceder a este servicio sin ningún problema cuando uso una conexión a Internet diferente, por lo que estoy 100% seguro de que este problema persiste solo detrás de mi enrutador DD-WRT.
Mi tabla de enrutamiento tiene el siguiente aspecto:
root@DD-WRT:~# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 12.34.56.1 0.0.0.0 UG 0 0 0 vlan2
12.34.56.0 0.0.0.0 255.255.255.0 U 0 0 0 vlan2
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 br0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 br0
192.168.66.0 192.168.66.2 255.255.255.0 UG 0 0 0 tun0
192.168.66.2 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
¿Alguna idea de cómo empezar a abordar eso?
Respuesta1
Yo tampoco soy un experto. Escribo esto porque tengo una configuración similar con mi ISP (WAN como /24subred), con una tabla de enrutamiento similar. La diferencia es que funciona. Incluso puedo olfatear paquetes que viajan desde o hacia algunos de mis "vecinos" (aunque no todos; creo que son aquellos con quienes comparto un centro).
traceroutea mi "vecino" muestra un solo salto como esperaba.
En su caso, parece que no hay una conexión de un solo salto entre usted y su vecino o que algunos dispositivos transparentes lo separan por alguna razón. De cualquier manera, la configuración de su ISP no es exactamente lo que esperaría según la configuración de DHCP que obtiene. Hay alguna peculiaridad por parte del ISP. Lo correcto que debe hacer el ISP puede ser:
- permitirle a usted y a su vecino comunicarse con un salto a través de dispositivos transparentes como concentradores, conmutadores, etc., lo que hará de esta una subred normal; o
- permitiéndole a usted y a su vecino comunicarse con dos saltos a través de la puerta de enlace.
Lo que puedes probar por tu cuenta
Este segundo punto anterior no significa que no tengas permitido comunicarte con tu vecino a través de la puerta de enlace.ahora. Es posible que tenga permiso o no; la puerta de enlace puede configurarse de cualquier manera. El punto es: con su tabla de enrutamiento actual no lo está intentando.
La segunda línea de su tabla de enrutamiento ( 12.34.56.0 …) le dice a su enrutador que siempre que necesite enviar un paquete a su vecino debe enviarlo con la IP del vecino.ydirección de hardware (MAC) como destino. La dirección del hardware es inicialmente desconocida, por lo que el enrutador la transmite. Esto nunca llega al vecino y estás atascado.
Intente eliminar temporalmente la segunda fila de la tabla de enrutamiento:
route del -net 12.34.56.0 netmask 255.255.255.0 dev vlan2
y dejar actuar al predeterminado. Cada paquete de usted a su vecino estará destinado a su IP pero a la dirección de hardware de la puerta de enlace (de manera similar a cuando se comunica con el mundo exterior). Ahora es el trabajo de la puerta de enlace entregar este paquete. Puede que haga esto o no.
En mi caso, si elimino la regla de enrutamiento adecuada, aún puedo comunicarme con mis "vecinos"; traceroutemuestradosSaltos, el nodo medio es la puerta de enlace de mi ISP. El problema está en las respuestas: están destinadas directamente a mi dirección de hardware debido a la de mi "vecino"inalteradotabla de ruteo. Esto funciona para mí pero no funcionaría para ti. Entonces tu vecinodebehaz el mismo truco consutabla de enrutamiento y luegopuedetrabajar.
Resulta que tengo acceso de administrador a uno de mis "vecinos". Cambié su tabla de enrutamiento y la mía. Luego confirmé que wiresharklos paquetes saltan a través de la puerta de enlace (usando su dirección de hardware) en ambas direcciones.
Si funciona para usted y su vecino, haga que este cambio sea permanente de alguna manera. Por supuesto, esta es una solución alternativa y sería mejor si su ISP cambiara la configuración.