NAT 1: 1 con varias LAN idénticas


13

Quiero conectar varias LAN ubicadas en edificios remotos.
El sitio "central" tiene una computadora Linux con OpenVPN. Cada sitio remoto también ejecuta OpenVPN.

  1. el sitio central tiene una LAN numerada 192.168.0.0/24
  2. varios sitios remotos también están numerados 192.168.0.0/24
  3. No puedo / no quiero / no quiero / lo que sea modificar la numeración LAN
  4. No tengo control sobre la mayoría de los OpenVPN remotos

Luego necesito:
1. definir LAN virtuales
2. configurar un NAT 1: 1 para cada sitio
3. el NAT 1: 1 debe configurarse en el enrutador central

Mapa LAN .
Por lo tanto, se considera que cada sitio tiene una LAN 10.10.x.0 / 24.
Cuando una computadora quiere alcanzar, digamos, 192.168.0.44 en el sitio 12, solo tiene que enviar un paquete a 10.10.12.44

Operar una VPN no es un problema para mí. Actualmente conecto más de 60 sitios. Pero no encuentro una manera simple de hacer esto NAT 1: 1.

Aquí hay un ejemplo de un paquete enviado desde el sitio central a un sitio remoto, y su paquete de respuesta:

ingrese la descripción de la imagen aquí

Hice algunas pruebas con iptables NETMAP pero no puedo hacer que funcione porque no encuentro una manera de modificar el origen + destino después de la decisión de enrutamiento.
Prefiero evitar la nueva --client-natfunción de OpenVPN.
Tal vez tengo que forzar el enrutamiento con ip route? ¿O para pasar dos veces en la pila de red con veth?

Nota: no quiero usar disfraces. Solo 1/1 NAT.

EDITAR:
No es posible con una configuración regular de openVPN. Debido a que un paquete de un sitio remoto es indistinguible de un paquete de otro sitio: ambos tienen direcciones de origen y destino similares, y ambos provienen de la misma interfaz tun (o tap). Por lo tanto, no es posible fuente-NAT.

Solución 1: haga el NAT en los sitios remotos. No es posible en mi caso. Tengo que hacerlo solo en el sitio central.

Solución 2: configure una VPN para cada sitio remoto. Así que tendré un tun para cada uno. Creo que esto puede estar bien. No es muy eficiente en memoria pero está bien.

Solución 3: configure un túnel (sin cifrar) dentro de la VPN para cada sitio. Esto le dará una interfaz para cada uno. Los túneles simples no son multiplataforma (para mi conocimiento). Por ejemplo, GRE o ipip o sit están bien para Linux, pero algunos sitios distantes solo ejecutan una computadora con Windows, por lo que openVPN está instalado en ella. Tan imposible de configurar un túnel simple. Otra opción es usar un túnel más complicado (¿cuál?) Pero la sobrecarga en el sistema y en el administrador del sistema puede ser mayor que tener múltiples VPN

Solución 4: compile la última versión de openVPN, ya que incluye una función NAT 1: 1. Pruebo esto esta semana.


1
Para la solución 4 no tiene que compilar. La mayoría de las principales distribuciones de Linux han compilado paquetes en el sitio web oficial de openVPN. Pero esto no funcionará para usted porque la característica --client-nat es una opción fácil de usar. Por lo tanto, sus clientes también deben usar la última versión de RC (y usted dice que no tiene control sobre sitios remotos).
Gregory MOUSSAT

1
Bueno, me equivoco: la característica --client-nat está 100% dentro de OpenVPN (pensé que estaba usando ipfilter). Acabo de probar: también funciona en Windows. Vea mi solución a continuación.
Gregory MOUSSAT

Me gustaría saber si alguna vez lo hiciste funcionar y qué hiciste.
Michael Grant

Respuestas:


2

Una solución muy básica es:
1. usar OpenVPN 2.3 o más (actualmente, el último es 2.3-alpha) para servidores + clientes
2. usar la opción de configuración de OpenVPN a continuación
3. no usar nada más (sin ipfilter, sin trucos)

En el lado del servidor, debe distribuir manualmente las direcciones VPN (por lo que no hay serveropción, debe usar ifconfigo ifconfig-push):

# /etc/openvpn/server.conf
ifconfig 10.99.99.1 10.99.99.2
route 10.99.99.0 255.255.255.0
push "route 10.99.99.0 255.255.255.0"
push "client-nat dnat 10.99.99.11 255.255.255.255 10.10.111.11"
push "client-nat dnat 10.99.99.12 255.255.255.255 10.10.112.12"
push "client-nat dnat 10.99.99.13 255.255.255.255 10.10.113.13"

El routee push routey client-natse requieren líneas si desea comunicarse directamente entre enrutadores ( ping 10.99.99.1desde un sitio distante A TRAVÉS la VPN). De lo contrario, puedes descartarlos.

.

.

Ahora tiene que elegir una dirección de red virtual. Mantuve lo mismo que usaste en tu ejemplo: 10.10.0.0/16 Permites el
enrutamiento para esto:

# /etc/openvpn/server.conf
route 10.10.0.0 255.255.0.0
push "route 10.10.0.0   255.255.0.0"

.

.

