Contabilidad por el Puerto de Servicio (FTP,SMTP,UDP)

Bien, supongamos que también queremos una mejor idea de que tipo de tráfico exactamente está transportándose por nuestro enlace PPP. Por ejemplo, nosotros podríamos querer saber cuanto del enlace están consumiendo los servicios FTP, SMTP, y Web.

Hay un par de rasgos interesantes a esta configuración. Primeramente, hemos especificado el protocolo. Cuando especificamos puertos en nuestras reglas, también debemos especificar un protocolo porque TCP y UDP proveen conjuntos separados de puertos. Ya que todos estos servicios están basados en TCP, lo hemos especificado como el protocolo. Segundo, tenemos especificado dos servicios ftp y ftp-data en un comando. ipfwadm permite establecer puertos simples, rango de puertos o una lista arbitraria de puertos. El comando ipchains permite cualesquiera, puertos simples o rango de puertos, que es lo que hemos usado aqui. La sintaxis «ftp-data: ftp» significa «puertos ftp-data (20) hasta ftp (21),» y es como nosotros codificamos rangos de puertos en ambos: ipchains e iptables. Cuando usted tiene una lista de puertos en una regla de contabilidad, eso significa que cualquier dato recibido para alguno de los puertos en la lista, provocará que el dato sea sumado a los totales de esa entrada. Recordando que el servicio FTP utiliza dos puertos, el de comando y el de transferencia de datos, los hemos añadido a la vez para sumar el tráfico de FTP. Finalmente, especificamos la dirección origen como “0 / 0”, que es la notación especial que coincide con todas las direcciones y es requerida por ambos comandos ipfwadm e ipchains para especificar los puertos.
Podemos extendernos un poco en el segundo punto para darnos una vista diferente de los datos en nuestro enlace. Ahora imaginemos que nosotros clasificamos tráfico FTP, SMTP, y del Web como tráfico esencial, y todo el otro tráfico como no esencial.
Aquí creamos dos cadenas definidas por usuario, una llamada a-essent, donde capturamos datos de contabilidad para servicios esenciales y otra llamada a-noness, donde capturamos datos de contabilidad para servicios no esenciales. Entonces agregamos a nuestra cadena forward las reglas que coinciden con nuestros servicios esenciales y saltan a la cadena a-essent, donde tenemos justamente una regla que acepta todos los datagramas y los cuenta. La última regla en nuestra cadena forward es una regla que salta a nuestra cadena a-noness, donde otra vez tenemos solamente una regla que acepta todos los datagramas y los cuenta. La regla que salta a la cadena a-noness no será alcanzada por ninguno de nuestros servicios esenciales, puesto que ellos se habrán aceptado en su propia cadena. Nuestras cuentas para servicios esenciales y no esenciales estarán por consiguiente disponibles en las reglas dentro de esas cadenas.
Esto parece bastante simple. Desafortunadamente, hay un pequeño pero inevitable problema al intentar efectuar contabilidad por el tipo de servicio. Recordará que discutimos el rol que juega la MTU en redes TCP/IP en un capítulo anterior. La MTU define el datagrama más largo que se transmitirá en un dispositivo de red. Cuando un datagrama se recibe por un encaminador que es más grande que el MTU de la interfaz que necesita al retransmitirlo, el encaminador realiza un truco llamado fragmentación. El encaminador fragmenta el datagrama largo en piezas pequeñas no más largos que la MTU de la interfase y entonces transmite éstas piezas. El encaminador construye nuevas cabeceras para poner delante de cada una de éstas piezas, y éstas son las que la máquina remota usa para reconstruir el dato original. Desafortunadamente, durante el proceso de fragmentación el puerto se pierde para todos menos para el primer fragmento. Esto significa que la contabilidad IP no puede contar adecuadamente datagramas fragmentados. Puede contar fiablemente sólo el primer fragmento o datagramas no fragmentados. Hay un pequeño truco permitido por ipfwadm que asegura que mientras nosotros no podamos saber exactamente desde que puerto el segundo y siguientes fragmentos vienen, podemos todavía contarlos. Una temprana versión del software de contabilidad Linux asignó a los fragmentos un número de puerto falso, 0xFFFF, que podríamos contar.