📍 🦏 🙅🏿 Cónsul + iptables =: 3 ◀️ 👩🏽‍🎓 👴

En 2010, Wargaming tenía 50 servidores y un modelo de red simple: backend, frontend y firewall. El número de servidores creció, el modelo se volvió más complicado: etapas, VLAN aisladas con ACL, luego VPN con VRF, VLAN con ACL a L2, VRF de ACL a L3. La cabeza está girando? Más será más divertido.

Cuando los servidores comenzaron a trabajar 16,000 sin roturas con tantos segmentos heterogéneos, se hizo imposible. Por lo tanto, se les ocurrió una solución diferente. Tomamos la pila de Netfilter, le agregamos Consul como fuente de datos y obtuvimos un firewall distribuido rápidamente. Reemplazaron la ACL en los enrutadores y se usaron como firewall externo e interno. Para la gestión dinámica de herramientas, desarrollamos el sistema BEFW, que se usó en todas partes: desde controlar el acceso de los usuarios a la red de supermercados hasta aislar los segmentos de la red entre sí.

Cómo funciona todo y por qué debería echar un vistazo más de cerca a este sistema, le dice a Ivan Agarkov (annmuor) - el jefe del grupo de seguridad de infraestructura de la unidad de Mantenimiento en el centro de desarrollo de la empresa de Minsk. Ivan es fanático de SELinux, ama a Perl, escribe código. Como jefe del grupo IB, trabaja regularmente con registros, copias de seguridad e I + D para proteger Wargaming de los piratas informáticos y garantizar el funcionamiento de todos los servidores de juegos de la empresa.

Referencia de la historia

Antes de decir cómo lo hicimos, te diré cómo llegamos a esto y por qué era necesario. Para hacer esto, transferimos hace 9 años: 2010, solo apareció World of Tanks. Wargaming tenía aproximadamente 50 servidores.

Gráfico de crecimiento de los servidores de la empresa.

Teníamos un modelo de red. Para ese momento fue óptimo.

El modelo de red en 2010.

En la parte delantera hay tipos malos que quieren rompernos, pero hay un firewall en él. No hay firewall en el back-end, pero hay 50 servidores allí, todos los conocemos. Todo funciona bien

A lo largo de 4 años, la flota de servidores ha crecido 100 veces, hasta 5000. Aparecieron las primeras redes aisladas, por etapas: no pueden entrar en producción y, a menudo, las cosas que podrían ser peligrosas giraban allí.

Modelo de red en 2014.

Por inercia, se utilizaron las mismas piezas de hierro y todo el trabajo se realizó en VLAN aisladas: las ACL se escriben en la VLAN que permiten o prohíben cualquier conexión.

En 2016, el número de servidores llegó a 8000. Wargaming absorbió otros estudios, aparecieron redes de afiliados adicionales. Parecen ser nuestros, pero no del todo: la VLAN a menudo no funciona para los socios, debe usar una VPN con VRF, el aislamiento se vuelve más complicado. Creció una mezcla de aislados de ACL.

El modelo de red en 2016.

A principios de 2018, la flota de automóviles creció a 16,000. Hubo 6 segmentos, y el resto no contamos, incluidos los cerrados, en los que se almacenaron los datos financieros. Hay redes de contenedores (Kubernetes), DevOps, redes en la nube conectadas a través de VPN, por ejemplo, desde el IVS. Había muchas reglas, dolía.

Modelo de red y métodos de aislamiento en 2018.

Para el aislamiento utilizamos: VLAN con ACL en L2, VRF con ACL en L3, VPN y mucho más. Demasiado.

Problemas

Todos viven con ACL y VLAN. ¿Qué está mal en general? Harold, ocultando el dolor, responderá esta pregunta.

Hubo muchos problemas, pero hubo cinco masivos.

