Tunneling una IP pública a una máquina remota

Tengo un servidor Linux A con un bloque de 5 direcciones IP públicas, 8.8.8.122/29. Actualmente, 8.8.8.122está asignado a eth0, y 8.8.8.123está asignado a eth0:1.

Tengo otra máquina Linux B en una ubicación remota, detrás de NAT. Me gustaría configurar un túnel entre los dos para que B pueda usar la dirección IP 8.8.8.123como su dirección IP principal.

OpenVPN es probablemente la respuesta, pero no puedo entender cómo configurar las cosas ( topology subneto topology p2ppodría ser apropiado. ¿O debería usar el puente Ethernet?). La seguridad y el cifrado no son una gran preocupación en este momento, por lo que GRE también estaría bien: la máquina B vendrá de una dirección IP conocida y se puede autenticar en función de eso.

¿Cómo puedo hacer esto? ¿Alguien puede sugerir una configuración OpenVPN, o algún otro enfoque, que podría funcionar en esta situación? Idealmente, también podría manejar múltiples clientes (por ejemplo, compartir las cuatro IP de repuesto con otras máquinas), sin permitir que esos clientes usen IP a las que no tienen derecho.

— Jim Paris
fuente

¿Qué cortafuegos hay en ambas ubicaciones?

— Robert

Espero que hayas inventado esas direcciones, en lugar de que realmente trabajes en Google. Si no lo hace, no podrá utilizar su espacio de direcciones.

— Michael Hampton

Robert: A es un servidor Linux con algunas iptablesreglas simples . B está detrás de un NAT que es otro servidor Linux en ejecución shorewall.

— Jim Paris

Michael: Sí, cambié los primeros tres octetos a 8 para ofuscarlos, pero sigo indicando que son públicos. Lo siento, Google.

— Jim Paris

Para referencia futura, tenemos un RFC para eso .

— Michael Hampton

Respuestas:

Terminé yendo con el puente de Ethernet. Muchos ejemplos extremadamente detallados para leer en línea, pero resulta bastante fácil:

Primero, en A , /etc/network/interfacesse cambió de:

auto eth0
iface eth0 inet static
    address 8.8.8.122
    netmask 255.255.255.248
    gateway 8.8.8.121

auto br0
iface br0 inet static
    address 8.8.8.122
    netmask 255.255.255.248
    gateway 8.8.8.121
    pre-up openvpn --mktun --dev tap0
    bridge_ports eth0 tap0
    bridge_fd 3

para eth0conectar (la interfaz WAN real) con tap0(una nueva interfaz de túnel) en el arranque.

Luego, en A , ejecute el servidor openvpn con:

openvpn --dev tap0

En B , conéctese a él con:

openvpn --remote 8.8.8.122 --dev tap0 --route-gateway 8.8.8.121 \
        --redirect-gateway def1 --ifconfig 8.8.8.123 255.255.255.248

Esa es la configuración súper simple que estaba buscando, y funciona: ahora B es accesible públicamente en 8.8.8.123, y las conexiones salientes se originan en la misma dirección.

Añadir seguridad ( --secret, --tls-server, etc.), según sea necesario, por supuesto.

— Jim Paris
fuente

¡Agradable! Voy a intentar eso ¿Encontró una manera de configurar eso: "sin dejar que esos clientes usen direcciones IP a las que no tienen derecho"?

— Bastian

No me molesté en mi configuración (que era temporal), pero imagino que podrías hacerlo con ebtables.

— Jim Paris

Muy útil. Una pregunta: ¿qué necesito cambiar en la configuración de A si necesito enrutar dos IP de A: A => B y A => C (donde C es otro host)? ¿Necesito configurar otro puente?

— frhack

Si. Añadir otra pre-up openvpnlínea para crear tap1también, añadir tap1a bridge_ports, y ejecutar otra instancia de openvpn con openvpn --dev tap1.

— Jim Paris

¿Qué tal si quisiera hacer que la puerta de enlace de A sea local a través de B para que cualquier sistema en la LAN pueda usar B y asignar la puerta de enlace predeterminada remota y usar IP públicas?

— Areeb Soo Yasir

Vas a pasar un mal momento, creo. La mayoría de los firewalls tendrán dificultades para enrutar el tráfico de OpenVPN si ambos lados de la VPN están en la misma subred.

Si está intentando enrutar para acceso público, movería ambos servidores a diferentes subredes desde sus direcciones públicas y luego usaría IP virtuales (1 a 1 Nat) para conectarlos. Para conectar los dos sitios, OpenVPN funcionaría o un túnel IP-Sec.

IP virtuales: http://doc.pfsense.org/index.php/What_are_Virtual_IP_Addresses%3F

Sitio a sitio: http://doc.pfsense.org/index.php/VPN_Capability_IPsec

Editar basado en comentarios:

Personalmente instalaría pfSense en el cuadro A y le daría el puerto que deseaba para su WAN. Luego configure un servidor OpenVPN en una subred local (que está lista para usar en la interfaz web de pfSense) y configure la otra máquina con una IP virtual que apunte a su IP local de OpenVPN. Esto le daría espacio para la expansión posterior (agregue más máquinas con IP virtuales, reenvíe puertos específicos a diferentes servidores, realmente tenga una configuración LAN / WAN / DMZ completa con OpenVPN para acceso virtual. Sin mencionar que tendría un enrutador completo, por lo que probablemente sea más seguro.

— Robert
fuente

No entiendo cómo están involucrados los firewalls intermedios; ciertamente no se busca en el interior de los paquetes de OpenVPN entre A y B . Para la configuración de OpenVPN en sí, esperaba que algo así push "route 50.7.19.122 255.255.255.255 net_gateway"aseguraría que los datos de VPN todavía se envíen a la red normal.

— Jim Paris

Para ser claros, quiero crear un túnel directamente entre A y B , no en firewalls separados en cada extremo.

— Jim Paris

Pero cuando la computadora A quiere enrutar a la computadora B, no sabrá si debe usar la WAN (con sus IP públicas), la LAN (con su IP estática) o OpenVPN (también con sus IP públicas) porque son todas misma subred B a A debería funcionar sin embargo.

— Robert

También hay esto, lo he tenido funcionando pero no con IP públicas. Creo que las ip virtuales serán mucho mejores de cualquier manera. openvpn.net/index.php/open-source/documentation/mis Miscellaneous

— Robert

"Para ser claros, quiero crear un túnel directamente entre A y B, no en firewalls separados en cada extremo". Tendrá que abrir un puerto en algún lugar para un servidor OpenVPN

— Robert