Visão geral da GGSN
O nó de suporte para GPRS de gateway (GGSN) converte o tráfego de dados de entrada vindo dos usuários móveis através do nó de suporte gprs de gateway de serviço (SGSN) e o encaminha para a rede relevante, e vice-versa. O GGSN e o SGSN juntos formam os nós de suporte para GPRS (GSN).
Entender o redirecionamento da GGSN
O Junos OS oferece suporte ao tráfego de protocolo de tunelamento GPRS (GTP) e ao redirecionamento do nó de suporte GPRS (GGSN). Um GGSN (X) pode enviar respostas de contexto create-pdp nas quais pode especificar diferentes endereços IP GGSN (GGSN Y e GGSN Z) para mensagens GTP-C e GTP-U subseqüentes. Consequentemente, a SGSN envia as seguintes mensagens de protocolo de tunelamento GGSN, controle (GTP-C) e protocolo de tunelamento GGSN, plano de usuário (GTP-U) para GGSNs Y e Z, em vez de X.
Visão geral dos cenários de agrupamento da GGSN
O protocolo de tunelamento (GTP) general Packet Radio Service (GPRS) oferece suporte a diferentes endereços IP de nó de suporte de GPRS de gateway (GGSN) durante um procedimento de criação de túnel. Existem dois cenários de agrupamento GGSN que oferecem suporte ao roaming de nó de suporte para GPRS (SGSN).
Entender o agrupamento de GGSN para o cenário 1
Na Figura 1, uma solicitação de contexto de protocolo de dados de pacotes (PDP) é enviada da SGSN A para GGSN B durante um procedimento de criação de túnel GTP. Após o envio da mensagem de solicitação de contexto PDP, a GGSN D registra as informações de solicitação e usa um endereço IP de destino diferente do endereço IP de destino do pacote de solicitação para enviar a mensagem de resposta ao SGSN A.
Nesse cenário, duas mensagens de pacote GTP são enviadas para a Unidade de Processamento de Serviços 1 (SPU1) e SPU2 pelo ponto central, e as mensagens são processadas individualmente por SPU1 e SPU2. A sessão é criada em SPU1 e SPU 2 para cada pacote GTP. O SPU1 registra as informações do pacote de solicitação e o SPU2 registra as informações do pacote de resposta.
A mensagem de resposta pdp enviada da GGSN D para SGSN A é retirada devido à falta de informações de solicitação. Assim, o túnel GTP não está estabelecido.

O SPU2 não pode recuperar informações de solicitação do SPU1.
Instale informações de solicitação à SPU remota
Nesse cenário, o pacote de resposta a PDP foi descartado por falta de informações de solicitação, e o túnel GTP não foi estabelecido. Isso pode ser resolvido instalando as informações de solicitação sobre a SPU correta.
Na Figura 2, ao criar um túnel, o endereço IP GGSN do pacote de resposta muda, desencadeando uma nova sessão e o ponto central distribui a mensagem para outra SPU.
O pacote de resposta sempre envia para o endereço de origem do pacote de solicitação para a SPU. Isso ajuda a instalar as informações de solicitação na SPU remota para o próximo pacote de resposta.
Instale as informações de solicitação na previsível função SPU, HASH (req-src-ip) enquanto processa o pacote de solicitação. Após o número de SPU esperado (Hash (10.1.1.1) = SPU2) ser calculado pelo endereço IP de origem da mensagem de solicitação de PDP, as informações de solicitação são instaladas no SPU2 remoto por meio da Interface de Passagem de Mensagens (JMPI) da Juniper.