Aumentos de precios geométricos para las nuevas reglas . Cada nueva regla se agregó más tiempo que la anterior, porque primero tenía que ver si ya existía dicha regla.
No hay firewall dentro de los segmentos . Los segmentos se separaron de alguna manera entre sí, en el interior ya no hay suficientes recursos.
Las reglas se han aplicado durante mucho tiempo. Las manos que los operadores de reglas locales podrían escribir en una hora. Global tardó varios días.
Dificultades con la auditoría de las reglas . Más precisamente, no fue posible. Las primeras reglas se escribieron en 2010, y la mayoría de sus autores ya no trabajaban para la empresa.
Bajo nivel de control sobre la infraestructura . Este es el problema principal: no sabíamos bien qué estaba pasando con nosotros.

Así se veía el ingeniero de redes en 2018 cuando escuchó: "Necesitamos más ACL".

Soluciones

A principios de 2018, se decidió hacer algo al respecto.

El precio de la integración está en constante crecimiento. El punto de partida fue que los grandes centros de datos ya no admitían VLAN y ACL aisladas, porque la memoria en los dispositivos se agotó.

Solución: eliminó el factor humano y automatizó la provisión de acceso al máximo.

Nuevas reglas aplican por mucho tiempo. Solución: acelerar la aplicación de las reglas, hacerla distribuida y paralela. Para hacer esto, necesita un sistema distribuido para que las reglas se entreguen por sí mismas, sin rsync o SFTP por mil sistemas.

La falta de un firewall dentro de los segmentos.El firewall dentro de los segmentos comenzó a volar hacia nosotros cuando aparecieron diferentes servicios dentro de la misma red. Solución: use un firewall basado en host. Casi en todas partes tenemos Linux, e iptables están en todas partes, esto no es un problema.

Dificultades con la auditoría de las reglas. Solución: mantenga todas las reglas en un solo lugar para su revisión y administración, de modo que podamos auditar todo.

Bajo nivel de control sobre la infraestructura. Solución: haga un inventario de todos los servicios y accesos entre ellos.

Este es más un proceso administrativo que técnico. A veces tenemos 200-300 nuevos lanzamientos por semana, especialmente durante las promociones y los días festivos. Sin embargo, esto es solo para un equipo de nuestros DevOps. Con tantos lanzamientos, es imposible ver qué tipo de puertos, IP, integración se necesitan. Por lo tanto, necesitábamos gerentes de servicio especialmente capacitados que entrevistaran a los equipos: "¿Qué hay allí y por qué lo plantearon?"

Después de todo lo que lanzamos, el ingeniero de redes en 2019 comenzó a verse así.

Cónsul

Decidimos que pondríamos todo lo que encontráramos con la ayuda de los gerentes de servicio en Consul y desde allí escribiríamos las reglas de iptables.

¿Cómo decidimos hacer esto?

Recopilamos todos los servicios, redes y usuarios.
Hagamos reglas de iptables basadas en ellas.
Control automatizado.
...
LUCRO.

Consul no es una API remota; puede funcionar en todos los nodos y escribir en iptables. ¡Solo queda encontrar controles automáticos que limpien el exceso, y la mayoría de los problemas se resolverán! Finalizaremos el resto en el proceso.

¿Por qué cónsul?

Bien establecido En 2014-15, lo usamos como back-end para Vault, en el que almacenamos contraseñas.

No pierde datos . Durante el uso, Consul no perdió datos en ningún accidente. Esta es una gran ventaja para el sistema de gestión de firewall.

Las comunicaciones P2P aceleran la propagación del cambio . Con P2P, todos los cambios se producen rápidamente, sin necesidad de esperar horas.

Conveniente API REST. También consideramos Apache ZooKeeper, pero no tiene una API REST, tendrá que poner muletas.

Funciona como un almacén de claves (KV) y como un directorio (Service Discovery) . Puede almacenar inmediatamente servicios, catálogos, centros de datos. Esto es conveniente no solo para nosotros, sino también para los equipos vecinos, porque al construir un servicio global, pensamos en grande.

