Tengo una situación idéntica a la pregunta enVPN IPSec: el tráfico no se enruta correctamente(sin embargo, parece que no puedo comunicarme con ese usuario directamente, ni puedo hacer un comentario sobre esa pregunta, y nadie ha respondido nunca).
Yo también tengo un servidor Windows 2008 R2, con una VPN IPSec que termina directamente en el servidor.
El servidor tiene una única interfaz de red, que tiene una dirección IP pública (llamémosla 203.10.10.10, por ejemplo).
Me gustaría que las computadoras en una red privada remota (10.16.0.0/255.254.0.0) pudieran conectarse a ese servidor de Windows en una dirección IP privada al final de un túnel IPSec que terminaenese servidor (no en un enrutador frente al servidor).
Igual de importante (y este podría ser el punto conflictivo) necesito que el servidor pueda iniciar una conexión TCP a dispositivos en la red remota (10.16.0.0) (por ejemplo, para descargar una imagen a través de HTTP).
Así es como se ve:
La IP privada que he elegido para el servidor es 192.168.70.1/255.255.255.0 y los filtros IPSec que establecen el túnel a la red privada remota son para origen/destinos 192.168.70.0/24 y 10.16.0.0/15.
Si hago ping a una dirección en la red remota desde el servidor de Windows, con el argumento fuente configurado, entonces puedo establecer el túnel y los pings funcionarán (es decir ping -S 192.168.70.1 10.16.0.1).
Sin embargo, cualquier tráfico "normal" enviado a una dirección 10.16.xx (incluidos los pings sin la dirección de origen forzada a 192.168.70.1) se envía alegremente a Internet a través de la ruta predeterminada y no inicia ni ingresa al túnel.
PREGUNTA
¿Es posible una configuración como esta? ¿O no es posible que el punto final de VPN envíe datos por el túnel, originados en una de sus direcciones privadas? (¿Es siempre necesario que el punto final de VPN esté en un enrutador separado del dispositivo que envía datos a través del túnel?)
¿Cómo puedo configurar Windows Server para garantizar que todas las comunicaciones con la red 10.16.0.0 se originen desde su dirección IP privada?
La dirección privada notenerser 192.168.70.1: se podría elegir otra subred si es necesario (digo esto porque he leído que, en igualdad de condiciones, Windows Vista y versiones posteriores usarán la IP de origen que más se acerque al destino, por lo que quizás usar una ¿Sería útil 10.XXX ip para la dirección privada del servidor?)
Sin embargo, no puedo realizar pruebas tan fácilmente, ya que el otro extremo de este túnel VPN no está bajo mi control, y necesitaría que los ingenieros de red en el otro extremo realicen cambios de configuración si decido cambiar la dirección 192.168.70.1. .
INFORMACIÓN ADICIONAL: LO QUE HE PROBADO HASTA AHORA
Probé dos métodos para configurar esa dirección IP privada (en el servidor de Windows) en un intento de que los paquetes se enruten correctamente.ysatisfacer las reglas IPSec que establecen el túnel.
Dirección privada en la interfaz principal.
Con la dirección 192.168.70.1 agregada a la interfaz de red principal (además de la IP pública), no parece posible definir ninguna ruta a 10.16.0.0 que haría que Windows use 192.168.70.1 como dirección de origen. Cualquier tráfico destinado a la puerta de enlace predeterminada terminará con la IP pública como fuente.
Si hay alguna magia disponible en cuanto a rutas en Windows que no conozco, ¡me encantaría saberlo! Sin embargo, el comando:
route add 10.16.0.0 mask 255.254.0.0 192.168.70.1
resultará en que se agreguen rutas de la siguiente manera (recoge la IP pública en esa misma interfaz para usarla como puerta de enlace de origen/enlace).
10.16.0.0 255.254.0.0 On-link 203.10.10.10 11 10.17.255.255 255.255.255.255 On-link 203.10.10.10 266
Dirección privada en un segundo adaptador virtual
Intenté agregar un adaptador de red virtual al servidor, primero con el dispositivo Microsoft Loopback Adapter. El dispositivo Loopback apareció en la lista de conexiones de red con sus "medios desconectados". Al ver que la NIC virtual no tenía conectividad, Windows simplemente volvió a enviar tráfico a través de la ruta predeterminada de todos modos (con la dirección de origen pública).
Luego probé con un controlador de dispositivo virtual diferente: el controlador del adaptador virtual TAP que viene con OpenVPN. Ese controlador le permite forzarlo a un estado "siempre conectado". Sin embargo, parece que después del primer ping, Windows nuevamente descubre que no hay conectividad en ese adaptador y vuelve a enviar tráfico a través de la puerta de enlace predeterminada en la interfaz principal (pública).
Entonces eso es todo... ¿alguna idea?
Respuesta1
Estás luchando contra las tendencias naturales de cómo funciona la selección de la dirección IP de origen al intentar hacer esto. Entonces, ¿por qué no cambiar un poco el diseño para que fluya de forma más natural?
El problema es que la selección de la dirección IP de origen se realiza antes de la decisión de impulsar el tráfico por el túnel. Eso significa que elegirá utilizar la dirección IP "pública" como IP de origen para cualquier tráfico que se origine a través del túnel.
En algunos sistemas operativos, puede hacer cosas divertidas con el enrutamiento, especificando direcciones de origen en una ruta para el tráfico originado en el host. Aunque no puedo encontrar nada parecido en Windows.
Sin embargo, dado el diseño de su red, creo que la forma más sencilla de resolver este problema es dejar de luchar con las direcciones RFC1918 en el lado del servidor y simplemente seguir adelante y configurar un túnel con SA entre su IP pública 203.10.10.10 y la IP privada. direcciones 10.16.0.0/15.
Luego, los clientes se dirigirían al servidor como 203.10.10.10 en lugar de 192.168.70.1 y, con suerte, todo lo demás encajaría mágicamente en su lugar. De esa manera, la selección de IP de origen ya seleccionará una dirección adecuada que funcionará.
Puede mantener la antigua política ipsec durante un período de transición, de modo que sus clientes puedan dirigirse al servidor con la antigua dirección RFC1918 o con la nueva dirección pública, mientras su caché DNS caduca (suponiendo que esté usando DNS para esto). si no, es una buena idea). Después de un período de transición, la dirección 192.168.70.1 ya no tiene ninguna función.
La otra opción es elegir explícitamente la dirección IP de origen al iniciar conexiones desde su servidor, lo cual puede ser posible si se trata de un software personalizado que usted mismo haya escrito, pero eso es un poco complicado.
Finalmente, la idea del adaptador de bucle invertido es prometedora, aunque es extraño que aparezca como "medio desconectado". Sin embargo, eso suena más como un problema con el adaptador loopback en sí que con la idea.