Hola Jordycf,
Puedes poner una regla previa con -j LOG y así puedes en el log (messages) o ejecutando dmesg, puedes ver si hay paquetes que lleguen que coinciden a esa regla. Lo que pasa que si la insertas con -I, sería así:
iptables -I FORWARD -s 192.168.1.150 -p udp --sport 3074 --dport 5000-5999 -j DROP
iptables -I FORWARD -s 192.168.1.150 -p udp --sport 3074 --dport 5000-5999 -j LOG
Saludos ;-)
Gracias madralphw en cuanto llegue a casa hoy insertaré un LOG a ver si está bien realizado. Lo he hecho tal cual sale en Wireshark:
Source ip: 192.168.1.150; Destination ip: (la del oponente); Source port: 3074 (siempre es la misma); Destination port: (varia, la mitad de las veces 3074 la otra mitad un puerto entre 5000:5999 que es la que he bloqueado.)
Aunque parece ser que algo hace puesto que como digo se ha incrementado bastante el tiempo durante el que la consola busca oponentes.Digamos que antes, al no filtrar oponentes el "casting" era más rápido, y ahora al bloquear esto pues tarda algo más.
Jordycf lapsus calami, lo siento, falta la s en port: (no es dport, es dports
iptables -I FORWARD -s 192.168.1.150 -p udp --sport 3074 -m multiport --dports 5000:5999 -j DROP
Edito:
Jordycf te puedo confirmar que funciona perfectamente, aun así como te digo dudo mucho que cambie algo, como tu mismo dijiste antes te pareció que funcionaba perfectamente pero no se estaba aplicando:
# iptables -nvL FORWARD Chain FORWARD (policy ACCEPT 851 packets, 208K bytes) pkts bytes target prot opt in out source destination 44 2252 TCPMSS tcp -- * eth0.3285 0.0.0.0/0 0.0.0.0/0 tcp flags:0x06/0x02 TCPMSS clamp to PMTU 10 280 DROP udp -- * * 192.168.1.200 0.0.0.0/0 udp spt:3074 multiport dports 5000:5999 nping --udp -g 3074 -p 5999 -e eth1 8.8.8.8 Starting Nping at 2015-11-20 16:35 Hora estßndar romance SENT (0.1780s) UDP 192.168.1.200:3074 > 8.8.8.8:5999 ttl=64 id=3230 iplen=28 SENT (1.2620s) UDP 192.168.1.200:3074 > 8.8.8.8:5999 ttl=64 id=3230 iplen=28 SENT (2.2640s) UDP 192.168.1.200:3074 > 8.8.8.8:5999 ttl=64 id=3230 iplen=28 SENT (3.2660s) UDP 192.168.1.200:3074 > 8.8.8.8:5999 ttl=64 id=3230 iplen=28 SENT (4.2680s) UDP 192.168.1.200:3074 > 8.8.8.8:5999 ttl=64 id=3230 iplen=28
Jordycf prueba con una de estas:
iptables -I FORWARD -s 192.168.1.150 -p udp --sport 3074 --dport 5000:5999 -j DROP ptables -I FORWARD -s 192.168.1.150 -p udp --sport 3074 --match multiport --dport 5000:5999 -j DROP
Yo siempre he usado la segunda, aunque en algunas ocasiones la 1º también puede funcionar. Luego en u rato lo compruebo y te digo
djbill excelente noticia, a ver si es posible que alguien nos confirme el estado de ella y le podemos echar el guante pronto.
Según me consta han entregado una versión B22 que soluciona problemas, lo que no tengo claro es si está en proceso de certificación o ya en FOA; a ver si nos hacemos con ella...
Un saludo.
Pues las pruebas de ayer no han tenido mucho éxito. Al parecer por la regla que puse no pasan paquetes.
Os pongo aquí la tabla que me aparece en Wireshark (entendiendo que en Destination me aparece la IP de mi rival).
Esta línea es la que quiero dejar pasar a traves del fix iptables:
| Source | Destination | Protocol | Length | Info |
| 192.168.1.150 | xx.xx.xxx.xx | UDP | 214 | Source port: 3074 Destination port: 3074 |
Y esta sería una de las que quiero bloquear (realmente quiero bloquear el rango de puertos 5000:5999)
| Source | Destination | Protocol | Length | Info |
| 192.168.1.150 | yy.yy.yyy.yy | UDP | 214 | Source port: 3074 Destination port: 5023 |
el fix "iptables -I FORWARD -s 192.168.1.150 -p udp --sport 3074 --dport 5000-5999 -j DROP" me muestra que no pasan paquetes por él. Por lo tanto entiendo que no está bloqueando nada puesto que la regla está mal puesta...
madralphw, a ver si miro los dial, en realidad no es algo que me sea costoso ir probándolo en el propio mitrastar porque aunq no lo tengo conectado a la línea si le tengo puenteada la conexión y puedo usarlo como ATA, a ver si "robo" uno de los fijos y pruebo.
Soluciones drástricas a las congelaciones sí... siempre sepuede programar por cron un reinicio cada 4-5 días, pero es demasiado drástrico. Estoy intentado lograr lo mismo pero solo reiniciando cfg_manager. Detenerlo y voler a levantarlo es sencillo, pero me está dando problemas a la hora de anidar en el mismo cron más de una instrucción que por alguna razón no lo hace bien... También tengo que comprar el cfg_manager de la B14 con el actual, desensamblarlo y ver si hicieron muchos cambios o puede mas o menos tracearse el problema.
La solución del reinicio completo es que durante unos 30-40 segundos te quedas muerto, la ventaja de hacerlo sólo con cfg_manager es que exceptuando el acceso a la interfaz web del router y alguan cosilla más, no se interrumpe nada, y además es mucho más rápido. A ver si es posible...
Los fichos no son problemas, el tamaño máximo establecido es de 128KB y tienen una rotación de 3, en cuanto estén los 3, el próximo sustituye al más viejo, con lo que ese aspecto si sé que está controlado
Hola Theliel,
Sí, lo modifiqué sólo para que las extensiones 20x fueran para el otro provider y lo el efecto secundario que obtuve fue que las llamadas a fjios/móviles salieran con número oculto (A saber porqué.. )
Probaré este fin de semana con tranquilidad, que el fijo tiene cierto uso para recibir llamadas y tiene que estar disponible. Pero casi prefiero sustituirlo por otro equipo si hay que andar reinciando cada poco.
bb
Pues ha subido unos megas el consumo de ram:
Ayer:
total used free shared buffers
Mem: 125672 47840 77832 0 3192
Hoy:
# uptime
15:48:12 up 1 day, 1 min, load average: 3.55, 3.58, 3.61
# free
total used free shared buffers
Mem: 125672 51624 74048 0 4092b
Ya van tres ficheros de messages:
# ls -last
0 drwxrwxrwx 10 1234 root 0 Nov 19 15:50 ..
104 -rw------- 1 1234 root 106169 Nov 19 15:50 messages
0 drwxrwxrwx 3 1234 root 0 Nov 19 09:01 .
128 -rw------- 1 1234 root 129052 Nov 19 09:00 messages.0
128 -rw------- 1 1234 root 129079 Nov 18 23:39 messages.1
Saludos ;)
Jordycf piensa que la configuración por defecto de todos los juegos es esa, es el juego quien cuando realiza la conexión debería de probar a realizarla hacia todos los puertos del juego si usa mas de uno. Es decir, si el juego requiere para la conexión los puertos 5 y 6, cuando tu te conectas a otro cliente el juego debería de probarlo a hacer tanto por el 5 como por el 6, el propio diseño de juego lo tendría que hacer así. Otra cosa es que el juego esté bugeado, pero el problema lo tendrían TODOS!! no sólo algunos usuarios.
La forma más rápida de ver por donde pasan los paquetes por las reglas es como te ha comentando madralphw, ni siquiera usar la segunda para registrarlo, usa directamente v para listar:
ipables -nvL
La primera/segunda columna te mostrará el número de paquetes/bytes que han pasado por dicha regla, con lo que es fácil ver si se está aplicando o no
madralphw, pero has probado añadir y modificar tu el dialplan?? has probado hacerlo desde el archivo de configuración?? No recuerdo a ver visto ningún bloqueo o limitación en ese sentido
