1 votos

Reenviar tráfico en la misma interfaz

Yo soy el funcionamiento de un servidor que aloja un conjunto de servicios, cada uno de ejecutar en otra ventana acoplable contenedor. Además, hay un KVM ejecución de pfSense que actúa como cortafuegos. El firewall tiene una interfaz física que está conectado a la red externa y una tarjeta de red virtual que se conecta a la interna del contenedor de la red, utilizando MACVLAN ventana acoplable lado, por lo que cada contenedor tiene su propia dirección IP, pero todos ellos están en la misma subred.

Por razones de seguridad, los contenedores deben ser aislados y no serán capaces de comunicarse unos con otros, principalmente (sólo con la red externa). Para esto, MACVLAN está configurado en VEPA modo, que permite el tráfico desde y hacia el dispositivo principal, pero no a otras direcciones en el mismo dispositivo principal.

Ahora, me gustaría permitir específicos de tráfico entre los contenedores específicos, por lo que pfSense debe enrutar el tráfico a la misma interfaz que recibió el tráfico, teniendo en cuenta las reglas de firewall configurado (leer, si el tráfico entrante en la interfaz interna coincide con una regla PASS será remitido a un host en la misma interfaz de la misma subred).

Me parece que no puede conseguir que el escenario de trabajo (no de tráfico entre los hosts en la interfaz interna, el tráfico desde y hacia la red externa funciona como se espera). Cualquier idea sobre cómo proceder a partir de aquí?

¿Hay algún elemento de configuración en FreeBSD en general o pfSense específicamente la que impide que tales escenarios, como "filtro de tráfico en la propia interfaz de" o "en la práctica esto no debería ocurre porque el tráfico es enviado en el interruptor en la parte delantera del router ya que es la misma subred para no hacer nada con él"?

Curiosamente, pfSense no tiene aún respuesta a la solicitud de ARP (que puede tener la misma razón):

[root@server ~]# ip r
default via 10.0.20.1 dev server proto static metric 410 
10.0.20.0/24 dev server proto kernel scope link src 10.0.20.2 metric 410

21:52:49.651286 ARP, Request who-has 10.0.20.4 tell 10.0.20.2, length 28
21:52:50.673895 ARP, Request who-has 10.0.20.4 tell 10.0.20.2, length 28
21:52:51.697860 ARP, Request who-has 10.0.20.4 tell 10.0.20.2, length 28
21:52:52.721992 ARP, Request who-has 10.0.20.4 tell 10.0.20.2, length 28

Quiero suponer una respuesta con la MAC de la 10.0.20.0/24 interfaz. El seguimiento se hizo en el servidor de seguridad de la interfaz (PING desde el servidor de seguridad para 10.0.20.4 funciona como se espera).

Al agregar la entrada manualmente puedo ver la solicitud de eco ICMP, pero no hay respuesta:

[root@server ~]# arp -s 10.0.20.4 02:42:0a:00:14:04
10.0.20.4                ether   02:42:0a:00:14:04   CM                    server

22:00:21.403515 IP 10.0.20.2 > 10.0.20.4: ICMP echo request, id 5622, seq 1, length 64
22:00:22.450162 IP 10.0.20.2 > 10.0.20.4: ICMP echo request, id 5622, seq 2, length 64
22:00:23.473790 IP 10.0.20.2 > 10.0.20.4: ICMP echo request, id 5622, seq 3, length 64
22:00:24.497803 IP 10.0.20.2 > 10.0.20.4: ICMP echo request, id 5622, seq 4, length 64

0voto

Roshan Puntos 908

Depende en parte de cómo piensa un contenedor para hacer referencia a otra. Valdría la pena considerar si esta topología de red es adecuado para el caso de uso y la política de seguridad.

Si usted desea para Un contenedor para abordar el recipiente B directamente por el nombre de host o dirección IP, esto tiene que seguir switching de Capa 2 y Capa 3 de enrutamiento:

  • Si están en la misma subred, a continuación, sólo será capaz de dirigirse unos a otros directamente a través del interruptor (que serán bloqueadas por VEPA como usted sugiere). El pfSense host sólo se puede ver el tráfico si:
    • el tráfico IP de destino está fuera del contenedor de subred, en cuyo caso el contenedor deberá enviar el tráfico a la puerta de enlace predeterminada para ser transferido; o
    • el tráfico se dirige directamente a los pfSense nombre de host/dirección IP.
  • Si usted coloca cada uno de los contenedores en una subred diferente (o incluso por separado redes virtuales), a continuación, el tráfico entre ellos se realizan a través de la puerta de enlace (pfSense). Esto pondría el pfSense en el control de la directiva de firewall.
  • Si usted puede determinar una política de que los grupos de contenedores se permite el acceso a cada uno de los otros directamente, tendría más sentido para el grupo de estos en virtual/ventana acoplable redes; entonces el problema desaparece. En este caso, usted es la alineación de la topología de la red con la política de seguridad. Esto es generalmente más fácil de obtener, mantener, y para otros a la razón.

Usted podría mirar en la ventana acoplable Macvlan del 802.1 q tronco a modo de puente que podría hacer más fácil para conectar múltiples contenedor de redes para el mismo libvirt/pfSense de la interfaz.

Alternativamente, puede suceder que sólo hay una muy estrecha y coherente conjunto de formas en que los contenedores de acceso de cada uno de los otros. En este caso, usted podría considerar la posibilidad de reenvío de puerto. Usted sería:

  • identificar un contenedor específico de servicio que usted desea que sean accesibles a otros contenedores
  • en pfSense, reenviar el tráfico entrante a un puerto en particular de la MACVLAN interfaz para la IP/puerto de la deseada contenedor
  • cuando otros recipientes que se necesitan para acceder al servicio, se utiliza la dirección IP (y nominado puerto) de la pfSense host (no el contenedor de destino)

En este caso, los contenedores no saben nada acerca de que el servicio de destino es - es posible que así se aloja directamente en el pfSense host. Nota sin embargo que esto no escala bien, y funciona solamente para simples de TCP/UDP de tráfico (FTP podría ser doloroso para configurar).

Hay también podría ser alguna otra ventana acoplable o libvirt características de red que permite definir de forma más detallada política de cortafuegos entre los contenedores en una red virtual, aunque no he mirado profundamente en mí mismo.

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: