¿Cómo se evita el conflicto de red con las redes internas de VPN?

Si bien existe una amplia variedad de redes privadas no enrutables a través de 192.168 / 16 o incluso 10/8, a veces al considerar un posible conflicto, todavía ocurre. Por ejemplo, configuré una instalación OpenVPN una vez con la red VPN interna en 192.168.27. Todo estuvo bien hasta que un hotel usó esa subred para el piso 27 en su wifi.

Volví a instalar la red VPN en una red 172.16, ya que parece que los hoteles y los cibercafés no la utilizan. ¿Pero es esa una solución adecuada al problema?

Si bien menciono OpenVPN, me encantaría escuchar pensamientos sobre este problema en otras implementaciones de VPN, incluido el simple IPSEC.

Tenemos varias VPN IPSec con nuestros socios y clientes y ocasionalmente encontramos conflictos de IP con su red. La solución en nuestro caso es hacer NAT de origen o NAT de destino a través de la VPN. Estamos utilizando productos Juniper Netscreen y SSG, pero supongo que esto puede ser manejado por la mayoría de los dispositivos VPN IPSec de gama alta.

Creo que cualquier cosa que uses, te arriesgarás a un conflicto. Diría que muy pocas redes usan rangos por debajo de 172.16, pero no tengo evidencia que lo respalde; solo el presentimiento de que nadie puede recordarlo. Podría usar direcciones IP públicas, pero eso es un desperdicio y es posible que no tenga suficiente de sobra.

Una alternativa podría ser usar IPv6 para su VPN. Esto requeriría configurar IPv6 para cada host al que desee acceder, pero definitivamente usaría un rango único, especialmente si obtiene un / 48 asignado a su organización.

Desafortunadamente, la única forma de garantizar que su dirección no se superponga con otra cosa es comprar un bloque de espacio de dirección IP pública enrutable.

Una vez dicho esto, podría intentar encontrar partes del espacio de direcciones RFC 1918 que sean menos populares. Por ejemplo, el espacio de direcciones 192.168.x se usa comúnmente en redes residenciales y de pequeñas empresas, posiblemente porque es el valor predeterminado en muchos dispositivos de red de gama baja. Sin embargo, supongo que al menos el 90% de las veces las personas que usan el espacio de direcciones 192.168.x lo usan en bloques de tamaño de clase C y generalmente comienzan su direccionamiento de subred en 192.168.0.x. Probablemente sea mucho menos probable encontrar personas que utilicen 192.168.255.x, por lo que podría ser una buena opción.

El espacio 10.xxx también se usa comúnmente, la mayoría de las redes internas de grandes empresas que he visto son 10.x espacio. Pero rara vez he visto personas usando el espacio 172.16-31.x. Estaría dispuesto a apostar que rara vez encontrarás a alguien que ya esté usando 172.31.255.x, por ejemplo.

Y, por último, si va a utilizar un espacio que no sea RFC1918, al menos intente encontrar un espacio que no pertenezca a otra persona y que no sea probable que se asigne para uso público en cualquier momento en el futuro. Hay un artículo interesante aquí en etherealmind.com donde el autor habla sobre el uso del espacio de direcciones RFC 3330 192.18.x que está reservado para pruebas de referencia. Eso probablemente sería viable para su ejemplo de VPN, a menos que, por supuesto, uno de sus usuarios de VPN trabaje para una empresa de marcas o equipos de red de referencia. :-)

El tercer octeto de nuestra clase pública C era .67, así que lo usamos adentro, es decir, 192.168.67.x

Cuando configuramos nuestra DMZ, utilizamos 192.168.68.x

Cuando necesitábamos otro bloque de direcciones, utilizamos .69.

Si hubiéramos necesitado más (y estuvimos cerca un par de veces) íbamos a renumerar y usar 10. para poder dar muchas redes a cada división de la compañía.

1. use subredes menos comunes como 192.168.254.0/24 en lugar de 192.168.1.0/24. Los usuarios domésticos suelen usar los bloques 192.168.xx y las empresas usan 10.xxx, por lo que puede usar 172.16.0.0/12 con muy pocos problemas.

2. usar bloques ip más pequeños; por ejemplo, si tiene 10 usuarios de VPN, use un grupo de 14 direcciones ip; a / 28. Si hay dos rutas a la misma subred, un enrutador utilizará primero la ruta más específica. Más específico = subred más pequeña.

3. Use enlaces punto a punto, usando un bloque / 30 o / 31 para que solo haya dos nodos en esa conexión VPN y no haya enrutamiento involucrado. Esto requiere un bloque separado para cada conexión VPN. Utilizo la versión de openVPN de Astaro y así es como me conecto a mi red doméstica desde otras ubicaciones.

En cuanto a otras implementaciones de VPN, IPsec funciona bien en un sitio a otro, pero es difícil de configurar, por ejemplo, una computadora portátil con Windows que viaja. PPTP es el más fácil de configurar, pero rara vez funciona detrás de una conexión NAT y se considera el menos seguro.

El uso de algo como 10.254.231.x / 24 o similar también podría hacer que pase desapercibido, ya que rara vez tienen redes 10.x lo suficientemente grandes como para comer su subred.