Aplicaciones de ALG
Configuración de las propiedades de la aplicación
Para configurar las propiedades de la aplicación, incluya la application instrucción en el nivel de [edit applications] jerarquía:
[edit applications] application application-name { application-protocol protocol-name; child-inactivity-timeout seconds; destination-port port-number; gate-timeout seconds; icmp-code value; icmp-type value; inactivity-timeout value; protocol type; rpc-program-number number; snmp-command command; source-port port-number; ttl-threshold value; uuid hex-value; }
Puede agrupar objetos de aplicación mediante la configuración de la application-set instrucción; para obtener más información, consulte Configuración de conjuntos de aplicaciones.
En esta sección se incluyen las siguientes tareas para configurar aplicaciones:
- Configuración de un protocolo de aplicación
- Configuración del protocolo de red
- Configuración del código y tipo de ICMP
- Configuración de puertos de origen y destino
- Configuración del período de tiempo de espera de inactividad
- Configuración de una aplicación ALG de IKE
- Configuración de SIP
- Configuración de un comando SNMP para la coincidencia de paquetes
- Configuración de un número de programa RPC
- Configuración del umbral TTL
- Configuración de un identificador único universal
Configuración de un protocolo de aplicación
La application-protocol instrucción le permite especificar cuál de los protocolos de aplicación (ALG) compatibles se debe configurar e incluir en un conjunto de aplicaciones para el procesamiento del servicio. Para configurar protocolos de aplicación, incluya la application-protocol instrucción en el nivel de [edit applications application application-name] jerarquía:
[edit applications application application-name] application-protocol protocol-name;
En la tabla 1 se muestra la lista de protocolos compatibles. Para obtener más información acerca de protocolos específicos, consulte Descripciones de ALG.
Nombre del protocolo |
Valor de la CLI |
Comentarios |
|---|---|---|
Protocolo de arranque (BOOTP) |
|
Es compatible con BOOTP y el protocolo de configuración dinámica de host (DHCP). |
Llamada a procedimiento remoto (RPC) del entorno informático distribuido (DCE) |
|
Requiere que la |
Mapa de puertos RPC DCE |
|
Requiere que la |
Sistema de nombres de dominio (DNS) |
|
Requiere que la |
ejecutivo |
|
Requiere que la |
FTP |
|
Requiere que la |
H.323 |
|
– |
IKE ALG |
|
Requiere que la |
Protocolo de mensajes de control de Internet (ICMP) |
|
Requiere que la |
Protocolo entre ORBES de Internet |
|
– |
IP |
|
– |
Iniciar sesión |
|
– |
BIOS de red |
|
Requiere que la |
NetShow |
|
Requiere que la |
Protocolo de tunelización punto a punto |
|
– |
Audio real |
|
– |
Protocolo de transmisión en tiempo real (RTSP) |
|
Requiere que la |
RPC protocolo de datagramas de usuario (UDP) o TCP |
|
Requiere que la |
Mapeo de puertos RPC |
|
Requiere que la |
Concha |
|
Requiere que la |
Protocolo de inicio de sesión |
|
– |
SNMP |
|
Requiere que la |
SQLNet |
|
Requiere que la |
Programa Talk |
|
|
Ruta de rastreo |
|
Requiere que la |
FTP trivial (TFTP) |
|
Requiere que la |
WinFrame |
|
– |
Puede configurar puertas de enlace a nivel de aplicación (ALG) para ICMP y rastrear la ruta en reglas de firewall con estado, TDR o CoS cuando se configura dos veces TDR en el mismo conjunto de servicios. Estos ALG no se pueden aplicar a flujos creados por el Protocolo de controlador de puerta de enlace de paquetes (PGCP). Twice TDR no admite ningún otro ALG. TDR aplica solo la dirección IP y los encabezados TCP o UDP, pero no la carga.
Para obtener más información acerca de cómo configurar dos veces TDR, consulte Descripción general del direccionamiento de red de Junos Address Aware.
Configuración del protocolo de red
La protocol instrucción le permite especificar cuál de los protocolos de red compatibles debe coincidir en una definición de aplicación. Para configurar protocolos de red, incluya la protocol instrucción en el nivel de [edit applications application application-name] jerarquía:
[edit applications application application-name] protocol type;
Especifique el tipo de protocolo como un valor numérico; para los protocolos más utilizados, los nombres de texto también se admiten en la interfaz de línea de comandos (CLI). En la Tabla 2 se muestra la lista de los protocolos compatibles.
Tipo de protocolo de red |
Valor de la CLI |
Comentarios |
|---|---|---|
Encabezado de autenticación de seguridad IP (IPsec) (AH) |
|
– |
Protocolo de puerta de enlace externa (EGP) |
|
– |
Encapsulación IPsec Seguridad carga (ESP) |
|
– |
Encapsulación de enrutamiento genérico (GR) |
|
– |
ICMP |
|
Requiere un |
ICMPv6 |
|
Requiere un |
Protocolo de administración de grupos de Internet (IGMP) |
|
– |
IP en IP |
|
– |
OSPF |
|
– |
Multidifusión independiente del protocolo (PIM) |
|
– |
Protocolo de reserva de recursos (RSVP) |
|
– |
TCP |
|
Requiere un |
UDP |
|
Requiere un |
Para obtener una lista completa de los posibles valores numéricos, consulte RFC 1700, Números asignados (para el conjunto de protocolos de Internet).
La versión IP 6 (IPv6) no se admite como protocolo de red en las definiciones de aplicación.
De forma predeterminada, la función dos veces TDR puede afectar a los encabezados IP, TCP y UDP incrustados en la carga útil de los mensajes de error ICMP. Puede incluir las protocol tcp instrucciones and protocol udp con la instrucción application para configuraciones dos veces TDR. Para obtener más información acerca de cómo configurar dos veces TDR, consulte Descripción general del direccionamiento de red de Junos Address Aware.
Configuración del código y tipo de ICMP
El código y el tipo de ICMP proporcionan una especificación adicional, junto con el protocolo de red, para la coincidencia de paquetes en una definición de aplicación. Para configurar las opciones del ICMP, incluya las icmp-code instrucciones and icmp-type en el nivel de [edit applications application application-name] jerarquía:
[edit applications application application-name] icmp-code value; icmp-type value;
Solo puede incluir un código ICMP y un valor de tipo. La application-protocol instrucción debe tener el valor icmp. En la Tabla 3 se muestra la lista de valores ICMP admitidos.
Declaración de la CLI |
Descripción |
|---|---|
|
Este valor o palabra clave proporciona información más específica que En lugar del valor numérico, puede especificar uno de los siguientes sinónimos de texto (también se enumeran los valores de campo). Las palabras clave se agrupan por el tipo de ICMP al que están asociadas: parámetro-problema: Redirigir: tiempo excedido: Inalcanzables: |
|
Normalmente, esta coincidencia se especifica junto con la En lugar del valor numérico, puede especificar uno de los siguientes sinónimos de texto (también se enumeran los valores de campo): |
Si configura una interfaz con un filtro de firewall de entrada que incluya una acción de rechazo y con un conjunto de servicios que incluya reglas de firewall con estado, el enrutador ejecutará el filtro de firewall de entrada antes de que se ejecuten las reglas de firewall con estado en el paquete. Como resultado, cuando el motor de reenvío de paquetes envía un mensaje de error ICMP a través de la interfaz, es posible que las reglas de firewall con estado quiten el paquete porque no se vio en la dirección de entrada.
Las posibles soluciones alternativas son incluir un filtro de tabla de reenvío para realizar la acción de rechazo, ya que este tipo de filtro se ejecuta después del firewall con estado en la dirección de entrada, o incluir un filtro de servicio de salida para evitar que los paquetes ICMP generados localmente vayan al servicio de firewall con estado.
Configuración de puertos de origen y destino
Los puertos de origen y destino TCP o UDP proporcionan especificaciones adicionales, junto con el protocolo de red, para la coincidencia de paquetes en una definición de aplicación. Para configurar puertos, incluya las destination-port instrucciones and source-port en el nivel de [edit applications application application-name] jerarquía:
[edit applications application application-name] destination-port value; source-port value;
Debe definir un puerto de origen o de destino. Normalmente, esta coincidencia se especifica junto con la protocol instrucción match para determinar qué protocolo se está utilizando en el puerto; para conocer las restricciones, consulte la tabla 1.
Puede especificar un valor numérico o uno de los sinónimos de texto enumerados en la Tabla 4.
Nombre de puerto |
Número de puerto correspondiente |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Para obtener más información acerca de los criterios coincidentes, consulte la Guía del usuario de políticas de enrutamiento, filtros de firewall y agentes de policía de tráfico.
Configuración del período de tiempo de espera de inactividad
Puede especificar un período de tiempo de espera para la inactividad de la aplicación. Si el software no ha detectado ninguna actividad durante la duración, el flujo deja de ser válido cuando expira el temporizador. Para configurar un período de tiempo de espera, incluya la inactivity-timeout instrucción en el nivel de [edit applications application application-name] jerarquía:
[edit applications application application-name] inactivity-timeout seconds;
El valor predeterminado es 30 segundos. El valor que configure para una aplicación anula cualquier valor global configurado en el nivel de [edit interfaces interface-name service-options] jerarquía; para obtener más información, consulte Configurar ajustes predeterminados de tiempo de espera para interfaces de servicios.
Configuración de una aplicación ALG de IKE
Antes de la versión 17.4R1 de Junos OS, la traducción de direcciones de red-recorrido (TDR-T) no es compatible con el conjunto de funciones IPsec de Junos VPN Site Secure en los enrutadores de la serie MX. El ALG de IKE permite el paso de paquetes IKEv1 e IPsec a través de filtros NAPT-44 y NAT64 entre pares IPsec que no cumplen con TDR-T. Este ALG solo admite el modo de túnel ESP. Puede utilizar la aplicación junos-ikeALG IKE predefinida , que tiene valores predefinidos para el puerto de destino (500), el tiempo de espera de inactividad (30 segundos), el tiempo de espera de puerta (120 segundos) y el tiempo de espera de inactividad de la sesión ESP (800 segundos). Si desea utilizar el ALG de IKE con valores diferentes de la aplicación predefinida junos-ike , debe configurar una nueva aplicación ALG de IKE.
Para configurar una aplicación ALG de IKE:
Especifique un nombre para la aplicación.
[edit applications] user@host# set application junos-ike
Especifique el ALG de ICR.
[edit applications application junos-ike] user@host# set application-protocol ike-esp-nat
Especifique el protocolo UDP.
[edit applications application junos-ike] user@host# set protocol udp
Especifique 500 para el puerto de destino.
[edit applications application junos-ike] user@host# set destination-port 500
-
Especifique el número de segundos que la sesión de IKE está inactiva antes de que se suprima. El valor predeterminado es de 30 segundos.
[edit applications application junos-ike] user@host# set inactivity-timeout seconds
Especifique el número de segundos que pueden transcurrir después de que IKE establezca la asociación de seguridad entre el cliente y el servidor IPsec y antes de que se inicie el tráfico ESP en ambas direcciones. Si el tráfico ESP no se inició antes de este valor de tiempo de espera, las puertas ESP se eliminarán y el tráfico ESP se bloqueará. El valor predeterminado es de 120 segundos.
[edit applications application junos-ike] user@host# set gate-timeout seconds
Especifique el tiempo de espera de inactividad de la sesión ESP (tráfico de datos IPsec) en segundos. Si no se pasa tráfico de datos IPsec en la sesión ESP en este tiempo, la sesión se eliminará. El valor predeterminado es de 800 segundos.
[edit applications application junos-ike] user@host# set child-inactivity-timeout seconds
Configuración de SIP
El protocolo de inicio de sesión (SIP) es un protocolo generalizado para la comunicación entre puntos de conexión involucrados en servicios de Internet como telefonía, fax, videoconferencias, mensajería instantánea e intercambio de archivos.
Junos OS proporciona servicios de ALG de acuerdo con el estándar descrito en RFC 3261, SIP: Protocolo de inicio de sesión. Los flujos SIP en Junos OS son los que se describen en RFC 3665, Ejemplos básicos de flujo de llamadas del Protocolo de iniciación de sesión (SIP).
Antes de implementar el ALG SIP de Junos OS, debe familiarizarse con ciertas limitaciones, descritas en Limitaciones de ALG SIP de Junos OS
El uso de TDR junto con el ALG SIP da como resultado cambios en los campos del encabezado SIP debido a la traducción de direcciones. Para obtener una explicación de estas traducciones, consulte Interacción SIP ALG con traducción de direcciones de red.
Para implementar SIP en interfaces de servicios adaptables, configure la application-protocol instrucción en el nivel de [edit applications application application-name] jerarquía con el valor sip. Para obtener más información acerca de esta instrucción, consulte Configurar un protocolo de aplicación. Además, hay otras dos instrucciones que puede configurar para modificar cómo se implementa SIP:
Puede permitir que el enrutador acepte cualquier llamada SIP entrante para los dispositivos de puntos de conexión que están detrás del firewall de TDR. Cuando un dispositivo detrás del firewall se registra con el proxy que está fuera del firewall, el PIC de AS o multiservicios mantiene el estado de registro. Cuando la
learn-sip-registerinstrucción está habilitada, el enrutador puede utilizar esta información para aceptar llamadas entrantes. Si esta instrucción no está configurada, no se aceptan llamadas entrantes; Solo los dispositivos detrás del firewall pueden llamar a dispositivos fuera del firewall.Para configurar el registro SIP, incluya la
learn-sip-registerinstrucción en el nivel de[edit applications application application-name]jerarquía:[edit applications application application-name] learn-sip-register;
Nota:La
learn-sip-registerinstrucción no es aplicable a los servicios de próxima generación MX-SPC3.También puede inspeccionar manualmente el registro SIP mediante la emisión del
show services stateful-firewall sip-registercomando; para obtener más información, consulte la Referencia de comandos de servicios y conceptos básicos del sistema de Junos OS. Elshow services stateful-firewall sip-registercomando no es compatible con servicios de próxima generación.Puede especificar un período de tiempo de espera para la duración de las llamadas SIP que se ponen en espera. Cuando una llamada se pone en espera, no hay actividad y los flujos pueden agotar el tiempo de espera después de que expire el período configurado
inactivity-timeout, lo que da como resultado el desmontaje del estado de la llamada. Para evitar esto, cuando una llamada se pone en espera, el temporizador de flujo se restablece alsip-call-hold-timeoutciclo para conservar el estado y los flujos de la llamada durante más tiempo que elinactivity-timeoutperíodo.Nota:La
sip-call-hold-timeoutinstrucción no es aplicable a los servicios de próxima generación MX-SPC3.Para configurar un período de tiempo de espera, incluya la
sip-call-hold-timeoutinstrucción en el nivel de[edit applications application application-name]jerarquía:[edit applications application application-name] sip-call-hold-timeout seconds;
El valor predeterminado es 7200 segundos y el intervalo va de 0 a 36.000 segundos (10 horas).
Interacción SIP ALG con traducción de direcciones de red
El protocolo de traducción de direcciones de red (TDR) permite que varios hosts en una subred privada compartan una única dirección IP pública para acceder a Internet. Para el tráfico saliente, TDR reemplaza la dirección IP privada del host en la subred privada por la dirección IP pública. Para el tráfico entrante, la dirección IP pública se convierte de nuevo en la dirección privada y el mensaje se enruta al host adecuado en la subred privada.
El uso de TDR con el servicio Protocolo de inicio de sesión (SIP) es más complicado porque los mensajes SIP contienen direcciones IP en los encabezados SIP, así como en el cuerpo del SIP. Cuando se usa TDR con el servicio SIP, los encabezados SIP contienen información sobre la persona que llama y el receptor, y el dispositivo traduce esta información para ocultarla de la red externa. El cuerpo del SIP contiene la información del Protocolo de descripción de sesión (SDP), que incluye las direcciones IP y los números de puerto para la transmisión de los medios. El dispositivo traduce la información de SDP para asignar recursos para enviar y recibir los medios.
La forma en que se reemplazan las direcciones IP y los números de puerto en los mensajes SIP depende de la dirección del mensaje. En el caso de un mensaje saliente, la dirección IP privada y el número de puerto del cliente se sustituyen por la dirección IP pública y el número de puerto del firewall de Juniper Networks. En el caso de un mensaje entrante, la dirección pública del firewall se sustituye por la dirección privada del cliente.
Cuando se envía un mensaje INVITE a través del firewall, la puerta de enlace de la capa de aplicación SIP (ALG) recopila información del encabezado del mensaje en una tabla de llamadas, que utiliza para reenviar los mensajes posteriores al punto de conexión correcto. Cuando llega un mensaje nuevo, por ejemplo, un ACK o 200 OK, el ALG compara los campos "De:, Para:, e ID de llamada:" con la tabla de llamadas para identificar el contexto de llamada del mensaje. Si llega un nuevo mensaje INVITE que coincide con la llamada existente, el ALG lo procesa como REINVITE.
Cuando llega un mensaje que contiene información de SDP, el ALG asigna puertos y crea una asignación TDR entre ellos y los puertos del SDP. Dado que el SDP requiere puertos secuenciales para los canales del Protocolo de transporte en tiempo real (RTP) y del Protocolo de control en tiempo real (RTCP), el ALG proporciona puertos pares e impares consecutivos. Si no puede encontrar un par de puertos, descarta el mensaje SIP.
Este tema contiene las siguientes secciones:
Llamadas salientes
Cuando se inicia una llamada SIP con un mensaje de solicitud SIP de la red interna a la externa, TDR reemplaza las direcciones IP y los números de puerto en el SDP y vincula las direcciones IP y los números de puerto al firewall de Juniper Networks. Los campos de encabezado SIP Vía, Contacto, Ruta y Ruta de registro, si están presentes, también están vinculados a la dirección IP del firewall. El ALG almacena estas asignaciones para usarlas en retransmisiones y para mensajes de respuesta SIP.
Luego, el ALG SIP abre agujeros en el firewall para permitir que los medios pasen por el dispositivo en los puertos asignados dinámicamente negociados en función de la información del SDP y los campos de encabezado Vía, Contacto y Ruta de registro. Los agujeros también permiten que los paquetes entrantes lleguen a las direcciones y puertos IP de contacto, vía y ruta de registro. Al procesar el tráfico de retorno, el ALG inserta los campos SIP originales Contact, Via, Route y Record-Route nuevamente en los paquetes.
Llamadas entrantes
Las llamadas entrantes se inician desde la red pública a direcciones TDR públicas estáticas o a direcciones IP de interfaz en el dispositivo. Las NAT estáticas son direcciones IP configuradas estáticamente que apuntan a hosts internos; Las direcciones IP de interfaz son registradas dinámicamente por el ALG mientras monitorea los mensajes de REGISTRO enviados por hosts internos al registrador SIP. Cuando el dispositivo recibe un paquete SIP entrante, configura una sesión y reenvía la carga útil del paquete al ALG SIP.
El ALG examina el mensaje de solicitud SIP (inicialmente una INVITACIÓN) y, según la información del SDP, abre puertas para los medios salientes. Cuando llega un mensaje de respuesta 200 OK, el ALG SIP realiza TDR en las direcciones IP y los puertos y abre agujeros en la dirección de salida. (Las puertas abiertas tienen un corto tiempo de vida y se agotan si no se recibe rápidamente un mensaje de respuesta de 200 OK).
Cuando llega una respuesta 200 OK, el proxy SIP examina la información del SDP y lee las direcciones IP y los números de puerto de cada sesión multimedia. El ALG SIP del dispositivo realiza TDR en las direcciones y los números de puerto, abre agujeros para el tráfico saliente y actualiza el tiempo de espera para las puertas en la dirección entrante.
Cuando el ACK llega para el 200 OK, también pasa por el SIP ALG. Si el mensaje contiene información de SDP, el ALG SIP garantiza que las direcciones IP y los números de puerto no se cambien con respecto a la invitación anterior; si lo hacen, el ALG elimina los agujeros antiguos y crea nuevos agujeros para permitir el paso de los medios. El ALG también supervisa los campos SIP Vía, Contacto y Ruta de registro y abre nuevos agujeros si determina que estos campos han cambiado.
Llamadas desviadas
Una llamada desviada es cuando, por ejemplo, el usuario A fuera de la red llama al usuario B dentro de la red y el usuario B desvía la llamada al usuario C fuera de la red. El ALG SIP procesa la INVITACIÓN del usuario A como una llamada entrante normal. Pero cuando el ALG examina la llamada desviada de B a C fuera de la red y observa que se llega a B y C mediante la misma interfaz, no abre agujeros en el firewall, ya que los medios fluirán directamente entre el usuario A y el usuario C.
Terminación de la llamada
El mensaje BYE finaliza una llamada. Cuando el dispositivo recibe un mensaje BYE, traduce los campos del encabezado como lo hace con cualquier otro mensaje. Pero debido a que un mensaje BYE debe ser reconocido por el receptor con un 200 OK, el ALG retrasa el desmontaje de llamadas durante cinco segundos para dar tiempo a la transmisión del 200 OK.
Mensajes de reinvitación de llamadas
Los mensajes de re-INVITAR agregan nuevas sesiones multimedia a una llamada y eliminan las sesiones multimedia existentes. Cuando se agregan nuevas sesiones de medios a una llamada, se abren nuevos agujeros en el firewall y se crean nuevos enlaces de dirección. El proceso es idéntico a la configuración de llamada original. Cuando se eliminan una o más sesiones de medios de una llamada, se cierran los agujeros y se liberan los enlaces como con un mensaje BYE.
Temporizadores de sesión de llamada
El ALG SIP utiliza el valor Session-Expires para agotar el tiempo de espera de una sesión si no se recibe un mensaje de Re-INVITE o UPDATE. El ALG obtiene el valor Session-Expires, si está presente, de la respuesta 200 OK a INVITE y usa este valor para señalar el tiempo de espera. Si el ALG recibe otro INVITE antes de que se agote el tiempo de espera de la sesión, restablece todos los valores de tiempo de espera a este nuevo INVITE o a los valores predeterminados, y el proceso se repite.
Como medida de precaución, el ALG SIP utiliza valores de tiempo de espera estrictos para establecer la cantidad máxima de tiempo que puede existir una llamada. Esto garantiza que el dispositivo esté protegido en caso de que ocurra uno de los siguientes eventos:
Los sistemas finales se bloquean durante una llamada y no se recibe un mensaje BYE.
Los usuarios malintencionados nunca envían un BYE en un intento de atacar un ALG SIP.
Las implementaciones deficientes del proxy SIP no procesan Record-Route y nunca envían un mensaje BYE.
Los errores de red impiden que se reciba un mensaje BYE.
Cancelación de llamada
Cualquiera de las partes puede cancelar una llamada enviando un mensaje CANCELAR. Al recibir un mensaje CANCEL, el ALG SIP cierra los agujeros a través del firewall, si se ha abierto alguno, y libera los enlaces de dirección. Antes de liberar los recursos, el ALG retrasa la antigüedad del canal de control durante aproximadamente cinco segundos para dar tiempo a que pasen los últimos 200 OK. La llamada finaliza cuando expira el tiempo de espera de cinco segundos, independientemente de si llega una respuesta 487 o no 200.
Bifurcación
La bifurcación permite que un proxy SIP envíe un único mensaje de INVITACIÓN a varios destinos simultáneamente. Cuando llegan varios mensajes de respuesta 200 OK para la sola llamada, el ALG SIP analiza pero actualiza la información de la llamada con los primeros 200 mensajes OK que recibe.
Mensajes SIP
El formato de mensaje SIP consta de una sección de encabezado SIP y el cuerpo SIP. En los mensajes de solicitud, la primera línea de la sección de encabezado es la línea de solicitud, que incluye el tipo de método, el URI de solicitud y la versión del protocolo. En los mensajes de respuesta, la primera línea es la línea de estado, que contiene un código de estado. Los encabezados SIP contienen direcciones IP y números de puerto que se utilizan para la señalización. El cuerpo del SIP, separado de la sección de encabezado por una línea en blanco, está reservado para la información de descripción de la sesión, lo cual es opcional. Actualmente, Junos OS solo admite SDP. El cuerpo del SIP contiene las direcciones IP y los números de puerto que se utilizan para transportar los medios.
Encabezados SIP
En el siguiente mensaje de solicitud SIP de ejemplo, TDR reemplaza las direcciones IP en los campos de encabezado para ocultarlas de la red externa.
INVITE bob@10.150.20.5SIP/2.0 Via: SIP/2.0/UDP10.150.20.3:5434 From: alice@10.150.20.3To: bob@10.150.20.5Call-ID: a12abcde@10.150.20.3Contact: alice@10.150.20.3:5434 Route: <sip:netscreen@10.150.20.3:5060> Record-Route: <sip:netscreen@10.150.20.3:5060>
La forma en que se realiza la traducción de direcciones IP depende del tipo y la dirección del mensaje. Un mensaje puede ser cualquiera de los siguientes:
Solicitud entrante
Respuesta saliente
Solicitud saliente
Respuesta entrante
La Tabla 5 muestra cómo se realiza la TDR en cada uno de estos casos. Tenga en cuenta que para varios de los campos de encabezado, el ALG determina más que solo si los mensajes provienen de dentro o fuera de la red. También debe determinar qué cliente inició la llamada y si el mensaje es una solicitud o respuesta.
Solicitud entrante (de público a privado) |
Para: |
Reemplazar dominio con dirección local |
De: |
Ninguno |
|
ID de llamada: |
Ninguno |
|
Vía: |
Ninguno |
|
URI de solicitud: |
Reemplace la dirección ALG con la dirección local |
|
Contacto: |
Ninguno |
|
Ruta de registro: |
Ninguno |
|
Ruta: |
Ninguno |
|
Respuesta saliente (de privado a público) |
Para: |
Reemplace la dirección ALG con la dirección local |
De: |
Ninguno |
|
ID de llamada: |
Ninguno |
|
Vía: |
Ninguno |
|
URI de solicitud: |
N/A |
|
Contacto: |
Reemplazar la dirección local con la dirección ALG |
|
Ruta de registro: |
Reemplazar la dirección local con la dirección ALG |
|
Ruta: |
Ninguno |
|
Solicitud saliente (de privado a público) |
Para: |
Ninguno |
De: |
Reemplazar la dirección local con la dirección ALG |
|
ID de llamada: |
Ninguno |
|
Vía: |
Reemplazar la dirección local con la dirección ALG |
|
URI de solicitud: |
Ninguno |
|
Contacto: |
Reemplazar la dirección local con la dirección ALG |
|
Ruta de registro: |
Reemplazar la dirección local con la dirección ALG |
|
Ruta: |
Reemplace la dirección ALG con la dirección local |
|
Respuesta saliente (de público a privado) |
Para: |
Ninguno |
De: |
Reemplace la dirección ALG con la dirección local |
|
ID de llamada: |
Ninguno |
|
Vía: |
Reemplace la dirección ALG con la dirección local |
|
URI de solicitud: |
N/A |
|
Contacto: |
Ninguno |
|
Ruta de registro: |
Reemplace la dirección ALG con la dirección local |
|
Ruta: |
Reemplace la dirección ALG con la dirección local |
Cuerpo SIP
La información del SDP en el cuerpo del SIP incluye las direcciones IP que el ALG utiliza para crear canales para la transmisión de medios. La traducción de la sección SDP también asigna recursos, es decir, números de puerto para enviar y recibir los medios.
El siguiente extracto de una sección de SDP de ejemplo muestra los campos que se traducen para la asignación de recursos.
o=user 2344234 55234434 IN IP410.150.20.3c=IN IP410.150.20.3m=audio43249RTP/AVP 0
Los mensajes SIP pueden contener más de una secuencia de medios. El concepto es similar a adjuntar varios archivos a un mensaje de correo electrónico. Por ejemplo, un mensaje INVITE enviado desde un cliente SIP a un servidor SIP puede tener los siguientes campos:
c=IN IP410.123.33.4m=audio33445RTP/AVP 0 c=IN IP410.123.33.4m=audio33447RTP/AVP 0 c=IN IP410.123.33.4m=audio33449RTP/AVP 0
Junos OS admite hasta 6 canales SDP negociados para cada dirección, para un total de 12 canales por llamada.
Limitaciones de SIP ALG de Junos OS
Se aplican las siguientes limitaciones a la configuración del ALG SIP:
Solo se admiten los métodos descritos en RFC 3261.
Solo se admite la versión 2 de SIP.
TCP no se admite como mecanismo de transporte para mensajes de señalización para MS-MPC, pero se admite para servicios de próxima generación.
No configure el ALG SIP cuando utilice STUN. si los clientes utilizan STUN/TURN para detectar el firewall o dispositivos TDR entre la persona que llama y el respondedor o proxy, el cliente intenta adivinar mejor el comportamiento del dispositivo TDR y actuar en consecuencia para realizar la llamada.
En MS-MPC, no utilice la opción de conjunto de TDR de asignación independiente del punto de conexión junto con el ALG SIP. Se producirán errores. Esto no se aplica a los servicios de última generación.
Los datos de señalización IPv6 no son compatibles con MS-MPC, pero sí con servicios de próxima generación.
No se admite la autenticación.
No se admiten mensajes cifrados.
La fragmentación de SIP no se admite para MS-MPC, pero sí para servicios de próxima generación.
Se supone que el tamaño máximo del paquete UDP que contiene un mensaje SIP es de 9 KB. No se admiten mensajes SIP mayores que este.
Se supone que el número máximo de canales de medios en un mensaje SIP es seis.
Los nombres de dominio completos (FQDN) no se admiten en campos críticos.
No se admite QoS. SIP admite reescrituras DSCP.
No se admite alta disponibilidad, excepto en modo de espera tibio.
No se admite una configuración de tiempo de espera de nunca en SIP ni en TDR.
No se admite la multidifusión (proxy de bifurcación).
Configuración de un comando SNMP para la coincidencia de paquetes
Puede especificar una configuración de comando SNMP para la coincidencia de paquetes. Para configurar SNMP, incluya la snmp-command instrucción en el nivel de [edit applications application application-name] jerarquía:
[edit applications application application-name] snmp-command value;
Los valores admitidos son get, get-next, sety trap. Solo puede configurar un valor para la coincidencia. La application-protocol instrucción en el nivel de [edit applications application application-name] jerarquía debe tener el valor snmp. Para obtener información acerca de cómo especificar el protocolo de aplicación, consulte Configurar un protocolo de aplicación.
Configuración de un número de programa RPC
Puede especificar un número de programa RPC para la coincidencia de paquetes. Para configurar un número de programa RPC, incluya la rpc-program-number instrucción en el nivel de [edit applications application application-name] jerarquía:
[edit applications application application-name] rpc-program-number number;
El rango de valores usado para DCE o RPC es de 100.000 a 400.000. La application-protocol instrucción en el nivel de [edit applications application application-name] jerarquía debe tener el valor rpc. Para obtener información acerca de cómo especificar el protocolo de aplicación, consulte Configurar un protocolo de aplicación.
Configuración del umbral TTL
Puede especificar un valor de umbral de tiempo de vida (TTL) de ruta de rastreo, el cual controla el nivel aceptable de penetración de red para el enrutamiento de rastreo. Para configurar un valor TTL, incluya la ttl-threshold instrucción en el nivel de [edit applications application application-name] jerarquía:
[edit applications application application-name] ttl-threshold value;
La application-protocol instrucción en el nivel de [edit applications application application-name] jerarquía debe tener el valor traceroute. Para obtener información acerca de cómo especificar el protocolo de aplicación, consulte Configurar un protocolo de aplicación.
Configuración de un identificador único universal
Puede especificar un identificador único universal (UUID) para objetos RPC DCE. Para configurar un valor UUID, incluya la uuid instrucción en el nivel de [edit applications application application-name] jerarquía:
[edit applications application application-name] uuid hex-value;
El uuid valor está en notación hexadecimal. La application-protocol instrucción en el nivel de [edit applications application application-name jerarquía debe tener el valor dce-rpc. Para obtener información acerca de cómo especificar el protocolo de aplicación, consulte Configurar un protocolo de aplicación. Para obtener más información sobre los números UUID, consulte http://www.opengroup.org/onlinepubs/9629399/apdxa.htm.
Ver también
Configuración de conjuntos de aplicaciones
Puede agrupar las aplicaciones que ha definido en un objeto con nombre incluyendo la application-set instrucción en el nivel de [edit applications] jerarquía con una application instrucción para cada aplicación:
[edit applications]
application-set application-set-name {
application application;
}
Para obtener un ejemplo de un conjunto de aplicaciones típico , consulte Ejemplos: Configuración de protocolos de aplicación.
Ejemplos: Configuración de protocolos de aplicación
En el ejemplo siguiente se muestra una definición de protocolo de aplicación que describe una aplicación FTP especial que se ejecuta en el puerto 78:
[edit applications]
application my-ftp-app {
application-protocol ftp;
protocol tcp;
destination-port 78;
timeout 100; # inactivity timeout for FTP service
}
En el ejemplo siguiente se muestra un protocolo ICMP especial (application-protocol icmp) de tipo 8 (eco ICMP):
[edit applications]
application icmp-app {
application-protocol icmp;
protocol icmp;
icmp-type icmp-echo;
}
En el siguiente ejemplo, se muestra un posible conjunto de aplicaciones:
[edit applications]
application-set basic {
http;
ftp;
telnet;
nfs;
icmp;
}
El software incluye un conjunto predefinido de protocolos de aplicación conocidos. El conjunto incluye aplicaciones para las que los filtros de firewall sin estado ya reconocen los puertos de destino TCP y UDP.
Verificación del resultado de sesiones ALG
Esta sección contiene ejemplos de resultados exitosos de sesiones ALG e información sobre la configuración del registro del sistema. Puede comparar los resultados de sus sesiones para comprobar si las configuraciones funcionan correctamente.
Ejemplo de FTP
En este ejemplo, se analiza el resultado durante una sesión FTP activa. Consta de cuatro flujos diferentes; dos son flujos de control y dos son flujos de datos. El ejemplo consta de las siguientes partes:
Salida de muestra
Tarjeta MS-MPC
En el caso de las MS-MPC, a continuación se muestra un ejemplo completo de salida del comando del show services stateful-firewall conversations application-protocol ftp modo operativo:
user@host>show services stateful-firewall conversations application-protocol ftp
Interface: ms-1/3/0, Service set: CLBJI1-AAF001
Conversation: ALG protocol: ftp
Number of initiators: 2, Number of responders: 2
Flow State Dir Frm count
TCP 1.1.79.2:14083 -> 2.2.2.2:21 Watch I 13
NAT source 1.1.79.2:14083 -> 194.250.1.237:50118
TCP 1.1.79.2:14104 -> 2.2.2.2:20 Forward I 3
NAT source 1.1.79.2:14104 -> 194.250.1.237:50119
TCP 2.2.2.2:21 -> 194.250.1.237:50118 Watch O 12
NAT dest 194.250.1.237:50118 -> 1.1.79.2:14083
TCP 2.2.2.2:20 -> 194.250.1.237:50119 Forward O 5
NAT dest 194.250.1.237:50119 -> 1.1.79.2:14104
Para cada flujo, la primera línea muestra información de flujo, incluido el protocolo (TCP), la dirección de origen, el puerto de origen, la dirección de destino, el puerto de destino, el estado del flujo, la dirección y el recuento de tramas.
El estado de un flujo puede ser
Watch,Forward, oDrop:Un
Watchestado de flujo indica que el ALG supervisa el flujo de control para obtener información de la carga. El procesamiento de TDR se realiza en el encabezado y la carga según sea necesario.Un
Forwardflujo reenvía los paquetes sin monitorear la carga. TDR se realiza en el encabezado según sea necesario.Un
Dropflujo descarta cualquier paquete que coincida con la tupla 5.
El recuento de tramas (
Frm count) muestra la cantidad de paquetes que se procesaron en ese flujo.
La segunda línea muestra la información de TDR.
sourceindica TDR de origen.destindica el destino TDR.La primera dirección y puerto de la línea TDR son la dirección original y el puerto que se traducen para ese flujo.
La segunda dirección y puerto en la línea TDR son la dirección traducida y el puerto para ese flujo.
Tarjeta MX-SPC3
En la tarjeta de servicios MX-SPC3, a continuación se muestra un ejemplo completo de salida del comando del show services sessions application-protocol ftp modo operativo:
user@host>show services sessions application-protocol ftp Session ID: 536870917, Service-set: ss1, Policy name: p1/131085, Timeout: 1, Valid Logical system: root-logical-system Resource information : FTP ALG, 1, 1 In: 12.10.10.10/35281 --> 22.20.20.3/8204;tcp, Conn Tag: 0x0, If: vms-2/0/0.100, Pkts: 6, Bytes: 320, Out: 22.20.20.3/8204 --> 60.1.1.2/48747;tcp, Conn Tag: 0x0, If: vms-2/0/0.200, Pkts: 9, Bytes: 8239, Session ID: 536870919, Service-set: ss1, Policy name: p1/131085, Timeout: 29, Valid Logical system: root-logical-system Resource information : FTP ALG, 1, 0 In: 12.10.10.10/44194 --> 22.20.20.3/21;tcp, Conn Tag: 0x0, If: vms-2/0/0.100, Pkts: 13, Bytes: 585, Out: 22.20.20.3/21 --> 60.1.1.2/48660;tcp, Conn Tag: 0x0, If: vms-2/0/0.200, Pkts: 11, Bytes: 650, Total sessions: 2
Para cada sesión:
En la primera línea se muestra información de flujo, como el ID de sesión, el nombre del conjunto de servicios, el nombre de la política, el tiempo de espera de la sesión, el nombre del sistema lógico y su estado.
La segunda línea,
Resource information, indica que ALG crea la sesión, incluido el nombre de ALG (FTP ALG) y el ID de grupo de ASL, que es 1, y el ID de recurso de ASL, que es 0 para la sesión de control y 1 para la sesión de datos.La tercera línea
Ines el flujo directo y la cuarta líneaOutes el flujo inverso, incluyendo la dirección de origen, el puerto de origen, la dirección de destino, el puerto de destino, el protocolo (TCP), la etiqueta de conexión de sesión, la interfaz entranteIny saliente,Outel recuento de tramas recibidas y los bytes. TDR se realiza en el encabezado según sea necesario.
Mensajes de registro del sistema FTP
Los mensajes de registro del sistema se generan durante una sesión FTP. Para obtener más información acerca de los registros del sistema, consulte Mensajes de registro del sistema.
Tarjeta MS-MPC
Los siguientes mensajes de registro del sistema se generan durante la creación del flujo de control FTP:
Registro del sistema de aceptación de reglas:
Oct 27 11:42:54 (FPC Slot 1, PIC Slot 1) {ss_ftp}[FWNAT]: ASP_SFW_RULE_ACCEPT: proto 6 (TCP) application: ftp, fe-3/3/3.0:1.1.1.2:4450 -> 2.2.2.2:21, Match SFW accept rule-set:, rule: ftp, term: 1Crear registro del sistema de flujo de aceptación:
Oct 27 11:42:54 (FPC Slot 1, PIC Slot 1) {ss_ftp}[FWNAT]: ASP_SFW_CREATE_ACCEPT_FLOW: proto 6 (TCP) application: ftp, fe-3/3/3.0:1.1.1.2:4450 -> 2.2.2.2:21, creating forward or watch flowRegistro del sistema para la creación del flujo de datos:
Oct 27 11:43:30 (FPC Slot 1, PIC Slot 1) {ss_ftp}[FWNAT]: ASP_SFW_FTP_ACTIVE_ACCEPT: proto 6 (TCP) application: ftp, so-2/1/2.0:2.2.2.2:20 -> 1.1.1.2:50726, Creating FTP active mode forward flow
Tarjeta MX-SPC3
Los siguientes mensajes de registro del sistema se generan durante la creación del flujo de control FTP:
Registro del sistema para la creación de sesiones de control FTP:
Mar 23 23:58:54 esst480r RT_FLOW: RT_FLOW_SESSION_CREATE_USF: Tag svc-set-name ss1: session created 20.1.1.2/52877->30.1.1.2/21 0x0 junos-ftp 20.1.1.2/52877->30.1.1.2/21 0x0 N/A N/A N/A N/A 6 p1 ss1-ZoneIn ss1-ZoneOut 818413576 N/A(N/A) ge-1/0/2.0 UNKNOWN UNKNOWN UNKNOWN N/A N/A -1 N/A Mar 23 23:59:00 esst480r junos-alg: RT_ALG_FTP_ACTIVE_ACCEPT: application:ftp data, vms-3/0/0.0 30.1.1.2:20 -> 20.1.1.2:33947 (TCP)
Registro del sistema para la creación de sesiones de datos FTP:
Mar 23 23:59:00 esst480r RT_FLOW: RT_FLOW_SESSION_CREATE_USF: Tag svc-set-name ss1: session created 30.1.1.2/20->20.1.1.2/33947 0x0 junos-ftp-data 30.1.1.2/20->20.1.1.2/33947 0x0 N/A N/A N/A N/A 6 p1 ss1-ZoneOut ss1-ZoneIn 818413577 N/A(N/A) ge-1/1/6.0 FTP-DATA UNKNOWN UNKNOWN Infrastructure File-Servers 2 N/A
Registro del sistema para la destrucción de la sesión de datos FTP:
Mar 23 23:59:02 esst480r RT_FLOW: RT_FLOW_SESSION_CLOSE_USF: Tag svc-set-name ss1: session closed TCP FIN: 30.1.1.2/20->20.1.1.2/33947 0x0 junos-ftp-data 30.1.1.2/20->20.1.1.2/33947 0x0 N/A N/A N/A N/A 6 p1 ss1-ZoneOut ss1-ZoneIn 818413577 2954(4423509) 281(14620) 2 FTP-DATA UNKNOWN N/A(N/A) ge-1/1/6.0 No Infrastructure File-Servers 2 N/A
Registro del sistema para la sesión de control FTP Destrucción de sesión:
Mar 23 23:59:39 esst480r RT_FLOW: RT_FLOW_SESSION_CLOSE_USF: Tag svc-set-name ss1: session closed Closed by junos-tcp-clt-emul: 20.1.1.2/52877->30.1.1.2/21 0x0 junos-ftp 20.1.1.2/52877->30.1.1.2/21 0x0 N/A N/A N/A N/A 6 p1 ss1-ZoneIn ss1-ZoneOut 818413576 23(1082) 18(1176) 45 UNKNOWN UNKNOWN N/A(N/A) ge-1/0/2.0 No N/A N/A -1 N/A
Análisis
Flujos de control
Tarjeta MS-MPC
Los flujos de control se establecen después de que se completa el apretón de manos de tres vías.
Controle el flujo desde el cliente FTP al servidor FTP. El puerto de destino TCP es 21.
TCP 1.1.79.2:14083 -> 2.2.2.2:21 Watch I 13 NAT source 1.1.79.2:14083 -> 194.250.1.237:50118Controle el flujo desde el servidor FTP al cliente FTP. El puerto de origen TCP es 21.
TCP 2.2.2.2:21 -> 194.250.1.237:50118 Watch O 12 NAT dest 194.250.1.237:50118 -> 1.1.79.2:14083
Tarjeta MX-SPC3
Los flujos de control se establecen después de que se completa el apretón de manos de tres vías.
Sesión de control desde el cliente FTP al servidor FTP, el puerto de destino TCP es 21.
Session ID: 536870919, Service-set: ss1, Policy name: p1/131085, Timeout: 29, Valid Logical system: root-logical-system Resource information : FTP ALG, 1, 0 In: 12.10.10.10/44194 --> 22.20.20.3/21;tcp, Conn Tag: 0x0, If: vms-2/0/0.100, Pkts: 13, Bytes: 585, Out: 22.20.20.3/21 --> 60.1.1.2/48660;tcp, Conn Tag: 0x0, If: vms-2/0/0.200, Pkts: 11, Bytes: 650,
Sesión de datos del cliente FTP al servidor FTP, es para el modo pasivo FTP.
Session ID: 536870917, Service-set: ss1, Policy name: p1/131085, Timeout: 1, Valid Logical system: root-logical-system Resource information : FTP ALG, 1, 1 In: 12.10.10.10/35281 --> 22.20.20.3/8204;tcp, Conn Tag: 0x0, If: vms-2/0/0.100, Pkts: 6, Bytes: 320, Out: 22.20.20.3/8204 --> 60.1.1.2/48747;tcp, Conn Tag: 0x0, If: vms-2/0/0.200, Pkts: 9, Bytes: 8239,
Sesión de datos del servidor FTP al cliente FTP, es para el modo activo FTP:
Session ID: 549978117, Service-set: ss1, Policy name: p1/131085, Timeout: 1, Valid Logical system: root-logical-system Resource information : FTP ALG, 1, 1 In: 22.20.20.3/20 --> 60.1.1.3/6049;tcp, Conn Tag: 0x0, If: vms-2/0/0.200, Pkts: 10, Bytes: 8291, Out: 12.10.10.10/33203 --> 22.20.20.3/20;tcp, Conn Tag: 0x0, If: vms-2/0/0.100, Pkts: 5, Bytes: 268,
Flujos de datos
Se negocia un puerto de datos de 20 para la transferencia de datos durante el transcurso del protocolo de control FTP. Estos dos flujos son flujos de datos entre el cliente FTP y el servidor FTP:
TCP 1.1.79.2:14104 -> 2.2.2.2:20 Forward I 3
NAT source 1.1.79.2:14104 -> 194.250.1.237:50119
TCP 2.2.2.2:20 -> 194.250.1.237:50119 Forward O 5
NAT dest 194.250.1.237:50119 -> 1.1.79.2:14104
Preguntas de solución de problemas
¿Cómo sé si el FTP ALG está activo?
El campo de protocolo ALG de la conversación debería mostrar
ftp.Debe haber un recuento de tramas válido (
Frm count) en los flujos de control.Un recuento de tramas válido en los flujos de datos indica que se ha realizado una transferencia de datos.
¿Qué necesito para comprobar si la conexión FTP está establecida pero no se realiza la transferencia de datos?
Lo más probable es que la conexión de control esté activa, pero la conexión de datos no funciona.
Compruebe los resultados de las conversaciones para determinar si están presentes los flujos de control y de datos.
¿Cómo interpreto cada flujo? ¿Qué significa cada flujo?
Flujo de control FTP Flujo iniciador: flujo con puerto de destino 21
Flujo de control FTP flujo de respuesta: flujo con puerto de origen; 21
Flujo de datos FTP Flujo iniciador: flujo con puerto de destino 20
Flujo de datos FTP Flujo de respondedor: flujo con puerto de origen 20
Ejemplo de ALG RTSP
El siguiente es un ejemplo de una conversación RTSP. La aplicación utiliza el protocolo RTSP para la conexión de control. Una vez que se establece la conexión, los medios se envían mediante el protocolo UDP (RTP).
Este ejemplo consta de lo siguiente:
- Prueba de salida para MS-MPC
- Salida de ejemplo para la tarjeta de servicios MX-SPC3
- Análisis
- Preguntas de solución de problemas
Prueba de salida para MS-MPC
Este es el resultado del comando del show services stateful-firewall conversations modo operativo:
user@host# show services stateful-firewall conversations Interface: ms-3/2/0, Service set: svc_set Conversation: ALG protocol: rtsp Number of initiators: 5, Number of responders: 5 Flow State Dir Frm count TCP 1.1.1.3:58795 -> 2.2.2.2:554 Watch I 7 UDP 1.1.1.3:1028 -> 2.2.2.2:1028 Forward I 0 UDP 1.1.1.3:1029 -> 2.2.2.2:1029 Forward I 0 UDP 1.1.1.3:1030 -> 2.2.2.2:1030 Forward I 0 UDP 1.1.1.3:1031 -> 2.2.2.2:1031 Forward I 0 TCP 2.2.2.2:554 -> 1.1.1.3:58795 Watch O 5 UDP 2.2.2.2:1028 -> 1.1.1.3:1028 Forward O 6 UDP 2.2.2.2:1029 -> 1.1.1.3:1029 Forward O 0 UDP 2.2.2.2:1030 -> 1.1.1.3:1030 Forward O 3 UDP 2.2.2.2:1031 -> 1.1.1.3:1031 Forward O 0
Salida de ejemplo para la tarjeta de servicios MX-SPC3
Este es el resultado del comando del show services sessions application-protocol rtsp modo operativo:
user@host# run show services sessions application-protocol rtsp Session ID: 1073741828, Service-set: sset1, Policy name: p1/131081, Timeout: 116, Valid Logical system: root-logical-system Resource information : RTSP ALG, 1, 0 In: 31.0.0.2/33575 --> 41.0.0.2/554;tcp, Conn Tag: 0x0, If: vms-4/0/0.1, Pkts: 8, Bytes: 948, Out: 41.0.0.2/554 --> 131.10.0.1/7777;tcp, Conn Tag: 0x0, If: vms-4/0/0.2, Pkts: 6, Bytes: 1117, Session ID: 1073741829, Service-set: sset1, Policy name: p1/131081, Timeout: 120, Valid Logical system: root-logical-system Resource information : RTSP ALG, 1, 1 In: 41.0.0.2/35004 --> 131.10.0.1/7780;udp, Conn Tag: 0x0, If: vms-4/0/0.2, Pkts: 220, Bytes: 79200, Out: 31.0.0.2/30004 --> 41.0.0.2/35004;udp, Conn Tag: 0x0, If: vms-4/0/0.1, Pkts: 0, Bytes: 0, Session ID: 1073741830, Service-set: sset1, Policy name: p1/131081, Timeout: 120, Valid Logical system: root-logical-system Resource information : RTSP ALG, 1, 4 In: 41.0.0.2/35006 --> 131.10.0.1/7781;udp, Conn Tag: 0x0, If: vms-4/0/0.2, Pkts: 220, Bytes: 174240, Out: 31.0.0.2/30006 --> 41.0.0.2/35006;udp, Conn Tag: 0x0, If: vms-4/0/0.1, Pkts: 0, Bytes: 0, Total sessions: 3
Análisis
Una conversación RTSP debe constar de flujos TCP correspondientes a la conexión de control RTSP. Debe haber dos flujos, uno en cada dirección, del cliente al servidor y del servidor al cliente:
TCP 1.1.1.3:58795 -> 2.2.2.2:554 Watch I 7 TCP 2.2.2.2:554 -> 1.1.1.3:58795 Watch O 5
La conexión de control RTSP para el flujo del iniciador se envía desde el puerto de destino 554.
La conexión de control RTSP para el flujo de respuesta se envía desde el puerto de origen 554.
Los flujos UDP corresponden a los medios RTP enviados a través de la conexión RTSP.
Preguntas de solución de problemas
Los medios no funcionan cuando se configura el ALG RTSP. ¿qué debo hacer?
Verifique las conversaciones RTSP para ver si existen flujos TCP y UDP.
El protocolo ALG debe mostrarse como
rtsp.
Nota:El estado del flujo se muestra como
Watch, porque se está llevando a cabo el procesamiento de ALG y el cliente está esencialmente "observando" o procesando la carga correspondiente a la aplicación. Para los flujos ALG FTP y RTSP, las conexiones de control son siempreWatchflujos.¿Cómo verifico si hay errores de ALG?
Para comprobar si hay errores, ejecute el siguiente comando. Cada ALG tiene un campo independiente para errores de paquetes ALG.
user@host# show services stateful-firewall statistics extensive Interface: ms-3/2/0 Service set: svc_set New flows: Accepts: 1347, Discards: 0, Rejects: 0 Existing flows: Accepts: 144187, Discards: 0, Rejects: 0 Drops: IP option: 0, TCP SYN defense: 0 NAT ports exhausted: 0 Errors: IP: 0, TCP: 276 UDP: 0, ICMP: 0 Non-IP packets: 0, ALG: 0 IP errors: IP packet length inconsistencies: 0 Minimum IP header length check failures: 0 Reassembled packet exceeds maximum IP length: 0 Illegal source address: 0 Illegal destination address: 0 TTL zero errors: 0, Illegal IP protocol number (0 or 255): 0 Land attack: 0 Non-IPv4 packets: 0, Bad checksum: 0 Illegal IP fragment length: 0 IP fragment overlap: 0 IP fragment reassembly timeout: 0 Unknown: 0 TCP errors: TCP header length inconsistencies: 0 Source or destination port number is zero: 0 Illegal sequence number and flags combinations: 0 SYN attack (multiple SYN messages seen for the same flow): 276 First packet not a SYN message: 0 TCP port scan (TCP handshake, RST seen from server for SYN): 0 Bad SYN cookie response: 0 UDP errors: IP data length less than minimum UDP header length (8 bytes): 0 Source or destination port number is zero: 0 UDP port scan (ICMP error seen for UDP flow): 0 ICMP errors: IP data length less than minimum ICMP header length (8 bytes): 0 ICMP error length inconsistencies: 0 Duplicate ping sequence number: 0 Mismatched ping sequence number: 0 ALG errors: BOOTP: 0, DCE-RPC: 0, DCE-RPC portmap: 0 DNS: 0, Exec: 0, FTP: 0 ICMP: 0 Login: 0, NetBIOS: 0, NetShow: 0 RPC: 0, RPC portmap: 0 RTSP: 0, Shell: 0 SNMP: 0, SQLNet: 0, TFTP: 0 Traceroute: 0
Mensajes de registro del sistema
Habilitar la generación de registros del sistema y verificar el registro del sistema también es útil para el análisis de flujo de ALG. Esta sección contiene lo siguiente:
Configuración de registros del sistema
Puede configurar la habilitación de mensajes de registro del sistema en varios niveles diferentes en la CLI de Junos OS. Como se muestra en las siguientes configuraciones de ejemplo, la elección del nivel depende de qué tan específico desee que sea el registro de eventos y qué opciones desee incluir. Para obtener más información sobre las opciones de configuración, consulte la biblioteca de administración de Junos OS para dispositivos de enrutamiento (nivel del sistema) o la biblioteca de interfaces de servicios de Junos OS para dispositivos de enrutamiento (todos los demás niveles).
En el nivel global más alto:
user@host# show system syslog file messages { any any; }A nivel de conjunto de servicios:
user@host# show services service-set svc_set syslog { host local { services any; } } stateful-firewall-rules allow_rtsp; interface-service { service-interface ms-3/2/0; }En el nivel de reglas de servicio:
user@host# show services stateful-firewall rule allow_rtsp match-direction input-output; term 0 { from { applications junos-rtsp; } then { accept; syslog; } }
Salida de registro del sistema
Los mensajes de registro del sistema se generan durante la creación del flujo, como se muestra en los siguientes ejemplos:
El siguiente mensaje de registro del sistema indica que el ASP coincidió con una regla de aceptación:
Oct 25 16:11:37 (FPC Slot 3, PIC Slot 2) {svc_set}[FWNAT]: ASP_SFW_RULE_ACCEPT: proto 6 (TCP) application: rtsp, ge-2/0/1.0:1.1.1.2:35595 -> 2.2.2.2:554, Match SFW accept rule-set: , rule: allow_rtsp, term: 0
Para obtener una lista completa de los mensajes de registro del sistema, consulte el Explorador de registros del sistema.