Dos LAN en NetBird: qué pares enrutan y quién puede hablar

Una estación de trabajo de la LAN oeste abre un navegador, escribe la dirección de una aplicación de la LAN este y espera hasta que expira el tiempo. Todas las pantallas de NetBird dicen que los pares están conectados, lo cual es cierto y no viene al caso: estar en una red superpuesta no es lo mismo que tener las dos subredes locales en una sola red. El recorrido siguiente empieza en esa estación de trabajo y termina con una petición que el diseño rechaza a propósito, y cada parada es algo que se lee en un dispositivo en vez de deducirse. Espere que la pieza que falta sea una ruta o una política, no la superposición.

Lea el fallo primero desde la estación de trabajo

Antes de abrir la consola de administración, establezca qué envía realmente la estación de trabajo. Su propia tabla de enrutamiento decide si el paquete va a la puerta de enlace del sitio, a una interfaz local o a ninguna parte, y esa decisión es visible sin ninguna herramienta de superposición. Una máquina sin ruta para el prefijo remoto fallará por muy sana que parezca la lista de pares. El rango de la superposición y el prefijo propio del sitio son espacios de direcciones distintos, y el alta configuró solo uno de ellos.

Después separe la resolución de nombres de la conectividad, porque el navegador informa de ambas como el mismo tiempo agotado. Repita la petición por dirección desde una máquina que ejecute el cliente NetBird y luego desde una estación de trabajo normal que no lo haga. Si la máquina dada de alta tiene éxito y la normal falla, el hueco está en el enrutamiento local; si fallan ambas, siga leyendo antes de cambiar una ruta.

Elija un par de enrutamiento por sede

Un par de enrutamiento es un host que representa su LAN en la superposición, así que elija una máquina Linux con conectividad estable a la subred en lugar de la estación de trabajo de alguien. Delo de alta por el proceso normal y póngalo en un grupo con el nombre del rol, porque el recurso de red y la política se referirán ambos a ese grupo. Un representante por sede sigue siendo legible; una legión de voluntarios anunciando el mismo prefijo convierte cada pregunta posterior en una sesión de depuración. La dirección del par en el segmento local importa tanto como su identidad en la superposición, porque esa dirección se convierte en el siguiente salto que se indica a cada dispositivo normal.

Escriba el plan antes de tocar la consola, porque los nombres y los prefijos son donde estos diseños se desvían: prefijo, puerta de enlace, dirección del par y grupo, por sede. El oeste es 10.52.0.0/24 servido por 10.52.0.5 y el este es 10.63.0.0/24 servido por 10.63.0.5; los dos grupos son west-routers y east-routers, y ningún prefijo puede solaparse con el otro, con el rango de la superposición ni con otro destino enrutado.

Cree el recurso, mantenga el enmascaramiento

En el panel desplegado, cree un recurso de red por sede y adjunte a él el grupo de pares de enrutamiento de esa sede. El recurso es el prefijo y el grupo es el host que responde por él, y ambos deben existir antes de que se anuncie nada. Confirme que la versión autoalojada desplegada tiene el flujo de trabajo Redes, porque una interfaz más antigua con un objeto de ruta de nombre parecido es otra función.

Deje el enmascaramiento activado. La guía de NetBird para sitio a sitio lo exige en esta disposición, y desactivarlo para mantener visible cada dirección original no es el mismo diseño con un salto menos; cambia lo que observan las comprobaciones de origen y las políticas de la superposición. La consecuencia merece decirse sin rodeos: el servicio receptor registra el par de enrutamiento como origen, no la estación de trabajo individual. Si la lista de permitidos o la auditoría de ese servicio espera direcciones de estaciones de trabajo, o cambia la expectativa o la identidad debe imponerse en el límite del sitio antes de la traducción.

Autorice a los iniciadores, no a los prefijos

Una ruta hace alcanzable una dirección y una política decide quién puede usarla; son dos objetos separados con propietarios separados. Escriba la política desde la carga de trabajo hacia atrás: qué grupo inicia, qué recurso apunta y qué servicio TCP necesita. Una red que anuncia ambos prefijos a cada par dado de alta ha creado alcance y no ha resuelto nada.

Luego lea qué más está ya permitido, porque una regla nueva estrecha no revoca una amplia antigua que está por encima. Cuando el este también deba iniciar conexiones hacia el oeste, escriba esa dirección como su propia política; el tráfico de retorno de una sesión abierta por el oeste es una pregunta distinta de permitir sesiones nuevas hacia el este. Si solo algunas estaciones de trabajo del oeste deben llegar a la aplicación del este, selecciónelas en el límite del sitio antes de la traducción y mantenga la autenticación propia de la aplicación. El par de enrutamiento transporta el tráfico de la LAN como el sitio entero y no como una identidad de superposición por usuario, así que la contabilidad por usuario tiene que venir de otro sitio.

Enseñe a cada puerta de enlace el siguiente salto y luego pruebe una denegación

Los dispositivos normales nunca ven la superposición, así que su propia puerta de enlace necesita una ruta estática que apunte el prefijo remoto a la dirección LAN del par de enrutamiento. Ese es el paso que la gente omite, porque todo lo visible dentro de NetBird ya funciona mientras las estaciones de trabajo normales aún expiran. La puerta de enlace conserva su ruta por defecto como estaba; este prefijo es una adición, no una sustitución.

Las dos descripciones de ruta van en la configuración de la puerta de enlace de cada sede, no en una excepción en el host. Ambas son rutas estáticas normales y ninguna toca la ruta por defecto:

west gateway: 10.63.0.0/24 via 10.52.0.5
east gateway: 10.52.0.0/24 via 10.63.0.5

Pruebe con la aplicación que el proyecto necesita de verdad, desde una estación de trabajo normal, y anote tres cosas: el siguiente salto elegido en el lado emisor, la política que coincidió y la dirección de origen que registró el servicio. Pruebe también una denegación, porque un diseño que nunca ha denegado nada tiene bordes desconocidos, y la denegación es la única prueba de que hace el trabajo la política y no el enrutamiento. Cuando el este también deba iniciar, empiece una conexión nueva desde ese lado en lugar de suponer que la segunda dirección sigue. Planifique también el reinicio, la actualización y la sustitución del par de enrutamiento, porque un host se ha convertido en dependencia del sitio.

Los nombres privados necesitan su propio diseño de resolución, porque el alcance no crea registros DNS y un camino IP que funciona con un nombre roto se lee exactamente como un camino roto. Si un par de enrutamiento se ejecuta dentro de una red de nube, revise también las reglas de reenvío y de cortafuegos del proveedor, porque el alta no las anula. Guarde las observaciones de la prueba junto al plan, porque la próxima persona que depure esto querrá la política coincidente y la dirección de origen registrada, no una descripción de la topología.