Escrito en Go, que es parte de la pila de Wargaming. Nos encanta este lenguaje, tenemos muchos desarrolladores de Go.

Potente sistema ACL. En Consul, puede usar ACL para administrar quién y qué escribir. Garantizamos que las reglas del firewall no se superpondrán con nada más y no tendremos problemas con esto.

Pero el cónsul tiene sus inconvenientes.

No se escala dentro del centro de datos, si no tiene una versión comercial. Es escalado solo por la federación.
Muy dependiente de la calidad de la red y la carga del servidor. El cónsul no funcionará normalmente como un servidor en un servidor ocupado si hay retrasos en la red, por ejemplo, velocidad desigual. Esto se debe a las conexiones P2P y los modelos de distribución de actualizaciones.
Dificultades con el monitoreo de accesibilidad . En el estado de Cónsul se puede decir que todo está bien, pero hace mucho que murió.

Resolvimos la mayoría de estos problemas durante la operación de Cónsul, así que lo elegimos. La compañía tiene planes para un backend alternativo, pero hemos aprendido cómo lidiar con los problemas y todavía estamos viviendo con Consul.

Cómo funciona el cónsul

En el centro de datos condicional, instalamos servidores, de tres a cinco. Uno o dos servidores no funcionarán: no podrán organizar un quórum y decidir quién tiene razón, quién está equivocado, cuando los datos no coinciden. Más de cinco no tiene sentido, el rendimiento disminuirá.

Los clientes se conectan en cualquier orden a los servidores: los mismos agentes, solo con una bandera server = false.

Después de eso, los clientes reciben una lista de conexiones P2P y crean conexiones entre ellos.

A nivel global, estamos interconectando varios centros de datos. También conectan P2P y se comunican.

Cuando deseamos recopilar datos de otro centro de datos, la solicitud va de servidor a servidor. Tal esquema se llama protocolo Serf . El protocolo Serf, como Cónsul, es desarrollado por HashiCorp.

Algunos hechos importantes sobre el cónsul

El cónsul tiene documentación que describe su trabajo. Daré solo hechos seleccionados que vale la pena conocer.

Los servidores de cónsul seleccionan maestros de entre los votantes . Cónsul selecciona el asistente de la lista de servidores para cada centro de datos, y todas las solicitudes van solo a él, independientemente de la cantidad de servidores. Colgar al mago no conduce a la reelección. Si el asistente no está seleccionado, las solicitudes no son atendidas por nadie.

¿Quieres escala horizontal? Lo siento, pero no.

Una solicitud a otro centro de datos va de maestro a maestro, independientemente del servidor al que llegó. El maestro seleccionado recibe el 100% de la carga, excepto la carga en las solicitudes de reenvío. Todos los servidores del centro de datos tienen una copia actualizada de los datos, pero solo uno responde.

La única forma de escalar es habilitar el modo obsoleto en el cliente.

En modo obsoleto, puede responder sin quórum. Este es un modo en el que rechazamos la coherencia de los datos, pero leemos un poco más rápido de lo habitual y cualquier servidor responde. Naturalmente, la grabación es solo a través del maestro.

El cónsul no copia datos entre centros de datos . Al recopilar la federación, cada servidor tendrá solo sus propios datos. Para otros, siempre se vuelve hacia alguien más.

La atomicidad de las operaciones no está garantizada fuera de la transacción . Recuerda que no solo puedes cambiar algo. Si lo desea de manera diferente, realice una transacción con un candado.

Las operaciones de bloqueo no garantizan el bloqueo . La solicitud va de maestro a maestro, y no directamente, por lo que no hay garantía de que el bloqueo funcione cuando se bloquea, por ejemplo, en otro centro de datos.

Las ACL tampoco garantizan el acceso (en muchos casos) . Es posible que la ACL no funcione porque está almacenada en un centro de datos de la federación, en el centro de datos de ACL (DC principal). Si el DC no le responde, el ACL no funcionará.

