Pues nada, aquí andamos para intentar también ayudar en todo lo posible con este router.
Lo primero quiero agradecer a Theliel su labor desinteresada para resolver las dudas y problemas que van surgiendo. No es fácil encontrar gente así.
Confirmar con todos (incluido él) el "capado" de los fix de más de 139 carácteres. Ya me cargué un Mitrastar al creer que el fix estaba bien, y al ser más largo de 139 carácteres bloquearse.
Si se meten los comandos en diferentes fix del modo:
fix1="......"
fix2="......"
fix3="......"
...
De momento no he encontrado ningún tipo de limitación, y todo ha ido correcto.
Ahora estoy con Wireshark monitorizando si hay paquetes que se pierden o si las conexiones que quiero realmente las está bloqueando. Y me surge una nueva duda...
Hay veces que a traves del puerto UDP 3250 (source port) se conecta a una IP a través de un destination port... que muchas veces es distinto al 3250 este que he hablado antes.
Me imagino que con algun fix "iptable" podré filtrar estos puestos de destino, pero que son? ese puerto es al que me conecto en la IP de destino o es de mi propio router?
Si mi IP es 1.2.3.4 puerto 3250 y los datos de destino son IP 6.7.8.9 puerto 9899 me estoy conectando desde mi puerto UDP 3250 hasta el puerto 9899 de la ip de destino?
Puedo bloquear, cuando mi puerto sea el UDP 3250 para que solo me conecte a través de el a otras IPs con puertos 3250?
pd.: Los puertos que he puesto son un ejemplo cualquiera.
Buenas Jordycf, si te sirve de consuelo, como dije, me costó unos cuantos ATBR (borrar la nvram) dar con el número exacto, desconozco el motivo... quizás un desbordamiento de buffer... pero bueno, en principio tenemos suficiente a menos que se quiera escribir sentencias muy largas
Sobre puertos:
Cuando te conectas a un servicio externo, estos servicios suelen estar identificados por el puerto entrante que usan. Así por ejemplo las conexiones realizadas hacia el 80/TCP son casi siempre trafico HTTP, porque el puerto 80 es el puerto asignado por la IANA para ello:
http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml
Eso no significa que no pueda usarse el puerto 80 para otros servicios, ni tampoco que no pueda ponerse a la escucha un servidor web en otro puerto. Son estándares, pero no es una obligación.
Pero hablamos de los puertos de entrada, puertos en un dispositivo asociados a un servicio: 80 HTTP, 443 HTTPS, 21 FTP... pero al margen de estos puertos, el tráfico IP usa puertos para realizar conexiones (existen protocolos que no funcionan con puertos), tanto por parte del origen como por parte del destino.
Los puertos no son una asociación. El tráfico para que llegue al puerto 80 de un servidor web no tiene por qué salir por el puerto 80 del cliente. El OS/aplicación del equipo cliente es el que selecciona un puerto de un pool de puertos disponibles (que no se esté usando, que no esté reservado, que..) de forma aleatoria o pseudoaleatoria, y abre la conexión por dicho puerto, con total independencia de cual es el puerto de destinom que a fin de cuenta es el que define el servicio. Efectivamente el equipo recibirá a su vez el trafico generado de la conversción con el servidor por ese mismo puerto por regla general, pero es que el equipo cliente no tiene asociado dicho puerto a un servicio, sino que para él es un mero canal establecido.
Esto quiere decir que da igual que el puerto de origen sea el 3250 y no vaya al 3250 del servidor, de echo lo raro es que fuese así, lo normal es que ambos sean diferentes. Desde el punto de vista de un "cliente", lo que importa es el puerto de destino, no por el puerto que se manda, con lo que normalmente esto no se controla. Para un servidor es al reves, lo qeu importa es el puerto por el que entran las conexiones, por que son esos puertos a los que se asocian los diferentes servicios.
Cuando ves en Wiresharl una conexión, pongamos de ejemplo el siguiente paquete
192.168.1.2:3250 -> 8.8.8.8:53
Significa que tu equipo con la IP 192.168.1.2 está enviando un paquete a través de su puerto 3250/udp a la dirección de destino 8.8.8.8 y hacia el puerto 53/udp de dicho servidor (es decir, el servicio de DNS). Tú, desde Wireshark, no ves al router. Es decir, tú no mandas al router dicho paquete al puerto 53, tu le dices al router que quieres enviar un paquete a los servidores de google al puerto 53, y que realizas la conexión a través del puerto 3250. El router es un mero intermediario, los puertos al final efectivos y reales son tu 3250 y el 53, que son los que realmente importan.
Si el origen es 1.2.3.4 puerto 3250 y el destino 6.7.8.9 puerto 9899, efectivamente, te conectas desde el 3250 tuyo al 9899 externo
Puedes bloquear cualquier puerto, saliente, entrante... pero lo que dices creo que como digo no tiene mucho sentido, bloquear un puerto saliente de un equipo solo tiene sentido por lo general cuando se quiere restringir tráfico muy concreto por motivos muy concretos
