Firewall/Gateway en GNU/Linux + Regnum Online: Gestion del trafico a internet

[takola]

Nota: Este thread no es ninguna pregunta en concreto, ni la explicacion concreta de ningun problema de jugabilidad. Realmente, lo he escrito para organizarme un poco las ideas que he tenido sobre la gestion del trafico de internet para mejorar la calidad del juego en todo lo que este en mis manos. El objetivo es compartir conocimientos y la idea que he tenido, los problemas que me han surgido en su diseño, y abe si a alguien le sirve de algo, o puede ayudarme en algo para acabar de montar el chiringito.

Surak! Iluminame mis dudas!


Wolas!

Despues de unos años de servicio mi pobre maquina que hacia de router/firewall de casa se queda obsoleta, y estoy instalando uno nuevo (de aqui para adelante conocido como firewall) . Las tareas principales del firewall son a) gestionar la conexion de internet y su uso adecuado/balanceado desde los distintos clientes de la red; b) el filtrar trafico no deseado entre las distintas subredes que conecta (firewalling); y c) la de ofrecer los servicios basicos de redes a las dos subredes que componen la red de mi casa (wifi y lan). Ya que juego mucho al regnum ultimamente, voi a incluir optimizaciones especificas para obtener el mejor aprovechamiento del ancho de banda a la vez que consigo una aceptable jugabilidad en el juego.

No voi a ponerme a explicar que hace o deja de hacer exactamente el server, ni como se configura para ello. Existen miles de howtos y guias por internet para todo tipo de soluciones, por lo que me centrare exclusivamente en la solucion de requisitos especificos relacionados con el Regnum, suponiendo que el resto de server funciona como debe. Ya que no se puede diseñar una solucion sin saber que deseamos conseguir, he aqui los objetivos del proyecto:

1. Permitir jugar al Regnum desde cualquier cliente local.
2. Compartir actualizaciones/sincronizaciones entre clientes locales.
3. Minimizar el lag en las sesiones del juego en casos de saturacion de mi conexion a internet.
4. Permitir una instalacion y actualizacion rapida y sencilla de cliente del juego desde la red local. Esto es util tanto para reinstalar clientes locales, como para enganchar a amigos del mundo real al juego.

La solucion a diseñar debe de ser multiplataforma para los clientes, ya que tengo clientes locales tanto en Windows como en GNU/Linux, y lo ideal es que la optimizacion de recursos sea independiente del S.O. del cliente local.

Una vez expuesto la situacion concreta y los objetivos de la solucion, hay van las ideas que se me ocurren para su implementacion:

1. Permitir jugar al Regnum desde cualquier cliente local.

   Esto es lo mas sencillo. Una vez configurado el NAT y permitidas las conexiones que los clientes locales establezcan al exterior, deberia de funcionar sin problemas. En caso de usar un firewall en modo paranoico a full que solo permita las conexiones salientes hacia puertos/hosts explicitamente especificados, tendremos que expecificar los datos del regnum tmb, pero esa configuracion no es muy habitual en routers caseros.