Agora, as informações de solicitação são instaladas no SPU1 local e no SPU2 remoto, para que a mensagem de resposta do PDP seja permitida.
Soluções alternativas para o Cenário 1
No cenário 1, a mensagem de solicitação de contexto PDP enviada da SGSN A chegou ao aplicativo junos-gprs-gtp
padrão Junos OS e a inspeção GTP foi habilitada para mensagem de solicitação de contexto PDP. No entanto, a mensagem de resposta ao contexto PDP enviada pelo GGSN D não pode chegar ao aplicativo junos-gprs-gtp
padrão Junos OS. Assim, o pacote não será inspecionado pelo módulo GTP.
Como uma solução alternativa, você precisa habilitar a inspeção de GTP para a mensagem de resposta ao contexto PDP, configurando a política e os aplicativos personalizados. Consulte a configuração de uma política/aplicativo personalizada do GGSN.
Entender o agrupamento de GGSN para o cenário 2
Na Figura 3, uma solicitação de contexto de protocolo de dados de pacotes (PDP) é enviada da SGSN A para GGSN B durante um procedimento de criação de túnel GTP. Após receber a mensagem de solicitação de contexto PDP, a GGSN B envia a mensagem de resposta ao contexto PDP para a SGSN A. Após receber a mensagem de resposta ao contexto PDP, o túnel GTP-C é criado entre SGSN C e GGSN D. Em seguida, a SGSN C envia uma mensagem de solicitação de contexto PDP atualizada para GGSN D usando diferentes endereços IP de origem e destino a partir do cabeçalho IP do pacote de solicitação.
No cenário 2, o SGSN A cria a primeira solicitação de contexto GTP e a envia à SPU pelo ponto central. A sessão é criada para o pacote de solicitação no SPU1. O pacote de resposta enviado de GGSN B para SGSN A chega à sessão corretamente.
O pacote de solicitação enviado pelo SGSN A indica que o GTP-C está estabelecido no CONTROLE IP 10.1.1.2 e o GTP-U está estabelecido nos dados IP 10.1.1.3. Da mesma forma, a mensagem de resposta enviada pelo GGSN indica que o GTP-C está estabelecido no controle do IP 10.2.2.3 e o GTP-U está estabelecido nos dados IP 10.2.2.4.
Os túneis GTP-C e GTP-U são criados no SPU1 local após todos os endpoints serem estabelecidos. No entanto, o túnel não está estabelecido na SPU 2, de modo que a mensagem de solicitação de atualização de PDP recebida da SPU2 é retirada.

Instale informações de túnel na SPU remota
No cenário 2, o pacote de solicitação de atualização é descartado devido à falta de informações de túnel. Isso pode ser resolvido instalando as informações do túnel na SPU correta após o processamento da solicitação e dos pacotes de resposta. A SPU que recebe o pacote de resposta instala as informações do túnel na SPU local ou remota.
Na Figura 4, após a criação do túnel, as mensagens de controle são enviadas para o endpoint do túnel de controle. O endereço IP de destino de todas as mensagens de controle deve ser o endereço IP de endpoint GGSN do túnel de controle. Isso ajuda a calcular o número de SPU remoto com antecedência para a mensagem de controle subseqüente.
Instale as informações do túnel na SPU previsível. Após o número de SPU ser calculado pelo IP de endpoint GGSN do túnel de controle, as informações do túnel são instaladas na SPU remota por meio do JMPI.

