Filtros del faro de Nebula frente al firewall: qué bloquea cada uno

Mire un handshake de Nebula desde el lado equivocado y los dos mecanismos parecen intercambiables. Uno decide qué direcciones anuncia un nodo al faro y qué direcciones remotas intentará; el otro decide qué puede pasar una vez que existe el túnel. Un filtro puede detener una conexión antes de que se evalúe cualquier regla de firewall, y una regla de firewall no puede revivir un extremo que el descubrimiento eliminó. Las dos capas responden preguntas distintas, y el orden en que actúan es la clave.

Siga una conexión por cuatro etapas: la dirección local anunciada, el extremo remoto considerado, el handshake y el tráfico de la capa superpuesta. Cada etapa tiene su propia configuración y su propia firma de fallo.

Empiece por la dirección local que anuncia el nodo

local_allow_list filtra las direcciones locales de este host antes de que se informen a los faros. Las entradas pueden ser rangos de direcciones, y la configuración también admite patrones de nombre de interfaz. Eso es útil cuando un host tiene puentes de contenedores o interfaces de túnel adicionales que no deberían convertirse en extremos de pares.

Recorra las interfaces del host y pregunte a cuáles puede llegar realmente un par remoto. Una dirección de puente Docker es local para ese host e inútil para un par en otra red. Anunciarla desperdicia el descubrimiento y puede enviar a un par hacia una dirección que nunca responde. Todo aquello a lo que un par no puede enrutar es ruido en la respuesta del faro.

Una lista de permitidos estrecha es más segura aquí que una lista de denegados amplia. Si solo hay entradas de permiso, el resto no especificado queda excluido; añadir una entrada de denegación después cambia la lógica predeterminada y necesita su propia revisión. Ese cambio merece una segunda mirada al valor predeterminado.

Después observe la selección del extremo remoto

remote_allow_list filtra las direcciones que este host considerará para un par remoto durante un handshake. Se aplica a la dirección de la red subyacente, no a la dirección de la capa superpuesta que el par usará una vez levantado el túnel.

Un rango privado puede ser perfectamente utilizable en una red de oficina compartida e intrascendente cuando los dos hosts están en redes no relacionadas que ambos usan 10.0.0.0/8. El filtro le permite preferir la ruta enrutable e ignorar la coincidencia.

Cuando un par no logra conectarse, compare la dirección que se está probando con la regla que le corresponde. Active los registros del handshake y lea la dirección remota seleccionada; la línea del registro nombra el extremo que sobrevivió al filtrado, lo que es más útil que la lista de direcciones que posee el par.

Un filtro de nombre de interfaz en el lado que anuncia puede eliminar el extremo antes de que el lado receptor lo vea siquiera. Revise ambos nodos cuando solo falla una dirección.

Tras el handshake se aplican las reglas de acceso de la capa superpuesta

Las reglas de firewall de Nebula operan dentro de la capa superpuesta, después de que el túnel se establece. Coinciden con hosts, grupos, puertos y protocolos, y deciden si un paquete puede entrar o salir del host local. No seleccionan un extremo de la red subyacente.

Esta separación explica un diagnóstico erróneo habitual. Un operador añade una regla de firewall para un puerto y sigue sin poder conectarse, porque el filtro del faro eliminó el único extremo alcanzable. Otro operador abre el filtro de direcciones y sigue sin llegar al servicio, porque el firewall de la capa superpuesta rechaza el puerto.

Lea el fallo en la capa correcta. Un handshake que nunca se completa apunta al descubrimiento, al filtrado de extremos o a la ruta de red. Un handshake completado seguido de una conexión de servicio rechazada o descartada apunta al firewall de la capa superpuesta o a la aplicación.

Lea el valor predeterminado al mezclar permiso y denegación

La configuración del faro admite listas solo de permitidos, solo de denegados y mixtas, y el valor predeterminado para el resto no especificado difiere entre esas formas. Una lista mixta necesita un valor predeterminado explícito para la familia de direcciones; suponer que el resto se comporta como la configuración anterior es como un extremo que funcionaba desaparece en silencio.

lighthouse:
  local_allow_list:
    interfaces:
      docker0: false
  remote_allow_list:
    192.168.0.0/16: true
    default: false

Trate el valor predeterminado como parte de la regla, no como texto de plantilla. Si el valor predeterminado de la familia es denegar, toda dirección no listada queda excluida, incluido un nuevo rango de oficina añadido después de escribir la configuración.

Anote qué direcciones debían ser accesibles y pruebe desde ambos lados. Un filtro que funciona para una pareja de pares puede fallar para otra pareja cuya única ruta común usa una dirección que la lista excluye.

Use relay cuando no haya ningún extremo directo accesible

Si cada extremo candidato queda filtrado o inaccesible, la respuesta no es una lista de permitidos más amplia que vuelva a admitir direcciones en las que no confía. La configuración de relay de Nebula ofrece una ruta alternativa para el par cuando la conectividad directa no es viable.

El relay resuelve el transporte y el descubrimiento, no la autorización, y no amplía el firewall. El firewall de la capa superpuesta sigue decidiendo qué servicios pueden usarse, y el relay no convierte el filtrado del faro en un mecanismo de control de acceso.

Pruebe la ruta del relay con los extremos directos desactivados y confirme que el servicio previsto sigue funcionando mientras que uno no previsto no lo hace. Esa única prueba separa una corrección de transporte de un cambio de política y mantiene honestas las dos capas.