Un asistente flotante congelará a toda la federación . Por ejemplo, en la federación hay 10 centros de datos, y en uno hay una red defectuosa, y un maestro cae. Todos los que se comunican con él están atrapados en un círculo: se está haciendo una solicitud, no hay respuesta, el hilo se cuelga. No será posible saber cuándo ocurrirá esto, solo en una o dos horas toda la federación caerá. No puedes hacer nada al respecto.

El estado, el quórum y las elecciones se procesan en un hilo separado. La re-selección no sucederá, el estado no mostrará nada. Piensas que tienes un cónsul en vivo, preguntas, y no pasa nada, no hay respuesta. Además, el estado muestra que todo está bien.

Enfrentamos este problema, tuvimos que reconstruir partes específicas de los centros de datos para evitarlo.

La versión comercial de Consul Enterprise no tiene algunas de las desventajas anteriores . Tiene muchas funciones útiles: votación, distribución, escalado. Solo hay un "pero": un sistema de licencias para un sistema distribuido es muy costoso.

Life hack: rm -rf /var/lib/consul- una cura para todas las enfermedades del agente. Si algo no funciona para usted, simplemente elimine sus datos y descargue los datos de la copia. Lo más probable es que el cónsul trabaje.

Befw

Ahora hablemos de lo que agregamos al cónsul.

BEFW - un acrónimo de Bed and ack E nd the F the ire of the W all. Era necesario nombrar de alguna manera el producto cuando creé el repositorio para poner las primeras confirmaciones de prueba en él. Este nombre permanece.

Plantillas de reglas

Las reglas están escritas en la sintaxis de iptables.

-N BEFW
-P GOTA DE ENTRADA
-A ENTRADA -m estado - estado RELACIONADO, ESTABLECIDO -j ACEPTAR
-A ENTRADA -i lo -j ACEPTAR
-A ENTRADA -j ANTES

Todos vamos a la cadena BEFW, excepto ESTABLISHED, RELATEDy localhost. La plantilla puede ser cualquier cosa, esto es solo un ejemplo.

¿Para qué sirve BEFW?

Servicios

Tenemos un servicio, siempre tiene un puerto, el nodo en el que funciona. Desde nuestro nodo, podemos preguntar localmente al agente y descubrir que tenemos algún tipo de servicio. También puedes poner etiquetas.

Cualquier servicio que se esté ejecutando y registrado con Consul se convierte en una regla de iptables. Tenemos SSH - abre el puerto 22. El script bash es simple: curl e iptables, no se necesita nada más.

Clientes

¿Cómo abrir el acceso no a todos, sino de forma selectiva? Por el nombre del servicio, agregue listas de IP al repositorio de KV.

Por ejemplo, queremos que todos los miembros de la décima red puedan acceder al servicio SSH_TCP_22. Añadir un pequeño campo TTL? y ahora tenemos permisos temporales, por ejemplo, por un día.

Accesos

Conectamos servicios y clientes: tenemos un servicio, para cada almacenamiento KV está listo. Ahora damos acceso no a todos, sino de forma selectiva.

Grupos

Si cada vez que escribimos miles de IP para accesos, nos cansaremos. Creemos agrupaciones, un subconjunto separado en KV. Lo llamaremos Alias (o grupos) y almacenaremos grupos allí de acuerdo con el mismo principio.

Conectar: ahora podemos abrir SSH no específicamente en P2P, sino en un grupo completo o en varios grupos. Del mismo modo, hay TTL: puede agregar al grupo y eliminarlo temporalmente.

Integración

Nuestro problema es el factor humano y la automatización. Hasta ahora lo hemos resuelto así.

Trabajamos con Puppet y le transferimos todo lo relacionado con el sistema (código de aplicación). Puppetdb (PostgreSQL normal) almacena una lista de servicios que se ejecutan allí, puede encontrarlos por tipo de recurso. Allí puedes encontrar quién va a dónde. También tenemos un sistema de solicitud de extracción y combinación para esto.