2. Compartir actualizaciones/sincronizaciones entre clientes locales.

   La idea seria que una vez que uno de los clientes locales ha sincronizado el cliente obteniendo los recursos desde el site oficial, estos recursos se cacheen en la red local y se compartan al resto de clientes que los soliciten, ahorrando ancho de banda y acelerando la actualizacion del resto de clientes locales.
   
   El launcher utiliza el protocolo http para actualizarse, por lo que la solucion mas sencilla seria cachear dichos recursos mediante un proxy http. En Windows tengo entendido que el juego utiliza la configuracion de Internet Explorer para la configuracion del proxy. En GNU/Linux, la verdad que no lo se seguro, pero supongo que se podra usar la variable de entorno http_proxy para definirlo.
   
   En cualquier caso, un proxy transparente solucionaria el problema a nivel de red sin necesidad de configurar los clientes uno a uno, aunque esto significa que necesitamos saber exactamente que puerto se usa para la actualizacion de recursos, por si no es el estandar puerto 80 (el proxy transparente se configura en puertos especificos, por eso necesitamos saberlo).
   
   En cuanto a la sincronizacion a nivel del juego (ya una vez pasado el launcher), lo logico es que use la misma metodologia de actualizacion que el launcher, por lo que en principio el problema estaria solucionado.
   
   Aunque esta configuracion nos aliviara bastante el uso de ancho de banda durante las actualizaciones de clientes multiples, seguramente no cacheara el 100% de los recursos, ya que es posible que algunos ficheros de recursos no cumplan los requisitos de cacheo predeterminados del servidor proxy. Para poder cachear todo abria que configurar directivas especificas para el/los servidores de recursos del juego.
   
   Aqui se podria rizar aun mas el rizo, y montar la solucion de forma que no haya necesidad de que ningun cliente sincronize el juego para que los recursos se cacheen en el firewall. Seria cuestion de ejecutar periodicamente un script que checkease si hay updates o no en el/los servidor/es de recursos, y que sincronize los datos locales con los nuevos en caso de que haya updates. En principio no parece muy complicado, pero abria que practicar un poco de ingenieria inversa para descubrir como y donde se notifican los updates, y supone un gasto de tiempo muy elevado para la minima ventaja que conseguimos, aunque realmente quedaria chulo el tema .
   

3. Minimizar el lag en las sesiones del juego en casos de saturacion de mi conexion a internet.

   Antes de nada, una aclaracion: Esto no es ni pretende ser una solucion definitiva al lag. Con una correcta configuracion podremos aliviar mucho el lag en caso de que nuestra linea este muy saturada, pero la parte del server no lo podemos solucionar gestionando nuestro trafico, por lo que siempre dependeremos del estado en el que este el server. La principal ventaja de este metodo es que permite mantener descargas u otros tipos de traficos en internet sin afectar demasiado al lag del juego (dejemos el p2p a un lado: es posible gestionarlo correctamente pero se complica bastante la cosa debido a que este tipo de servicios establecen cantidades desorbitadas de conexiones a la vez, saturando la linea aunque tenga una teorica buena gestion de los paquetes).
   
   Esto es cuestion de QoS. La idea seria clasificar todo el trafico saliente de nuestra red hacia internet segun la prioridad que tenga. Solo gestionaremos nuestro trafico saliente, ya que el gestionar el trafico entrante supondria desechar paquetes que realmente nos han llegado, cosa que obviamente no tiene sentido (abria que reenviarlos, perdiendo efectividad en vez de ganarla).
   
   Los paquetes ACK e icmp y todo el trafico interactivo tanto del juego como de otros servicios tendran prioridad alta, para que se envie lo antes posible, mientras que todos los paquetes de descargas masivas y demas trafico no interactivo debe tener prioridad baja, para que no molesten si hay trafico mas importante que este para enviar.
   
   Aqui el problema radica en diferenciar los paquetes de trafico interactivo de los de no interactivo del Regnum Online. Si la suposicion de que utiliza solo el protocolo http para la sincronizacion de recursos (el unico trafico no interactivo del juego) es correcta, la diferenciacion es bastante sencilla, pero si no es asi, la cosa se complica. En caso de que se usen puertos distintos estariamos en el mismo caso que del protocolo http, sencillo tambien, pero si no es asi solo nos queda mirar el ToS de los paquetes. Si este tampoco esta bien diferenciado, no se me ocurre como podria ser posible diferenciar estos dos traficos, y la optimizacion que conseguiriamos no seria tan alta como la que conseguiriamos si las separasemos.
   

4. Permitir una instalacion y actualizacion rapida y sencilla de cliente del juego desde la red local. Esto es util tanto para reinstalar clientes locales, como enganchar a amigos del mundo real al juego.

   Esto seria automatico con solo guardar los instaladores si la solucion del 2ndo objetivo es correcta. Una vez instalado el juego este se sincronizaria contra el cache local, por lo que se ahorraria mucho ancho hacia internet a la vez que se agilizaria muchisimo el sincronizado inicial del cliente.

Una vez expuestos los objetivos y posibles soluciones para implementar todo este chiringuito, paso con las dudas que surgen, abe si alguien sabe las respuestas correctas. De todas formas, seguire indagando y mirando por el foro, si descubro algo lo añado como respuesta:

