= ¿Pueden interconectarse en LAN a VPS/servidor en la nube tunelizar todas las entradas de otros dos sistemas LAN? =
¿Puedo hacer esto?
Caja WG dedicada en túneles LAN al servidor VPS/cloud WG. Esta caja WG local tiene múltiples interfaces ethernet. ¿Puede tomar entradas sin tunelizar de otras dos cajas LAN y reenviarlas a través del túnel WG al servidor VPS/en la nube? Además, ¿puede una de estas otras cajas LAN SSH a la caja WG con otra conexión ethernet?
Resumen de las interfaces cableadas de la caja LAN WG:
1: al lado LAN del enrutador, para acceso WAN y para SSH con una Mac;
2. la Mac a través del enrutador, para el tráfico a ser tunelizado;
3. la otra caja LAN, para el tráfico a ser tunelizado.
La Mac enviaría su tráfico por canalizar a la interfaz 2 y el tráfico SSH a la interfaz 1; ambas interfaces se conectan al enrutador. La interfaz 3 se conecta directamente a la otra caja LAN. Todas las direcciones LAN están en la misma subred y son direcciones estáticas.
Problemas que veo hasta ahora: creo que el cuadro WG tiene que NAT el tráfico de su túnel (además del servidor VPS nuevamente); si es asi, algun problema ahi? ¿Y cómo se puede aislar el tráfico SSH del túnel?
Todas las direcciones LAN están en la misma subred y son direcciones estáticas.
Tener múltiples LAN con la misma subred es una mala idea. Cada LAN debe usar su propia subred. Y la caja WG no debería tener varias interfaces conectadas a la misma subred.
No debería necesitar usar NAT en el cuadro WG, en su lugar, debe configurar las subredes LAN en ips permitidas en el servidor WG en la nube.
Editar: reemplazado por mi próxima respuesta
Bien, esto es lo que pienso ahora que ha encendido la bombilla de varias subredes En este momento solo hay una subred, 192.16816. Hay muchas cajas/hosts/dispositivos en él (teléfonos, termostatos, computadoras, componentes de cine en casa, etc.), además de los tres mencionados en mi OP (a los que ahora me referiré como 1_LAN_WG_box, 2_ Mac y 3_otra_caja_LAN).
Digamos que 2_Mac se convertirá en 172.16.0.6 y 3_other_LAN_box será 172.17.0.7. El conector ETH1 de la caja LAN WG permanece en 192.16816. Su conector ETH2 se convierte en 172.16.0.2 (subred de 2_Mac) y su conector ETH3 se convierte en 172.17.0.1 (puerta de enlace en la subred de 3_other_LAN_box). Eso elimina el problema de NAT local.
No quiero la Mac en la VPN todo el tiempo, sino solo ocasionalmente como cliente web. Estaba planeando activar la función de navegador del servidor proxy, con el cuadro LAN WG como proxy, solo cuando quiero usar la VPN. Creo que aún no he mencionado que la caja LAN WG no tiene cabeza; Quiero usar la Mac para controlarlo y configurarlo a través de SSH. Lo mismo se aplica a 3_other_LAN_box.
La Mac, 172.16.0.6, SSH a la casilla LAN WG en la dirección 192.16816 de este último. Le daré al enrutador principal una ruta estática para eso. El navegador Mac, cuando quiero que use la VPN, usará la dirección ETH2 172.16.0.2 de la caja LAN WG como proxy del navegador.
3_otra_LAN_solo tiene un conector RJ45. Utilizará la caja LAN WG como puerta de enlace. Si 3_other_LAN_box se conecta a un conmutador, la Mac podría conectarse mediante SSH a 3_other_LAN_box a través de una ruta estática del enrutador principal.
¡Creo que este es mi primer diseño de red! Un problema pendiente es aislar el tráfico SSH de la caja LAN WG del túnel. Tengo algunas ideas al respecto, pero si la respuesta a mi pregunta general, "¿Esto puede funcionar?"es que si, ese tema lo dejo para otro post. También para otra publicación, el contenido de los archivos WG conf se adaptará a este diseño de LAN, ¡a menos que todo funcione en mi primer intento!
(He tratado de aclarar este comentario, pero entiendo que contiene muchos detalles. ¡Agradezco su ayuda!)
Hay algunos aspectos de mi respuesta anterior de 13 h. Hace que creo que probablemente no funcione, así que estoy empezando de nuevo. Puedes ignorar esa respuesta si quieres.
Panorama general: tengo una caja de Ubuntu sin interfaz ("WGbox") que quiero usar para conectar dos dispositivos locales, una Mac y un servidor de datos sin interfaz ("DS") al extremo local de un túnel WG a un servidor WG en un VPS en la nube. DS se canalizará las 24 horas del día, los 7 días de la semana, pero Mac solo ocasionalmente. Tanto WGbox como DS, al no tener periféricos, necesitan acceso SSH desde la Mac.
WGbox tiene cuatro conectores RJ45. En este momento tengo una subred LAN, 192.168.1.0/24. Debido a las necesidades de enrutamiento virtual de WG, necesitaré al menos una subred adicional para tunelizar dos dispositivos (Mac y DS).
Teniendo en cuenta la Mac primero, quiero canalizar de vez en cuando el tráfico web del navegador a través de WGbox, y ser capaz de SSH a WGbox cuando no estoy canalizando el tráfico web. Actualmente, la única interfaz cableada de WGBox en uso tiene asignada 198.168.1.10 y yo SSH desde la Mac, que es 198.168.1.200.
¿Qué tal si agrego una subred para Mac, con una puerta de enlace como 172.16.0.1/24 y la asigno a una segunda interfaz cableada en WGbox? Cuando quiero tunelizar la Mac, cambio la IP/puerta de enlace de la Mac a 172.16.0.1/172.16.0.1. Dado que el enrutador principal está en la subred 192.168, normalmente tendría que poner un puente en sus iptables para enrutar a 172.16.0.1. Pero como la Mac y la WGbox están conectadas al mismo interruptor, creo que puedo evitar el puente.
¿Crees que esto funciona? Si es así, pasaré a la tunelización y el acceso SSH para el dispositivo DS. Si no es así, hágame saber cualquier idea sobre cómo solucionarlo.
"la caja WG no debería tener varias interfaces conectadas a la misma subred". ¿Por qué? No estoy discutiendo, solo quejándome, ya que creo que violar esa regla simplificaría mi tarea y me gustaría saber la razón detrás de esto.
Puede que esté malinterpretando esto (día largo), pero lo que te impide:
- usar WGbox como puerta de enlace LAN para todos los dispositivos que desea enrutar permanentemente a través del túnel (debería configurar esto en los dispositivos respectivos y renunciar o complicar su configuración de DHCP desde la puerta de enlace LAN predeterminada)?
- configurar un proxy en el WGbox que puede activar y desactivar a su gusto, en los dispositivos que
*no quieres* enrutado permanentemente?
No es necesario (en mi humilde opinión y en una lectura rápida) perder el tiempo con diferentes subredes, múltiples conexiones de red, etc. A menos que me esté perdiendo algo. Sin relación con esto, le sugiero encarecidamente que separe los dispositivos "IoT"(al menos) en una red diferente.
Un problema con tener todos los dispositivos en la misma subred es el requisito de que WGbox NAT el tráfico del túnel. Supongo que eso no es necesariamente fatal, pero parece un desperdicio a la luz de la nube VPS al final del túnel que también tiene que NAT. También complica la configuración de WGbox. Pero evita la complicación de configurar las subredes adicionales y vincularlas en mi enrutador principal.
En cuanto a activar/desactivar los túneles a voluntad para la navegación web desde mi Mac, había pensado en configurar una de las interfaces de WGbox como proxy en mi navegador web (¿es eso lo que quiere decir?) En resumen, la autoeducación mediante la búsqueda en Internet. descubra que para HTTPS, el navegador emite una CONEXIÓN al servidor proxy para establecer un túnel al servidor web de destino. No estoy seguro de qué hará WGbox con CONNECT. De manera más general, creo que se requiere alguna configuración de firewall para evitar que WGbox descarte o rechace el tráfico web de la Mac antes que WireGuard. O tal vez AllowedIPs 0.0.0.0/0 para las secciones Peer configuraría automáticamente el control de acceso permisivo.
Resulta que solo hay un dispositivo (hasta ahora), el servidor de datos sin cabeza, que me gustaría canalizar para su función principal. Digo "función central"porque, al no tener cabeza, necesito acceso SSH desde una Mac. Eso, no DHCP (que puedo manejar fácilmente), es lo que complica configurar WGbox para que sea su puerta de enlace. Además, durante las sesiones SSH, necesita preferiblemente acceso WAN sin túnel para actualizaciones del sistema operativo, etc.
== ÃÂÃÂber diese Comunidad ==
Mitglieder
En línea
Reddit