Escribimos befw-sync, la solución más simple que ayuda a transferir datos. Primero, las cookies de sincronización van a puppetdb. La API HTTP está configurada allí: preguntamos qué servicios tenemos, qué hay que hacer. Luego hacen una solicitud al Cónsul.

¿Hay integración? Sí: escribieron las reglas, se les permitió aceptar la solicitud de extracción. ¿Necesita algún puerto o agregar un host a algún grupo? Solicitud de extracción, revisión: no más "Encuentre otras 200 ACL e intente hacer algo al respecto".

Mejoramiento

El ping localhost con una cadena de reglas vacía tarda 0.075 ms.

Agregue 10,000 iptables a esta cadena. Como resultado, el ping aumentará 5 veces: iptables es completamente lineal, el procesamiento de cada dirección lleva algún tiempo.

Para el firewall, en el que migramos miles de ACL, tenemos muchas reglas, y esto introduce un retraso. Para los protocolos de juego, esto es malo.

Pero si ponemos 10,000 direcciones en ping de ipset , incluso disminuirá.

El punto es que la "O" (complejidad del algoritmo) para ipset siempre es 1, sin importar cuántas reglas haya. Es cierto, hay una limitación: no puede haber más de 65535 reglas. Por ahora, vivimos con esto: puede combinarlas, expandirlas, hacer dos ipsets en uno.

Almacenamiento

La continuación lógica del proceso de iteración es el almacenamiento de información del cliente para el servicio en ipset.

Ahora tenemos el mismo SSH, y no escribimos inmediatamente 100 IP, pero configuramos el nombre ipset para comunicarnos y la siguiente regla DROP. Puede rehacer la regla "Quién no está aquí, eso es DROP", pero más claramente.

Ahora tenemos reglas y conjuntos. La tarea principal es hacer un conjunto antes de escribir la regla, porque de lo contrario iptables no escribirá la regla.

Esquema general

En forma de diagrama, todo lo que dije se ve así.

Comprométete con Puppet, todo se envía al host, los servicios están aquí, ipset está allí, y quien no está registrado allí no está permitido.

Permiten negar

Para salvar rápidamente al mundo o apagar rápidamente a alguien, al comienzo de todas las cadenas hicimos dos ipset: rules_allowy rules_deny. ¿Cómo funciona?

Por ejemplo, alguien con bots crea una carga en nuestra web. Anteriormente, era necesario encontrar su IP en los registros, remitirlo a los ingenieros de red para que pudieran encontrar la fuente del tráfico y prohibirlo. Ahora se ve diferente.

Enviamos al Cónsul, esperamos 2.5 s, y ya está. Dado que Consul se distribuye rápidamente a través de P2P, funciona en todas partes, en cualquier parte del mundo.

Una vez que detuve por completo WOT, cometiendo un error con el firewall. rules_allow- Este es nuestro seguro contra tales casos. Si cometimos un error con el firewall en algún lugar, algo está bloqueado en algún lugar, siempre podemos enviar un condicional 0.0/0para aumentar rápidamente todo. Luego arreglaremos todo con nuestras manos.

Otros conjuntos

Puede agregar cualquier otro conjunto en el espacio $IPSETS$ .

¿Para qué? A veces alguien necesita un ipset, por ejemplo, para emular la desconexión de alguna parte del clúster. Todos pueden traer cualquier conjunto, llamarlos y serán tomados del cónsul. Al mismo tiempo, los conjuntos pueden participar en las reglas de iptables y ser como un equipo NOOP: el demonio respaldará la coherencia.

Los usuarios

Solía ser así: un usuario conectado a una red y recibió parámetros a través de un dominio. Hasta la próxima generación de firewalls, Cisco no podía entender dónde está el usuario y dónde está la IP. Por lo tanto, el acceso se otorgó solo a través de máquinas de nombre de host.