Ahora debe indicar al cliente que use el NAT 1: 1:

# /etc/openvpn/ccd/client_11
ifconfig-push 10.99.99.11 10.99.99.1
push "client-nat snat 10.99.99.11 255.255.255.255 10.10.111.11"
push "client-nat snat 192.168.0.0 255.255.255.0 10.10.11.0"
push "client-nat dnat 10.10.10.0 255.255.255.0 192.168.0.0"
iroute 10.10.11.0 255.255.255.0
iroute 10.10.111.0 255.255.255.0

La primera línea establece la dirección del enrutador remoto. Tenga cuidado con el controlador de Windows que requiere direcciones especiales.
La segunda y última línea permiten que el enrutador distante se comunique desde su interfaz 10.99.99.x.
La tercera y cuarta líneas hacen el origen y el destino 1: 1 NAT
La quinta línea le dice a OpenVPN qué hacer con los paquetes correspondientes.

Este método permite conectar sitios con direcciones LAN idénticas (o no), sin ningún host sombreado.


1
Simple, brillante
Bertrand SCHITS

Intenté esto pero no pude hacerlo funcionar. Estoy usando Linux en ambos lados. Algunas cosas son extrañas o no entiendo algo completamente. Su ifconfig-push en el archivo client_11 (primera línea), ¿no debería ser una máscara de red para el segundo argumento en lugar de 10.99.99.1? Segundo, ¿por qué estás usando esta tercera red 10.10.111.0/24? Parece que está tratando de usar la red 111 para la comunicación entre sitios, ¿no se puede usar la red 10.10 para eso directamente? Por último, no importa lo que intente, no veo (en tcpdump) el snat y el dnat que afectan los paquetes en el cliente.
Michael Grant

No es realmente simple pero sigue siendo brillante.
Neurotransmisor el

4

He hecho algo similar con las interfaces reales, pero no puedo ver por qué no funcionaría con las interfaces VPN.

La idea es que, como tiene la misma subred disponible en diferentes interfaces en ese enrutador, complica el enrutamiento. Básicamente, cuando un paquete para 10.10.13.123 ingresa al enrutador, se DNAT antes de enrutar a 192.168.0.123, por lo que debe poder indicar el enrutamiento que estaba destinado a 192.168.0.123 en la interfaz VPN13 .

Eso se puede hacer usando marcas de firewall y reglas de enrutamiento que usan esas marcas. SNAT y DNAT se deben hacer con el objetivo del firewall NETMAP. Para SNAT, es el mismo problema, en POSTROUTING, ha perdido la información de que el paquete proviene de esta o aquella interfaz y todos tienen la dirección de origen 192.168.0.x. Por lo tanto, también necesita una marca para llevar esa información desde mangle-PREROUTING a nat-POSTROUTING. Puede usar la misma marca, pero eso significaría que esos paquetes usarían esa tabla de enrutamiento alternativa, por lo que necesitaría duplicar la tabla de enrutamiento global en todos.

Para cada red, harías:

lnet=192.168.0.0/24
if10=eth0 if11=tun0 if12=tun1 if13=tun2

n=0
for site in 10 11 12 13; do
  table=$site
  net=10.10.$site.0/24
  n=$(($n + 1))
  eval "interface=\$if$site"
  inmark=$(($n * 2)) outmark=$(($n * 2 + 1))

  iptables -t nat -A PREROUTING -d "$net" -j NETMAP --to "$lnet"
  iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -m mark --mark "$inmark"/0xf -j NETMAP --to "$net"
  iptables -t mangle -A PREROUTING -i "$interface" -j MARK --set-mark "$inmark"/0xf
  iptables -t mangle -A PREROUTING -d "$net" -j MARK --set-mark "$outmark"/0xf
  ip rule add fwmark "$outmark"/0xf table "$table"
  ip route add "$lnet" dev "$interface" table "$table"
done

Arriba, estamos usando los primeros 4 bits de la marca , para permitir que se enruten hasta 7 redes de esa manera.


1
Gracias por tu respuesta. Lo probé pero no funciona. Probé con una sola LAN, sin más resultados. Uso tcpdump para monitorear los paquetes, y cuando envío un paquete desde el sitio remoto al centro, ni siquiera veo nada (¿cómo es posible?). Con sus instrucciones, trato de construir mi respuesta paso a paso. No estoy seguro de tener éxito.
Bertrand SCHITS el

2
Mi respuesta solo cubre qué hacer en el sitio central. Supongo que configura el enrutamiento correctamente en los otros sitios. Por ejemplo, probablemente necesite agregar una ruta a 10.10.0.0/16 a través del túnel VPN en los sitios remotos. También es posible que deba indicarle a openvpn que deje pasar esos paquetes. En cualquier caso, usando tcpdump para ver qué paquetes obtienen dónde y cómo es el enfoque correcto. el objetivo de LOG de iptables también es tu amigo.
Stéphane Chazelas

2
Si no ve ningún paquete, debe buscar en su registro openvpn. Probablemente encontrará paquetes descartados. Si este es el caso, use un "iroute 192.168.0.0 255.255.255.0" para cada cliente en su directorio de configuración de cliente
Gregory MOUSSAT
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.