Hola, no soy realmente administrador de sistemas ni experto en redes, así que ten cuidado conmigo.
Estoy intentando enrutar a través de VPN en Windows 7. Agregué
route -p ADD 10.165.0.0 MASK 255.255.0.0 10.124.16.2 METRIC 1
Y funcionó bien. puedo ver en mi
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 192.168.0.1 192.168.0.4 266
10.124.16.0 255.255.255.0 192.168.3.1 192.168.3.106 20
10.124.23.0 255.255.255.0 192.168.3.1 192.168.3.106 20
10.165.0.0 255.255.0.0 192.168.3.1 192.168.3.106 20
Entonces reconoció automáticamente que tiene que pasar primero a través de la puerta de enlace VPN, que es 192.168.3.1.
Cuando hice lo mismo con otra dirección:
route -p ADD 10.139.0.0 MASK 255.255.0.0 10.124.16.2 METRIC 1
Obtengo rutas activas:
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 192.168.0.1 192.168.0.4 266
10.124.16.0 255.255.255.0 192.168.3.1 192.168.3.106 20
10.124.23.0 255.255.255.0 192.168.3.1 192.168.3.106 20
10.139.0.0 255.255.0.0 10.124.16.2 192.168.3.106 21
10.165.0.0 255.255.0.0 192.168.3.1 192.168.3.106 20
Creo que no es correcto porque no puede llegar directamente a "10.124.16.2". Por otro lado, espero que las rutas activas se combinen con prioridad de arriba hacia abajo. Lo que significa que si la segunda línea indica cómo enrutar 10.124.16.0 aún puede funcionar, ¿verdad?
De todos modos, también intenté configurar explícitamente la interfaz VPN:
Interface List
17...44 45 53 54 4f 53 ......Kerio Virtual Network Adapter
usando:
route -p ADD 10.139.0.0 MASK 255.255.0.0 10.124.16.2 METRIC 1 IF 17
Intenté reiniciar la máquina, omitir -p, hacer route delete 10.139.0.0, intentar vaciar algunos billetes con el comando netsh interface ip delete destinationcache, pero nada ayudó. No puedo hacer ping ahí y tracertno me dice ninguna ip - solo:
Tracing route to 10.139.16.167 over a maximum of 30 hops
1 * * * Request timed out.
Nuestro informático me dijo que mi enrutamiento es correcto y que mi Windows debe recordar algo incorrecto en algún caché. Me dijo que tiene la misma ruta y trabaja para él.
¿Alguna idea de qué puede estar mal? Estoy realmente perdido, sin pistas y desesperado porque necesito llegar allí...
Respuesta1
Entonces, problema resuelto: a veces, si su departamento de TI le dice que el problema está en su sitio, solo necesita decirles: no hay ningún problema de su lado. Me faltaba algo de derecha en el lado del servidor VPN...
De todos modos, se nos ocurren buenos trucos: puedes intentar configurar ambas puertas de enlace y crear ventanas para resolverlo, así:
Network Address Netmask Gateway Address Metric
10.139.0.0 255.255.0.0 192.168.3.1 1
10.139.0.0 255.255.0.0 10.124.16.2 1
Probablemente no sea correcto, pero en caso desesperado puedes intentarlo.
Otra mejor opción si (desafortunadamente) estás en Windows es instalar wireshark. Espía la interfaz deseada y verifica si el paquete ping se envía en esa interfaz. Si es así, ve a tu TI y deja que lo resuelvan;)
En Linux puedes preguntar directamente:/sbin/ip route get 10.139.16.167
Y lo último es reinstalar su cliente SVN. Después de todo, el hecho de que vaya a su IP virtual no significa que el cliente VPN esté funcionando y reenviándolo a través de su interfaz real (y es difícil espiar esto ya que es un canal cifrado)