¿Qué hemos hecho? Encajado en el momento de recibir la dirección. Por lo general, es dot1x, Wi-Fi o VPN: todo pasa por RADIUS. Para cada usuario, cree un grupo por nombre de usuario y coloque una IP con TTL, que es igual a su dhcp.lease: tan pronto como caduque, la regla desaparecerá.

Ahora podemos abrir el acceso a los servicios, así como a otros grupos, por nombre de usuario. Eliminamos el dolor con el nombre de host cuando cambian, y quitamos la carga de los ingenieros de red porque ya no necesitaban Cisco. Ahora, los propios ingenieros prescriben el acceso a sus servidores.

Aislamiento

Paralelamente, comenzamos a desmontar el aislamiento. Los gerentes de servicio hicieron un inventario y analizamos todas nuestras redes. Los descomponemos en los mismos grupos, y en los servidores necesarios se agregaron los grupos, por ejemplo, para negar. Ahora, el mismo aislamiento de etapas entra en reglas_denegación en la producción, pero no en la producción misma.

El esquema funciona de manera rápida y sencilla: elimine todas las ACL de los servidores, descargue hardware y reduzca la cantidad de VLAN aisladas.

Control de integridad

Anteriormente, un disparador especial funcionaba para nosotros, que informaba cuando alguien cambiaba la regla del firewall con sus manos. Escribí un gran verificador de reglas de firewall, fue difícil. Ahora la integridad controla BEFW. Celosamente se asegura de que las reglas que hace no cambien. Si alguien cambia las reglas del firewall, devolverá todo. "Rápidamente planteé un proxy aquí para trabajar desde casa", ya no hay tales opciones.

BEFW controla el ipset de los servicios y la lista en befw.conf, las reglas de servicio en la cadena BEFW. Pero no sigue otras cadenas y reglas y otros ipset.

Protección contra accidentes

BEFW siempre guarda el último estado exitoso directamente en la estructura binaria de state.bin. Si algo salió mal, siempre vuelve a este estado.bin.

Este es el seguro inestable del Cónsul cuando no envió datos o alguien cometió un error y usó reglas que no pudieron aplicarse. Para que no nos quedemos sin un firewall, BEFW regresará al último estado si se produce un error en algún momento.

En situaciones críticas, esto es una garantía de que permaneceremos con un firewall en funcionamiento. Abrimos todas las redes grises con la esperanza de que el administrador venga y lo arregle. Algún día lo sacaré en configuraciones, pero ahora solo tenemos tres redes grises: 10/8, 172/12 y 192.168 / 16. Como parte de nuestro cónsul, esta es una característica importante que ayuda a desarrollar más.

: - BEFW. . GitHub.

Te contaré sobre los errores que encontramos.

ipset add set 0.0.0.0/0. ¿Qué sucede si agrega a ipset 0.0.0.0/0? ¿Se agregarán todas las IP? ¿Se abrirá el acceso a Internet?

No, tenemos un error que nos costó dos horas de tiempo de inactividad. Además, el error no ha estado funcionando desde 2016, se encuentra en RedHat Bugzilla con el número # 1297092, pero lo encontramos por accidente, según el informe del desarrollador.

Ahora BEFW tiene una regla estricta, que se 0.0.0.0/0convierte en dos direcciones: 0.0.0.0/1y 128.0.0.0/1.

ipset restore set <archivo. ¿Qué hace ipset cuando lo cuentas restore? ¿Crees que funciona igual que iptables? ¿Recuperar datos?

Nada de eso: se fusiona y las direcciones antiguas no desaparecen, no se cierra el acceso.

Encontramos un error cuando probamos el aislamiento. Ahora hay un sistema bastante complicado: en lugar de restorellevarse a cabo create temp, entonces restore flush tempy restore temp. Al final del intercambio: por atomicidad, porque si se realiza por primera vez flushy en ese momento llega un paquete, se descartará y algo saldrá mal. Por lo tanto, hay un poco de magia negra.

