Aplicações ALG
Configurando propriedades do aplicativo
Para configurar as propriedades do aplicativo, inclua a application declaração no nível da [edit applications] hierarquia:
[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; }
Você pode agrupar objetos de aplicativo configurando a application-set instrução; para obter mais informações, consulte Configurando conjuntos de aplicativos.
Esta seção inclui as seguintes tarefas para configurar aplicativos:
- Configurando um protocolo de aplicativo
- Configurando o protocolo de rede
- Configurando o código e o tipo de ICMP
- Configuração de portas de origem e destino
- Configurando o período de tempo limite de inatividade
- Configurando um aplicativo IKE ALG
- Configurando o SIP
- Configurando um comando SNMP para correspondência de pacotes
- Configuração de um número de programa RPC
- Configurando o limite de TTL
- Configurando um identificador exclusivo universal
Configurando um protocolo de aplicativo
A application-protocol declaração permite que você especifique qual dos protocolos de aplicativo (ALGs) suportados configurar e incluir em um conjunto de aplicativos para processamento de serviços. Para configurar protocolos de aplicativo, inclua a application-protocol declaração no nível da [edit applications application application-name] hierarquia:
[edit applications application application-name] application-protocol protocol-name;
A Tabela 1 mostra a lista de protocolos suportados. Para obter mais informações sobre protocolos específicos, consulte Descrições do ALG.
Nome do protocolo |
Valor da CLI |
Comentários |
|---|---|---|
Protocolo Bootstrap (BOOTP) |
|
Oferece suporte a BOOTP e protocolo de configuração dinâmica de host (DHCP). |
Chamada de procedimento remoto (RPC) do ambiente de computação distribuída (DCE) |
|
Requer que a |
Mapa de portas RPC DCE |
|
Requer que a |
Sistema de Nomes de Domínio (DNS) |
|
Requer que a |
Executivo |
|
Requer que a |
FTP |
|
Requer que a |
H.323 |
|
– |
IKE ALG |
|
Requer que a |
Protocolo de mensagens de controle da Internet (ICMP) |
|
Requer que a |
Protocolo Internet Inter-ORB |
|
– |
IP |
|
– |
Login |
|
– |
BIOS em rede |
|
Requer que a |
NetShow |
|
Requer que a |
Protocolo de tunelamento ponto a ponto |
|
– |
Áudio real |
|
– |
Protocolo de streaming em tempo real (RTSP) |
|
Requer que a |
RPC Protocolo de datagrama de usuário (UDP) ou TCP |
|
Requer que a |
Mapeamento de porta RPC |
|
Requer que a |
Concha |
|
Requer que a |
Protocolo de iniciação de sessão |
|
– |
SNMP |
|
Requer que a |
SQLNet |
|
Requer que a |
Programa de Palestras |
|
|
Rastrear rota |
|
Requer que a |
FTP trivial (TFTP) |
|
Requer que a |
WinFrame |
|
– |
Você pode configurar gateways de nível de aplicativo (ALGs) para ICMP e rastrear a rota sob regras de firewall stateful, NAT ou CoS quando duas vezes o NAT é configurado no mesmo conjunto de serviços. Esses ALGs não podem ser aplicados a fluxos criados pelo PGCP (Packet Gateway Controller Protocol). O Twice NAT não oferece suporte a nenhum outro ALGs. O NAT aplica apenas o endereço IP e os cabeçalhos TCP ou UDP, mas não o payload.
Para obter mais informações sobre como configurar duas vezes o NAT, consulte Visão geral do Endereçamento de Rede do Junos Address Aware.
Configurando o protocolo de rede
A protocol instrução permite especificar quais dos protocolos de rede suportados devem corresponder em uma definição de aplicativo. Para configurar protocolos de rede, inclua a protocol declaração no nível da [edit applications application application-name] hierarquia:
[edit applications application application-name] protocol type;
Você especifica o tipo de protocolo como um valor numérico; para os protocolos mais usados, os nomes de texto também são suportados na interface de linha de comando (CLI). A Tabela 2 mostra a lista dos protocolos suportados.
Tipo de protocolo de rede |
Valor da CLI |
Comentários |
|---|---|---|
Cabeçalho de autenticação de segurança IP (IPsec) (AH) |
|
– |
Protocolo de gateway externo (EGP) |
|
– |
Payload de Segurança (ESP) de encapsulamento de IPsec |
|
– |
Encapsulamento genérico de roteamento (GR) |
|
– |
ICMP |
|
Requer um |
ICMPv6 |
|
Requer um |
Protocolo de gerenciamento de grupos de Internet (IGMP) |
|
– |
IP em IP |
|
– |
OSPF |
|
– |
Multicast independente de protocolo (PIM) |
|
– |
Protocolo de reserva de recursos (RSVP) |
|
– |
TCP |
|
Requer um |
UDP |
|
Requer um |
Para obter uma lista completa de valores numéricos possíveis, consulte RFC 1700, Assigned Numbers (for the Internet Protocol Suite).
O IP versão 6 (IPv6) não é suportado como um protocolo de rede em definições de aplicativo.
Por padrão, o recurso duas vezes NAT pode afetar cabeçalhos IP, TCP e UDP incorporados na carga útil de mensagens de erro ICMP. Você pode incluir as protocol tcp instruções and protocol udp com a instrução application para duas configurações NAT. Para obter mais informações sobre como configurar duas vezes o NAT, consulte Visão geral do Endereçamento de Rede do Junos Address Aware.
Configurando o código e o tipo de ICMP
O código e o tipo ICMP fornecem especificações adicionais, em conjunto com o protocolo de rede, para correspondência de pacotes em uma definição de aplicativo. Para definir as configurações de ICMP, inclua as icmp-code declarações and icmp-type no nível da [edit applications application application-name] hierarquia:
[edit applications application application-name] icmp-code value; icmp-type value;
Você pode incluir apenas um código ICMP e um valor de tipo. A application-protocol instrução deve ter o valor icmp. A Tabela 3 mostra a lista de valores ICMP suportados.
Declaração da CLI |
Descrição |
|---|---|
|
Esse valor ou palavra-chave fornece informações mais específicas do que No lugar do valor numérico, você pode especificar um dos seguintes sinônimos de texto (os valores de campo também são listados). As palavras-chave são agrupadas pelo tipo de ICMP ao qual estão associadas: problema-parâmetro: Redirecionar: Tempo excedido: Inacessível: |
|
Normalmente, você especifica essa correspondência em conjunto com a No lugar do valor numérico, você pode especificar um dos seguintes sinônimos de texto (os valores de campo também estão listados): |
Se você configurar uma interface com um filtro de firewall de entrada que inclui uma ação de rejeição e com um conjunto de serviços que inclui regras de firewall stateful, o roteador executará o filtro de firewall de entrada antes que as regras de firewall stateful sejam executadas no pacote. Como resultado, quando o Mecanismo de Encaminhamento de Pacotes envia uma mensagem de erro ICMP pela interface, as regras de firewall stateful podem descartar o pacote porque ele não foi visto na direção de entrada.
As possíveis soluções alternativas são incluir um filtro de tabela de encaminhamento para executar a ação de rejeição, porque esse tipo de filtro é executado após o firewall stateful na direção de entrada, ou incluir um filtro de serviço de saída para impedir que os pacotes ICMP gerados localmente vão para o serviço de firewall stateful.
Configuração de portas de origem e destino
As portas de origem e destino TCP ou UDP fornecem especificações adicionais, em conjunto com o protocolo de rede, para correspondência de pacotes em uma definição de aplicativo. Para configurar portas, inclua as destination-port instruções and source-port no nível da [edit applications application application-name] hierarquia:
[edit applications application application-name] destination-port value; source-port value;
Você deve definir uma porta de origem ou destino. Normalmente, você especifica essa correspondência em conjunto com a protocol instrução match para determinar qual protocolo está sendo usado na porta; para restrições, consulte a Tabela 1.
Você pode especificar um valor numérico ou um dos sinônimos de texto listados na Tabela 4.
Nome da porta |
Número da porta correspondente |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Para obter mais informações sobre critérios de correspondência, consulte o Guia do usuário de políticas de roteamento, filtros de firewall e policiais de tráfego.
Configurando o período de tempo limite de inatividade
Você pode especificar um período de tempo limite para a inatividade do aplicativo. Se o software não tiver detectado nenhuma atividade durante a duração, o fluxo se tornará inválido quando o temporizador expirar. Para configurar um período de tempo limite, inclua a inactivity-timeout declaração no nível da [edit applications application application-name] hierarquia:
[edit applications application application-name] inactivity-timeout seconds;
O valor padrão é 30 segundos. O valor que você configura para um aplicativo substitui qualquer valor global configurado no nível de [edit interfaces interface-name service-options] hierarquia; para obter mais informações, consulte Definindo configurações de tempo limite padrão para interfaces de serviços.
Configurando um aplicativo IKE ALG
Antes do lançamento do Junos OS 17.4R1, a Network Address Translation-Traversal (NAT-T) não é suportada para o conjunto de recursos IPsec do Junos VPN Site Secure nos roteadores da Série MX. O IKE ALG permite a passagem de pacotes IKEv1 e IPsec através de filtros NAPT-44 e NAT64 entre pares IPsec que não são compatíveis com NAT-T. Este ALG suporta apenas o modo de túnel ESP. Você pode usar o aplicativo junos-ikeIKE ALG predefinido , que tem valores predefinidos para a porta de destino (500), tempo limite de inatividade (30 segundos), tempo limite de porta (120 segundos) e tempo limite ocioso da sessão ESP (800 segundos). Se você quiser usar o IKE ALG com valores diferentes do aplicativo predefinido junos-ike , será necessário configurar um novo aplicativo IKE ALG.
Para configurar um aplicativo IKE ALG:
Especifique um nome para o aplicativo.
[edit applications] user@host# set application junos-ike
Especifique o IKE ALG.
[edit applications application junos-ike] user@host# set application-protocol ike-esp-nat
Especifique o protocolo UDP.
[edit applications application junos-ike] user@host# set protocol udp
Especifique 500 para a porta de destino.
[edit applications application junos-ike] user@host# set destination-port 500
-
Especifique o número de segundos que a sessão de IKE está inativa antes de ser excluída. O padrão é 30 segundos.
[edit applications application junos-ike] user@host# set inactivity-timeout seconds
Especifique o número de segundos que podem passar depois que o IKE estabelece a associação de segurança entre o cliente IPsec e o servidor e antes que o tráfego ESP comece em ambas as direções. Se o tráfego ESP não tiver sido iniciado antes desse valor de tempo limite, as portas ESP serão excluídas e o tráfego ESP será bloqueado. O padrão é 120 segundos.
[edit applications application junos-ike] user@host# set gate-timeout seconds
Especifique o tempo limite ocioso da sessão ESP (tráfego de dados IPsec) em segundos. Se nenhum tráfego de dados IPsec for passado na sessão ESP nesse momento, a sessão será excluída. O padrão é 800 segundos.
[edit applications application junos-ike] user@host# set child-inactivity-timeout seconds
Configurando o SIP
O Session Initiation Protocol (SIP) é um protocolo generalizado para comunicação entre endpoints envolvidos em serviços de Internet, como telefonia, fax, videoconferência, mensagens instantâneas e troca de arquivos.
O Junos OS oferece serviços ALG de acordo com o padrão descrito no RFC 3261, SIP: Session Initiation Protocol. Os fluxos SIP sob o Junos OS são os descritos em RFC 3665, Exemplos de fluxo de chamadas básicas do protocolo de iniciação de sessão (SIP).
Antes de implementar o Junos OS SIP ALG, você deve estar familiarizado com certas limitações, discutidas em Limitações do Junos OS SIP ALG
O uso de NAT em conjunto com o SIP ALG resulta em alterações nos campos de cabeçalho SIP devido à conversão de endereços. Para obter uma explicação dessas traduções, consulte Interação SIP ALG com a Network Address Translation.
Para implementar o SIP em interfaces de serviços adaptáveis, configure a application-protocol declaração no nível da [edit applications application application-name] hierarquia com o valor sip. Para obter mais informações sobre essa declaração, consulte Configurando um protocolo de aplicativo. Além disso, há duas outras instruções que você pode configurar para modificar como o SIP é implementado:
Você pode habilitar o roteador para aceitar qualquer chamada SIP de entrada para os dispositivos de endpoint que estão atrás do firewall NAT. Quando um dispositivo atrás do firewall se registra com o proxy que está fora do firewall, o AS ou o PIC multisserviços mantém o estado de registro. Quando a
learn-sip-registerdeclaração está habilitada, o roteador pode usar essas informações para aceitar chamadas de entrada. Se essa declaração não estiver configurada, nenhuma chamada de entrada será aceita; Somente os dispositivos por trás do firewall podem chamar dispositivos fora do firewall.Para configurar o registro SIP, inclua a
learn-sip-registerdeclaração no nível da[edit applications application application-name]hierarquia:[edit applications application application-name] learn-sip-register;
Observação:A
learn-sip-registerdeclaração não é aplicável aos Serviços de Próxima Geração MX-SPC3.Você também pode inspecionar manualmente o registro SIP emitindo o
show services stateful-firewall sip-registercomando; para obter mais informações, consulte a Referência de comandos de serviços e fundamentos do sistema Junos OS. Oshow services stateful-firewall sip-registercomando não é suportado para Serviços de Próxima Geração.Você pode especificar um período de tempo limite para a duração das chamadas SIP colocadas em espera. Quando uma chamada é colocada em espera, não há atividade e os fluxos podem atingir o tempo limite após a expiração do período configurado
inactivity-timeout, resultando em desmontagem do estado da chamada. Para evitar isso, quando uma chamada é colocada em espera, o temporizador de fluxo é redefinido para osip-call-hold-timeoutciclo para preservar o estado da chamada e flui por mais tempo do que oinactivity-timeoutperíodo.Observação:A
sip-call-hold-timeoutdeclaração não é aplicável aos Serviços de Próxima Geração MX-SPC3.Para configurar um período de tempo limite, inclua a
sip-call-hold-timeoutdeclaração no nível da[edit applications application application-name]hierarquia:[edit applications application application-name] sip-call-hold-timeout seconds;
O valor padrão é 7200 segundos e o intervalo é de 0 a 36.000 segundos (10 horas).
Interação SIP ALG com a Network Address Translation
O protocolo Network Address Translation (NAT) permite que vários hosts em uma sub-rede privada compartilhem um único endereço IP público para acessar a Internet. Para o tráfego de saída, o NAT substitui o endereço IP privado do host na sub-rede privada pelo endereço IP público. Para tráfego de entrada, o endereço IP público é convertido novamente no endereço privado e a mensagem é roteada para o host apropriado na sub-rede privada.
Usar o NAT com o serviço SIP (Session Initiation Protocol) é mais complicado porque as mensagens SIP contêm endereços IP nos cabeçalhos SIP, bem como no corpo do SIP. Ao usar o NAT com o serviço SIP, os cabeçalhos SIP contêm informações sobre o chamador e o receptor, e o dispositivo traduz essas informações para ocultá-las da rede externa. O corpo SIP contém as informações do Protocolo de Descrição de Sessão (SDP), que inclui endereços IP e números de porta para transmissão da mídia. O dispositivo traduz informações de SDP para alocação de recursos para enviar e receber a mídia.
A substituição dos endereços IP e números de porta nas mensagens SIP depende da direção da mensagem. Para uma mensagem de saída, o endereço IP privado e o número da porta do cliente são substituídos pelo endereço IP público e pelo número da porta do firewall da Juniper Networks. Para uma mensagem de entrada, o endereço público do firewall é substituído pelo endereço privado do cliente.
Quando uma mensagem INVITE é enviada pelo firewall, o SIP Camada de aplicativo Gateway (ALG) coleta informações do cabeçalho da mensagem em uma tabela de chamadas, que ele usa para encaminhar mensagens subsequentes para o endpoint correto. Quando uma nova mensagem chega, por exemplo, um ACK ou 200 OK, o ALG compara os campos "De:, Para: e ID da chamada:" com a tabela de chamada para identificar o contexto de chamada da mensagem. Se chegar uma nova mensagem INVITE que corresponda à chamada existente, a ALG a processará como um REINVITE.
Quando uma mensagem contendo informações de SDP chega, o ALG aloca portas e cria um mapeamento NAT entre elas e as portas no SDP. Como o SDP requer portas sequenciais para os canais RTP (Real-Time Transport Protocol) e RTCP (Real-Time Control Protocol), o ALG fornece portas pares e ímpares consecutivas. Se não conseguir localizar um par de portas, ele descarta a mensagem SIP.
Este tópico contém as seguintes seções:
Chamadas efetuadas
Quando uma chamada SIP é iniciada com uma mensagem de solicitação SIP da rede interna para a externa, o NAT substitui os endereços IP e números de porta no SDP e vincula os endereços IP e números de porta ao firewall da Juniper Networks. Via, Contato, Rota e Registro-Rota Os campos de cabeçalho SIP, se presentes, também estão vinculados ao endereço IP do firewall. O ALG armazena esses mapeamentos para uso em retransmissões e para mensagens de resposta SIP.
O SIP ALG então abre orifícios no firewall para permitir que a mídia através do dispositivo nas portas atribuídas dinamicamente negociadas com base nas informações no SDP e nos campos de cabeçalho Via, Contact e Record-Route. Os orifícios também permitem que os pacotes de entrada alcancem os endereços IP e portas de contato, via e rota de registro. Ao processar o tráfego de retorno, o ALG insere os campos SIP originais de Contato, Via, Rota e Registro-Rota de volta nos pacotes.
Chamadas recebidas
As chamadas recebidas são iniciadas da rede pública para endereços NAT estáticos públicos ou para endereços IP de interface no dispositivo. NATs estáticos são endereços IP configurados estaticamente que apontam para hosts internos; Os endereços IP da interface são registrados dinamicamente pelo ALG enquanto ele monitora as mensagens REGISTER enviadas por hosts internos ao registrador SIP. Quando o dispositivo recebe um pacote SIP de entrada, ele configura uma sessão e encaminha a carga útil do pacote para o SIP ALG.
O ALG examina a mensagem de solicitação SIP (inicialmente um INVITE) e, com base nas informações do SDP, abre portas para mídia de saída. Quando uma mensagem de resposta 200 OK chega, o SIP ALG executa NAT nos endereços IP e portas e abre orifícios na direção de saída. (Os portões abertos têm um curto tempo de vida e atingem o tempo limite se uma mensagem de resposta 200 OK não for recebida rapidamente.)
Quando uma resposta 200 OK chega, o proxy SIP examina as informações do SDP e lê os endereços IP e os números de porta para cada sessão de mídia. O SIP ALG no dispositivo executa NAT nos endereços e números de porta, abre pinholes para tráfego de saída e atualiza o tempo limite para portões na direção de entrada.
Quando o ACK chega para o 200 OK, ele também passa pelo SIP ALG. Se a mensagem contiver informações de SDP, o SIP ALG garantirá que os endereços IP e os números de porta não sejam alterados em relação ao INVITE anterior — se forem, o ALG excluirá os orifícios antigos e criará novos orifícios para permitir a passagem da mídia. O ALG também monitora os campos SIP Via, Contact e Record-Route e abre novos orifícios se determinar que esses campos foram alterados.
Chamadas encaminhadas
Uma chamada encaminhada é quando, por exemplo, o usuário A fora da rede chama o usuário B dentro da rede e o usuário B encaminha a chamada para o usuário C fora da rede. O SIP ALG processa o CONVITE do usuário A como uma chamada de entrada normal. Mas quando o ALG examina a chamada encaminhada de B para C fora da rede e percebe que B e C são alcançados usando a mesma interface, ele não abre furos no firewall, porque a mídia fluirá diretamente entre o usuário A e o usuário C.
Terminação de chamadas
A mensagem BYE encerra uma chamada. Quando o dispositivo recebe uma mensagem BYE, ele traduz os campos de cabeçalho da mesma forma que faz com qualquer outra mensagem. Mas como uma mensagem BYE deve ser confirmada pelo receptor com um 200 OK, o ALG atrasa a desmontagem da chamada por cinco segundos para dar tempo para a transmissão do 200 OK.
Mensagens de reconvite de chamada
Re-INVITE mensagens, adicione novas sessões de mídia a uma chamada e remova as sessões de mídia existentes. Quando novas sessões de mídia são adicionadas a uma chamada, novos orifícios são abertos no firewall e novas ligações de endereço são criadas. O processo é idêntico à configuração original da chamada. Quando uma ou mais sessões de mídia são removidas de uma chamada, os pinholes são fechados e as associações liberadas da mesma forma que em uma mensagem BYE.
Temporizadores de sessão de chamada
O SIP ALG usa o valor Session-Expires para expirar uma sessão se uma mensagem Re-INVITE ou UPDATE não for recebida. O ALG obtém o valor Session-Expires, se presente, da resposta 200 OK para o INVITE e usa esse valor para o tempo limite de sinalização. Se o ALG receber outro INVITE antes que a sessão atinja o tempo limite, ele redefinirá todos os valores de tempo limite para esse novo INVITE ou para os valores padrão, e o processo será repetido.
Como medida de precaução, o SIP ALG usa valores de tempo limite rígidos para definir a quantidade máxima de tempo que uma chamada pode existir. Isso garante que o dispositivo esteja protegido caso ocorra um dos seguintes eventos:
Os sistemas finais travam durante uma chamada e uma mensagem BYE não é recebida.
Usuários mal-intencionados nunca enviam um BYE na tentativa de atacar um SIP ALG.
Implementações ruins do proxy SIP falham ao processar Record-Route e nunca enviam uma mensagem BYE.
Falhas de rede impedem que uma mensagem BYE seja recebida.
Cancelamento de chamadas
Qualquer uma das partes pode cancelar uma chamada enviando uma mensagem CANCELAR. Ao receber uma mensagem CANCEL, o SIP ALG fecha os orifícios no firewall — se algum tiver sido aberto — e libera as ligações de endereço. Antes de liberar os recursos, o ALG atrasa o envelhecimento do canal de controle por aproximadamente cinco segundos para dar tempo para que os 200 OK finais passem. A chamada é encerrada quando o tempo limite de cinco segundos expira, independentemente de uma resposta 487 ou não 200 chegar.
Bifurcação
A bifurcação permite que um proxy SIP envie uma única mensagem INVITE para vários destinos simultaneamente. Quando as várias mensagens de resposta 200 OK chegam para a chamada única, o SIP ALG analisa, mas atualiza as informações da chamada com as primeiras 200 mensagens OK recebidas.
Mensagens SIP
O formato de mensagem SIP consiste em uma seção de cabeçalho SIP e o corpo SIP. Em mensagens de solicitação, a primeira linha da seção de cabeçalho é a linha de solicitação, que inclui o tipo de método, o URI de solicitação e a versão do protocolo. Nas mensagens de resposta, a primeira linha é a linha de status, que contém um código de status. Os cabeçalhos SIP contêm endereços IP e números de porta usados para sinalização. O corpo SIP, separado da seção de cabeçalho por uma linha em branco, é reservado para informações de descrição da sessão, que são opcionais. Atualmente, o Junos OS oferece suporte apenas ao SDP. O corpo SIP contém endereços IP e números de porta usados para transportar a mídia.
Cabeçalhos SIP
No exemplo de mensagem de solicitação SIP a seguir, o NAT substitui os endereços IP nos campos de cabeçalho para ocultá-los da rede 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>
A forma como a conversão de endereço IP é executada depende do tipo e da direção da mensagem. Uma mensagem pode ser qualquer uma das seguintes:
Solicitação de entrada
Resposta de saída
Solicitação de saída
Resposta de entrada
A Tabela 5 mostra como o NAT é realizado em cada um desses casos. Observe que, para vários dos campos de cabeçalho, o ALG determina mais do que apenas se as mensagens vêm de dentro ou de fora da rede. Ele também deve determinar qual cliente iniciou a chamada e se a mensagem é uma solicitação ou resposta.
Solicitação de entrada (de público para privado) |
Para: |
Substituir domínio por endereço local |
De: |
Nenhum |
|
ID da chamada: |
Nenhum |
|
Via: |
Nenhum |
|
URI da solicitação: |
Substituir endereço ALG por endereço local |
|
Contato: |
Nenhum |
|
Rota de registro: |
Nenhum |
|
Rota: |
Nenhum |
|
Resposta de saída (de privado para público) |
Para: |
Substituir endereço ALG por endereço local |
De: |
Nenhum |
|
ID da chamada: |
Nenhum |
|
Via: |
Nenhum |
|
URI da solicitação: |
N/A |
|
Contato: |
Substituir endereço local pelo endereço ALG |
|
Rota de registro: |
Substituir endereço local pelo endereço ALG |
|
Rota: |
Nenhum |
|
Solicitação de saída (de privado para público) |
Para: |
Nenhum |
De: |
Substituir endereço local pelo endereço ALG |
|
ID da chamada: |
Nenhum |
|
Via: |
Substituir endereço local pelo endereço ALG |
|
URI da solicitação: |
Nenhum |
|
Contato: |
Substituir endereço local pelo endereço ALG |
|
Rota de registro: |
Substituir endereço local pelo endereço ALG |
|
Rota: |
Substituir endereço ALG por endereço local |
|
Resposta de saída (de público para privado) |
Para: |
Nenhum |
De: |
Substituir endereço ALG por endereço local |
|
ID da chamada: |
Nenhum |
|
Via: |
Substituir endereço ALG por endereço local |
|
URI da solicitação: |
N/A |
|
Contato: |
Nenhum |
|
Rota de registro: |
Substituir endereço ALG por endereço local |
|
Rota: |
Substituir endereço ALG por endereço local |
Corpo SIP
As informações de SDP no corpo SIP incluem endereços IP que o ALG usa para criar canais para o fluxo de mídia. A tradução da seção SDP também aloca recursos, ou seja, números de porta para enviar e receber a mídia.
O trecho a seguir de uma seção SDP de exemplo mostra os campos que são convertidos para alocação de recursos.
o=user 2344234 55234434 IN IP410.150.20.3c=IN IP410.150.20.3m=audio43249RTP/AVP 0
As mensagens SIP podem conter mais de um fluxo de mídia. O conceito é semelhante a anexar vários arquivos a uma mensagem de email. Por exemplo, uma mensagem INVITE enviada de um cliente SIP para um servidor SIP pode ter os seguintes 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
O Junos OS oferece suporte a até 6 canais SDP negociados para cada direção, para um total de 12 canais por chamada.
Limitações do Junos OS SIP ALG
As seguintes limitações se aplicam à configuração do SIP ALG:
Há suporte apenas para os métodos descritos no RFC 3261.
Somente o SIP versão 2 é suportado.
O TCP não tem suporte como um mecanismo de transporte para mensagens de sinalização para MS-MPCs, mas tem suporte para Serviços de Próxima Geração.
Não configure o SIP ALG ao usar o STUN. se os clientes usarem STUN/TURN para detectar o firewall ou os dispositivos NAT entre o chamador e o respondente ou proxy, o cliente tentará adivinhar melhor o comportamento do dispositivo NAT e agir de acordo para fazer a chamada.
Em MS-MPCs, não use a opção de pool NAT de mapeamento independente de ponto de endpoint em conjunto com o SIP ALG. Ocorrerão erros. Isso não se aplica aos Serviços de Próxima Geração.
Os dados de sinalização IPv6 não são compatíveis com MS-MPCs, mas sim com Serviços de Próxima Geração.
Não há suporte para autenticação.
Não há suporte para mensagens criptografadas.
A fragmentação SIP não tem suporte para MS-MPCs, mas tem suporte para serviços de próxima geração.
O tamanho máximo do pacote UDP que contém uma mensagem SIP é considerado 9 KB. Mensagens SIP maiores que isso não são suportadas.
O número máximo de canais de mídia em uma mensagem SIP é considerado seis.
Não há suporte para nomes de domínio totalmente qualificados (FQDNs) em campos críticos.
A QoS não é suportada. O SIP oferece suporte a regravações de DSCP.
Não há suporte para alta disponibilidade, exceto para espera passiva.
Uma configuração de tempo limite de nunca é suportada no SIP ou NAT.
Não há suporte para multicast (proxy de bifurcação).
Configurando um comando SNMP para correspondência de pacotes
Você pode especificar uma configuração de comando SNMP para correspondência de pacotes. Para configurar o SNMP, inclua a snmp-command declaração no nível da [edit applications application application-name] hierarquia:
[edit applications application application-name] snmp-command value;
Os valores com suporte são get, get-next, set, e trap. Você pode configurar apenas um valor para correspondência. A application-protocol instrução no nível de [edit applications application application-name] hierarquia deve ter o valor snmp. Para obter informações sobre como especificar o protocolo de aplicativo, consulte Configurando um protocolo de aplicativo.
Configuração de um número de programa RPC
Você pode especificar um número de programa RPC para correspondência de pacotes. Para configurar um número de programa RPC, inclua a rpc-program-number declaração no nível da [edit applications application application-name] hierarquia:
[edit applications application application-name] rpc-program-number number;
O intervalo de valores usados para DCE ou RPC é de 100.000 a 400.000. A application-protocol instrução no nível de [edit applications application application-name] hierarquia deve ter o valor rpc. Para obter informações sobre como especificar o protocolo de aplicativo, consulte Configurando um protocolo de aplicativo.
Configurando o limite de TTL
Você pode especificar um valor de limite de vida útil (TTL) da rota de rastreamento, que controla o nível aceitável de penetração de rede para roteamento de rastreamento. Para configurar um valor TTL, inclua a ttl-threshold declaração no nível da [edit applications application application-name] hierarquia:
[edit applications application application-name] ttl-threshold value;
A application-protocol instrução no nível de [edit applications application application-name] hierarquia deve ter o valor traceroute. Para obter informações sobre como especificar o protocolo de aplicativo, consulte Configurando um protocolo de aplicativo.
Configurando um identificador exclusivo universal
Você pode especificar um UUID (Identificador Exclusivo Universal) para objetos RPC DCE. Para configurar um valor UUID, inclua a uuid declaração no nível da [edit applications application application-name] hierarquia:
[edit applications application application-name] uuid hex-value;
O uuid valor está em notação hexadecimal. A application-protocol instrução no nível de [edit applications application application-name hierarquia deve ter o valor dce-rpc. Para obter informações sobre como especificar o protocolo de aplicativo, consulte Configurando um protocolo de aplicativo. Para obter mais informações sobre números UUID, consulte http://www.opengroup.org/onlinepubs/9629399/apdxa.htm.
Veja também
Configurando conjuntos de aplicativos
Você pode agrupar os aplicativos definidos em um objeto nomeado incluindo a application-set instrução no nível da [edit applications] hierarquia com uma application instrução para cada aplicativo:
[edit applications]
application-set application-set-name {
application application;
}
Para obter um exemplo de um conjunto de aplicativos típico, consulte Exemplos: Configuração de protocolos de aplicativos.
Exemplos: Configuração de protocolos de aplicativos
O exemplo a seguir mostra uma definição de protocolo de aplicativo que descreve um aplicativo FTP especial em execução na porta 78:
[edit applications]
application my-ftp-app {
application-protocol ftp;
protocol tcp;
destination-port 78;
timeout 100; # inactivity timeout for FTP service
}
O exemplo a seguir mostra um protocolo ICMP especial (application-protocol icmp) do tipo 8 (eco ICMP):
[edit applications]
application icmp-app {
application-protocol icmp;
protocol icmp;
icmp-type icmp-echo;
}
O exemplo a seguir mostra um possível conjunto de aplicativos:
[edit applications]
application-set basic {
http;
ftp;
telnet;
nfs;
icmp;
}
O software inclui um conjunto predefinido de protocolos de aplicativos bem conhecidos. O conjunto inclui aplicativos para os quais as portas de destino TCP e UDP já são reconhecidas por filtros de firewall stateless.
Verificando a saída de sessões ALG
Esta seção contém exemplos de saída bem-sucedida de sessões do ALG e informações sobre a configuração do log do sistema. Você pode comparar os resultados de suas sessões para verificar se as configurações estão funcionando corretamente.
Exemplo de FTP
Este exemplo analisa a saída durante uma sessão de FTP ativa. Consiste em quatro fluxos diferentes; dois são fluxos de controle e dois são fluxos de dados. O exemplo consiste nas seguintes partes:
Saída de amostra
Placa MS-MPC
Para MS-MPCs, veja a seguir um exemplo completo de saída do show services stateful-firewall conversations application-protocol ftp comando de modo operacional:
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 fluxo, a primeira linha mostra informações de fluxo, incluindo protocolo (TCP), endereço de origem, porta de origem, endereço de destino, porta de destino, estado do fluxo, direção e contagem de quadros.
O estado de um fluxo pode ser
Watch,Forward, ouDrop:Um
Watchestado de fluxo indica que o fluxo de controle é monitorado pelo ALG para obter informações na carga. O processamento do NAT é executado no cabeçalho e no payload, conforme necessário.Um
Forwardfluxo encaminha os pacotes sem monitorar a carga. O NAT é executado no cabeçalho conforme necessário.Um
Dropfluxo descarta qualquer pacote que corresponda à tupla 5.
A contagem de quadros (
Frm count) mostra o número de pacotes que foram processados nesse fluxo.
A segunda linha mostra as informações do NAT.
sourceindica o NAT da fonte.destindica o NAT de destino.O primeiro endereço e a primeira porta na linha NAT são o endereço e a porta originais que estão sendo convertidos para esse fluxo.
O segundo endereço e a segunda porta na linha NAT são o endereço e a porta convertidos para esse fluxo.
Placa MX-SPC3
Na placa de serviços MX-SPC3, a seguir está um exemplo completo de saída do comando de show services sessions application-protocol ftp modo operacional:
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 sessão:
A primeira linha mostra informações de fluxo, incluindo ID da sessão, nome do conjunto de serviços, nome da política, tempo limite da sessão, nome do sistema lógico e seu estado.
A segunda linha,
Resource information, indica que a sessão é criada pela ALG, incluindo o nome da ALG (FTP ALG) e a ID do grupo ASL, que é 1, e a ID do recurso ASL, que é 0 para a sessão de controle e 1 para a sessão de dados.A terceira linha
Iné o fluxo de encaminhamento e a quarta linhaOuté o fluxo reverso, incluindo o endereço de origem, porta de origem, endereço de destino, porta de destino, protocolo (TCP), tag de conexão de sessão, entrada eInsaída paraOutinterface, contagem de quadros recebidos e bytes. O NAT é executado no cabeçalho conforme necessário.
Mensagens de log do sistema FTP
As mensagens de log do sistema são geradas durante uma sessão de FTP. Para obter mais informações sobre logs do sistema, consulte Mensagens de log do sistema.
Placa MS-MPC
As seguintes mensagens de log do sistema são geradas durante a criação do fluxo de controle de FTP:
Log do sistema de aceitação de regra:
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: 1Criar log do sistema de fluxo de aceitação:
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 flowLog do sistema para criação de fluxo de dados:
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
Cartão MX-SPC3
As seguintes mensagens de log do sistema são geradas durante a criação do fluxo de controle de FTP:
Log do sistema para criação de sessão de controle de 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)
Log do sistema para criação de sessão de dados 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
Log do sistema para destruição de sessão de dados 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
Log do sistema para destruição de sessão de controle de FTP:
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álise
Fluxos de controle
Placa MS-MPC
Os fluxos de controle são estabelecidos após a conclusão do handshake de três vias.
Fluxo de controle do cliente FTP para o servidor FTP. A porta de destino TCP é 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 o fluxo do servidor FTP para o cliente FTP. A porta de origem TCP é 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
Placa MX-SPC3
Os fluxos de controle são estabelecidos após a conclusão do handshake de três vias.
Sessão de controle do cliente FTP para o servidor FTP, a porta de destino TCP é 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,
Sessão de dados do cliente FTP para o servidor FTP, é para o modo passivo 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,
Sessão de dados do servidor FTP para o cliente FTP, é para o modo ativo 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,
Fluxos de dados
Uma porta de dados de 20 é negociada para transferência de dados durante o curso do protocolo de controle FTP. Esses dois fluxos são fluxos de dados entre o cliente FTP e o 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
Perguntas sobre solução de problemas
Como posso saber se o FTP ALG está ativo?
O campo de protocolo ALG na conversa deve exibir
ftp.Deve haver uma contagem de quadros válida (
Frm count) nos fluxos de controle.Uma contagem de quadros válida nos fluxos de dados indica que a transferência de dados ocorreu.
O que preciso verificar se a conexão FTP foi estabelecida, mas a transferência de dados não ocorre?
Muito provavelmente, a conexão de controle está ativa, mas a conexão de dados está inativa.
Verifique a saída de conversas para determinar se os fluxos de controle e dados estão presentes.
Como interpreto cada fluxo? O que significa cada fluxo?
Fluxo do iniciador de fluxo de controle de FTP — Fluxo com a porta de destino 21
Fluxo do respondente de fluxo de controle de FTP — Fluxo com porta de origem; 21
Fluxo do iniciador de fluxo de dados FTP — Fluxo com a porta de destino 20
Fluxo de resposta de fluxo de dados FTP — fluxo com a porta de origem 20
Exemplo de RTSP ALG
Veja a seguir um exemplo de uma conversa RTSP. O aplicativo usa o protocolo RTSP para conexão de controle. Depois que a conexão é configurada, a mídia é enviada usando o protocolo UDP (RTP).
Este exemplo consiste no seguinte:
- Saída de amostra para MS-MPCs
- Saída de amostra para placa de serviços MX-SPC3
- Análise
- Perguntas sobre solução de problemas
Saída de amostra para MS-MPCs
Aqui está a saída do show services stateful-firewall conversations comando de modo operacional:
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
Saída de amostra para placa de serviços MX-SPC3
Aqui está a saída do show services sessions application-protocol rtsp comando de modo operacional:
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álise
Uma conversação RTSP deve consistir em fluxos TCP correspondentes à conexão de controle RTSP. Deve haver dois fluxos, um em cada direção, do cliente para o servidor e do servidor para o 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
A conexão de controle RTSP para o fluxo do iniciador é enviada da porta de destino 554.
A conexão de controle RTSP para o fluxo do respondente é enviada da porta de origem 554.
Os fluxos UDP correspondem à mídia RTP enviada pela conexão RTSP.
Perguntas sobre solução de problemas
A mídia não funciona quando o RTSP ALG está configurado. O que fazer?
Verifique as conversas RTSP para ver se existem fluxos TCP e UDP.
O protocolo ALG deve ser exibido como
rtsp.
Observação:O estado do fluxo é exibido como
Watch, porque o processamento ALG está ocorrendo e o cliente está essencialmente "observando" ou processando a carga correspondente ao aplicativo. Para fluxos ALG de FTP e RTSP, as conexões de controle são sempreWatchfluxos.Como verifico erros de ALG?
Você pode verificar se há erros emitindo o comando a seguir. Cada ALG tem um campo separado para erros de pacote 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
Mensagens de log do sistema
Habilitar a geração de log do sistema e verificar o log do sistema também são úteis para a análise de fluxo ALG. Esta seção contém o seguinte:
Configuração de log do sistema
Você pode configurar a habilitação de mensagens de log do sistema em vários níveis diferentes na CLI do Junos OS. Conforme mostrado nas configurações de exemplo a seguir, a escolha do nível depende de quão específico você deseja que o log de eventos seja e quais opções você deseja incluir. Para obter detalhes sobre as opções de configuração, consulte a Biblioteca de administração do Junos OS para dispositivos de roteamento (nível do sistema) ou a Biblioteca de interfaces de serviços do Junos OS para dispositivos de roteamento (todos os outros níveis).
No nível global mais alto:
user@host# show system syslog file messages { any any; }No nível do conjunto de serviços:
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; }No nível da regra de serviço:
user@host# show services stateful-firewall rule allow_rtsp match-direction input-output; term 0 { from { applications junos-rtsp; } then { accept; syslog; } }
Saída de log do sistema
As mensagens de log do sistema são geradas durante a criação do fluxo, conforme mostrado nos exemplos a seguir:
A seguinte mensagem de log do sistema indica que o ASP correspondeu a uma regra de aceitação:
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 obter uma lista completa das mensagens de log do sistema, consulte o Explorador de Logs do Sistema.