Agora, as informações do túnel são instaladas no SPU2 remoto, para que a mensagem de resposta de atualização do PDP seja permitida.
Exemplo: configurar uma política e aplicativo personalizados do GGSN
Este exemplo mostra como configurar uma política e aplicativo personalizados de nó de suporte para GPRS de gateway (GGSN) para oferecer suporte ao cenário de agrupamento GGSN 1.
Requisitos
Este exemplo usa os seguintes componentes de hardware e software:
Dispositivo SRX5400
Um PC
Versão do Junos OS 12.1X44-D10
Configuração
Configuração de uma política personalizada de GGSN
Visão geral
Este exemplo mostra como configurar políticas de segurança para o tráfego GTP, o que fará o tráfego funcionar caso o agrupamento GTP ocorra. Esse mesmo exemplo também fará o tráfego GTP fluir corretamente quando o recurso de distribuição GTP estiver habilitado, com ou sem inspeção de GTP. O que fazemos aqui é configurar as políticas de segurança em ambas as direções, espelhadas. Em ambas as direções, usamos os mesmos objetos de endereço e os mesmos aplicativos. Além do aplicativo GTP regular junos-gprs-gtp, criamos um aplicativo GTP reverso personalizado, chamado reverso junos-gprs-gtp. Este aplicativo GTP reverso fará com que os pacotes GTP correspondam à política de segurança, mesmo quando apenas a porta UDP de origem for uma porta GTP bem conhecida. Dessa forma, todo o tráfego GTP será compatível com as políticas e tratado corretamente como tráfego GTP.
Configuração rápida da CLI
Para configurar rapidamente este exemplo, copie os seguintes comandos, cole-os em um arquivo de texto, remova quaisquer quebras de linha, altere todos os detalhes necessários para combinar com sua configuração de rede, copiar e colar os comandos na CLI no nível de [edit]
hierarquia e, em seguida, entrar no commit modo de configuração.
Caso o recurso GTP Distribution seja usado sem a inspeção do GTP, não crie o perfil GTP e não aplique o perfil gtp de serviços de aplicativo às políticas de segurança.
set security address-book global address local_GSN_range 10.1.1.0/24 set security address-book global address remote_GSN_range 10.2.2.0/24 set security gtp profile GTP-Profile set security policies from-zone trust to-zone untrust policy t-u match source-address local_GSN_range set security policies from-zone trust to-zone untrust policy t-u match destination-address remote_GSN_range set security policies from-zone trust to-zone untrust policy t-u match application junos-gprs-gtp set security policies from-zone trust to-zone untrust policy t-u match application reverse-junos-gprs-gtp set security policies from-zone trust to-zone untrust policy t-u then permit application-services gtp-profile GTP-Profile set security policies from-zone untrust to-zone trust policy u-t match source-address remote_GSN_range set security policies from-zone untrust to-zone trust policy u-t match destination-address local_GSN_range set security policies from-zone untrust to-zone trust policy u-t match application reverse-junos-gprs-gtp set security policies from-zone untrust to-zone trust policy u-t match application junos-gprs-gtp set security policies from-zone untrust to-zone trust policy u-t then permit application-services gtp-profile GTP-Profile
Procedimento passo a passo
Para configurar uma política personalizada de GGSN:
Configure o endereço de origem.
[edit security] user@host# set security policies from-zone trust to-zone untrust policy t-u match source-address local_GSN_range
Configure o endereço de destino.
[edit security] user@host# set security policies from-zone trust to-zone untrust policy t-u match destination-address remote_GSN_range
Configure os aplicativos de política.
[edit security] user@host#set security policies from-zone trust to-zone untrust policy t-u match application junos-gprs-gtp user@host#set security policies from-zone trust to-zone untrust policy t-u match application reverse-junos-gprs-gtp
-
Configure o tipo de atividade e especifique o nome do perfil GTP.
[edit security]user@host# set security policies from-zone trust to-zone untrust policy t-u then permit application-services gtp-profile GTP-Profile
Caso o recurso de distribuição GTP seja usado sem a inspeção do GTP:
[edit security] user@host# set security policies from-zone trust to-zone untrust policy t-u then permit
-
Configure o mesmo novamente, com as zonas de segurança confiáveis e invertidas não confiáveis.
Resultados
A partir do modo de configuração, confirme sua configuração entrando no show security policies
comando. Se a saída não exibir a configuração pretendida, repita as instruções de configuração neste exemplo para corrigi-la.
[edit] user@host# show security policies from-zone trust to-zone untrust { policy t-u { match { source-address local_GSN_range; destination-address remote_GSN_range; application [ junos-gprs-gtp reverse-junos-gprs-gtp ]; } then { permit { application-services { gtp-profile GTP-Profile; } } } } } from-zone untrust to-zone trust { policy u-t { match { source-address remote_GSN_range; destination-address local_GSN_range; application [ reverse-junos-gprs-gtp junos-gprs-gtp ]; } then { permit { application-services { gtp-profile GTP-Profile; } } } } }
Antes de confirmarmos a configuração, precisamos configurar o aplicativo GTP reverso.
Configuração de aplicativo GTP reverso
Ao usar o recurso GTP Distribution , as sessões de fluxo serão definidas como unidirecionais. Essa ação para defini-los como unidirecionais é realizada pelo GTP ALG (mesmo quando não usa o GTP Inspection). Por isso, é necessário que o GTP ALG seja aplicado a todo o tráfego GTP.
O aplicativo predefinido junos-gprs-gtp está configurado com o GTP ALG. No entanto, em alguns casos, o tráfego GTP pode não coincidir com este aplicativo, o que será o caso do tráfego de devolução quando uma porta de origem diferente foi usada do que as portas GTP UDP padrão. Nesse caso, a asa de sessão reversa pode ter uma porta de destino aleatória e a porta GTP padrão como porta de origem. Para garantir que o GTP ALG seja aplicado a esse tráfego GTP reverso neste caso, é necessário adicionar o seguinte aplicativo GTP 'reverso' a todas as políticas de segurança GTP.
Configuração rápida da CLI
Para configurar rapidamente este exemplo, copie os seguintes comandos, cole-os em um arquivo de texto, remova quaisquer quebras de linha, altere todos os detalhes necessários para combinar com sua configuração de rede, copiar e colar os comandos na CLI no nível de [edit]
hierarquia e, em seguida, entrar no commit modo de configuração.
set applications application reverse-junos-gprs-gtp-c term t1 alg gprs-gtp-c set applications application reverse-junos-gprs-gtp-c term t1 protocol udp set applications application reverse-junos-gprs-gtp-c term t1 source-port 2123 set applications application reverse-junos-gprs-gtp-c term t1 destination-port 0-65535 set applications application reverse-junos-gprs-gtp-u term t1 alg gprs-gtp-u set applications application reverse-junos-gprs-gtp-u term t1 protocol udp set applications application reverse-junos-gprs-gtp-u term t1 source-port 2152 set applications application reverse-junos-gprs-gtp-u term t1 destination-port 0-65535 set applications application reverse-junos-gprs-gtp-v0 term t1 alg gprs-gtp-v0 set applications application reverse-junos-gprs-gtp-v0 term t1 protocol udp set applications application reverse-junos-gprs-gtp-v0 term t1 source-port 3386 set applications application reverse-junos-gprs-gtp-v0 term t1 destination-port 0-65535 set applications application-set reverse-junos-gprs-gtp application reverse-junos-gprs-gtp-c set applications application-set reverse-junos-gprs-gtp application reverse-junos-gprs-gtp-u set applications application-set reverse-junos-gprs-gtp application reverse-junos-gprs-gtp-v0
Verificação
Confirme que a configuração está funcionando corretamente.
Verificando a configuração
Propósito
Verifique se a configuração de política personalizada do GGSN está correta.
Ação
Comprometa a configuração e a saída. Do modo operacional, entre no show security policies
comando.
Saída de amostra
nome de comando
[edit] user@host# show applications application reverse-junos-gprs-gtp-c { term t1 alg gprs-gtp-c protocol udp source-port 2123 destination-port 0-65535; } application reverse-junos-gprs-gtp-u { term t1 alg gprs-gtp-u protocol udp source-port 2152 destination-port 0-65535; } application reverse-junos-gprs-gtp-v0 { term t1 alg gprs-gtp-v0 protocol udp source-port 3386 destination-port 0-65535; } application-set reverse-junos-gprs-gtp { application reverse-junos-gprs-gtp-c; application reverse-junos-gprs-gtp-u; application reverse-junos-gprs-gtp-v0; } [edit] user@host# commit and-quit commit complete Exiting configuration mode user@host> show security policies Default policy: deny-all Default policy log Profile ID: 0 Pre ID default policy: permit-all From zone: trust, To zone: untrust Policy: t-u, State: enabled, Index: 6, Scope Policy: 0, Sequence number: 1, Log Profile ID: 0 Source vrf group: any Destination vrf group: any Source addresses: local_GSN_range Destination addresses: remote_GSN_range Applications: junos-gprs-gtp, reverse-junos-gprs-gtp Source identity feeds: any Destination identity feeds: any Action: permit, application services From zone: untrust, To zone: trust Policy: u-t, State: enabled, Index: 7, Scope Policy: 0, Sequence number: 1, Log Profile ID: 0 Source vrf group: any Destination vrf group: any Source addresses: remote_GSN_range Destination addresses: local_GSN_range Applications: reverse-junos-gprs-gtp, junos-gprs-gtp Source identity feeds: any Destination identity feeds: any Action: permit, application services
Esta saída mostra um resumo da configuração da política.