cónsul kv get -datacenter = otro. Como dije, creemos que estamos solicitando algunos datos, pero obtendremos datos o un error. Podemos hacer esto a través del Cónsul localmente, pero en este caso, tanto uno como el otro colgarán.

El cliente local de Consul es un contenedor sobre la API HTTP. Pero simplemente se cuelga y no responde Ctrl + C o Ctrl + Z, no importa qué, solokill -9en la consola adyacente. Nos encontramos con esto cuando estábamos construyendo un gran grupo. Pero todavía no tenemos solución, nos estamos preparando para corregir este error en Consul.

El líder del cónsul no responde. Nuestro maestro en el centro de datos no responde, pensamos: "Probablemente, ¿el algoritmo de re-selección funcionará ahora?"

No, no funcionará, y el monitoreo no mostrará nada: el cónsul dirá que hay un índice de compromiso, se ha encontrado un líder, todo está bien.

¿Cómo estamos luchando contra esto? service consul restarten cron cada hora. Si tiene 50 servidores, no es gran cosa. Cuando haya 16,000, comprenderá cómo funciona.

Conclusión

Como resultado, obtuvimos las siguientes ventajas:

100% de cobertura de todas las máquinas Linux.
Velocidad.
Automatización
Liberaron a los ingenieros de hierro y redes de la esclavitud.
Hay oportunidades de integración que son casi infinitas: incluso con Kubernetes, incluso con Ansible, incluso con Python.

Contras : Cónsul, con quien ahora vivimos, y un precio de error muy alto. Como ejemplo, una vez a las 6 pm (horario de máxima audiencia en Rusia), descarté algo en las listas de redes. Estábamos construyendo aislamiento en BEFW en ese momento. Parece que me equivoqué en alguna parte, indiqué la máscara incorrecta, pero todo cayó en dos segundos. El monitoreo se enciende, el oficial de guardia entra: "¡Todo está con nosotros!" El jefe del departamento se puso gris cuando le explicó al negocio por qué sucedió esto.

El precio del error es tan alto que se nos ocurrió nuestro propio procedimiento de profilaxis complicado. Si lo implementará en una producción grande, no necesita dar una ficha maestra sobre Cónsul a todos. Terminará mal.

Costo.Escribí el código solo durante 400 horas. Para apoyar a mi equipo de 4 personas, pasa 10 horas al mes. En comparación con el precio de cualquier firewall de nueva generación, es gratis.

Planes El plan a largo plazo es la búsqueda de transporte alternativo a cambio o adicional del cónsul. Quizás sea Kafka o algo así. Pero en los próximos años viviremos del cónsul.

Planes inmediatos: integración con Fail2ban, con monitoreo, con nftables, posiblemente con otras distribuciones, métricas, monitoreo avanzado, optimización. El soporte de Kubernetes también está en algún lugar de los planes, porque en este momento tenemos varios grupos y deseos.

Otro de los planes:

buscar anomalías de tráfico;
gestión de mapas de red;
Apoyo de Kubernetes;
montaje de paquetes para todos los sistemas;
IU web

Trabajamos constantemente para expandir la configuración, aumentar las métricas y optimizar.

Únete al proyecto El proyecto resultó ser genial, pero, desafortunadamente, sigue siendo un proyecto de una persona. Ven a GitHub e intenta hacer algo: comprometerte, probar, ofrecer algo, dar tu evaluación.

Mientras tanto, nos estamos preparando para Saint HighLoad ++ , que se llevará a cabo los días 6 y 7 de abril en San Petersburgo, e invitamos a los desarrolladores de sistemas de alta carga a solicitar un informe . Los oradores experimentados ya saben qué hacer, y recomendamos que los recién llegados a los discursos al menos lo intenten . Participar en la conferencia como orador tiene varias ventajas. Que puedes leer, por ejemplo, al final de este artículo .

Cónsul + iptables =: 3