• Que puertos y sobre que protocolos de transmision usa exactamente el Regnum para sincronizar los recursos, tanto a nivel de launcher, como del juego en si? y cuales para el trafico interactivo? En caso de que se compartan puertos, se podria diferenciar de alguna forma el trafico interactivo del no interactivo solo viendo la cabecera del protocolo de transmision (tcp/udp)? Todo el trafico interactivo deberia tener la misma prioridad, o convendria que algunos de ellos tuvieran mas prioridad que otros? En caso afirmativo, como podria diferenciar entre los distintos tipo de prioridades de traficos interactivos?
• En caso de que la transmision de recursos se haga por http, podria identificar de alguna forma el trafico perteneciente a este? Valdria que tuvieran una extension concreta, o un mime-type, o una direccion diferenciada, o cualqiuer aspecto caracteristico que puedan tener.

Y eso es todo por ahora. No se si soy el unico interesado en esto, o si son miles de personas las que lo han pensado, pero si hay alguien que haya implementado/pensado algo me gustaria conocer su experiencia. Si veis cualquier tipo de incoherencia, posible problema, mejor solucion posible o lo que sea, no dudeis en postear .

Como dije mas arriba, todo esto son suposiciones teoricas basadas en experiencias anteriores en el montaje de sistemas de este tipo, pero aun no he probado nada de ello . Ahora me pongo con ello, y abe k sale

Saludos.

P.D.: Vaia muerto me ha salido, me apiado por todos los que lo leais

[surak]

Hola, dos aclaraciones cortitas.

1. El launcher NO usa http para actualizarse, usa un protocolo propio.
2. Los recursos se bajan por HTTP. Pero no tienen un mime-type o una extension especifica (aunque en algun momento se habló de que la tengan)

Slds.

[sunos]

Originally Posted by takolo

2. Compartir actualizaciones/sincronizaciones entre clientes locales.

en mi experiencia personal (no particularmente con Regnum) en una red base 100 como tenemos todos hoy en dia podes solucionarte la vida con un NFS , centralizas la data del RO en el servidor, permitis que solo las maquinas de la intranet puedan montar el FS y le das permisos de escrituras, un solo cliente que actualize y se actualiza todo, por ahi seria enredado con los launcher para windows, sobre todo porque en linux y win difieren los nombres de las carpetass (no me fije si se puede moddificar eso en linux) pero las DB son exactamente iguales, en WIN XP hace falta un parche para poder usar NFS , en las versiones 2003 server viene de forma nativa y no creo que ni remotamente con todas las maquinas al mismo tiempo puedas saturar el ancho de banda de la red

EDITO: los puertos ahora no me los acuerdo, pero iptraf te va a dar la info que necesitas (asegurate de no tener otras conexiones embolandote en el medio)

[carbunc]

Me gustaría saber esi es posible que squid pued cachear los recursos que se bajan como text/html.

Por otro lado aqui pongo unas reglas como para macar a los paquetes de regnum. Luego de eso se pueden priorizar con htb.

#subida regnum
$IPTABLES -t mangle -A POSTROUTING -o $EXTIF -p tcp --dport 48001 -j MARK --set-mark 1
$IPTABLES -t mangle -A POSTROUTING -o $EXTIF -p udp --dport 9961 -j MARK --set-mark 1

#bajada regnum
$IPTABLES -t mangle -A POSTROUTING -o $INTIF -p tcp --sport 48001 -j MARK --set-mark 1
$IPTABLES -t mangle -A POSTROUTING -o $INTIF -p udp --sport 9961 -j MARK --set-mark 1

[takola]

Originally Posted by carbunc

Me gustaría saber esi es posible que squid pued cachear los recursos que se bajan como text/html.

Squid en principio cachea todo lo que no exceda el maxsize (esta en algun lugar en squid.conf), ni este explicitamente marcado como nocache (cgis y demas suelen estarlo en configuraciones por defecto). Eso combinandolo con configuracion de proxy transparente deberia de cachearte muchas cosas del regnum. Me gustaria poder cachear todo lo que viene del server regnum aun cuando exceda el maxsize, pero no se exactamente como se hace.

Saludos