Autenticação

A Biblioteca > Página de autenticação permite configurar servidores de autenticação e criar regras de autenticação com opções para o lado do cliente Basic ou Formulários e NTLM ou BASIC do lado do servidor.

Configurando a Autenticação - Um Fluxo de Trabalho

Por favor, execute as seguintes etapas como um mínimo para aplicar a Autenticação ao seu serviço.

1. Criar um Servidor de Autenticação.

2. Criar uma Regra de Autenticação que utilize um Servidor de Autenticação.

3. Criar uma regra flightPATH que utilize uma regra de autenticação.

4. Aplicar a regra flightPATH a um serviço

Servidores de Autenticação

Para configurar um método de autenticação funcional, é necessário primeiro configurar um servidor de autenticação.

· Clique no botão Adicionar Servidor.

· Esta ação produzirá uma linha em branco pronta para ser concluída.

Opção	Descrição
Nome	Dê a seu servidor um nome para fins de identificação - este nome é usado nas regras
Descrição	Acrescentar uma descrição
Método de autenticação	Escolha um método de autenticação LDAP - LDAP básico com nomes de usuário e senhas enviadas em texto claro para o servidor LDAP. LDAP-MD5 - LDAP básico com nome de usuário em texto claro e senha MD5 hashed para maior segurança. LDAPS - LDAP sobre SSL. Envia a senha em texto claro dentro de um túnel criptografado entre o ADC e o servidor LDAP. LDAPS-MD5 - LDAP sobre SSL. A senha é MD5 hashed para maior segurança dentro de um túnel criptografado entre o ADC e o servidor LDAP.
Domínio	Adicionar no nome de domínio para o servidor LDAP.
Endereço do servidor	Adicionar o endereço IP ou hostname do servidor de autenticação LDAP - endereço IPv4 ou hostname. LDAP-MD5 - somente nome do host (endereço IPv4 não funcionará) LDAPS - endereço IPv4 ou hostname. LDAPS-MD5 - somente hostname (endereço IPv4 não funcionará).
Porto	Use a porta 389 para LDAP e a porta 636 para LDAPS por padrão. Não é necessário adicionar o número da porta para LDAP e LDAPS. Quando outros métodos estiverem disponíveis, você será capaz de configurá-los aqui
Condições de busca	As condições de busca devem estar em conformidade com a RFC 4515. Exemplo: (MemberOf=CN=Phone- VPN,CN=Users,DC=mycompany,DC=local).
Base de busca	Este valor é o ponto de partida para a busca no banco de dados do LDAP. Exemplo dc=empresa microscópica,dc=local
Formato de Login	Use o formato de login que você precisa. Nome de usuário - com este formato escolhido, você só precisa digitar o nome de usuário. Qualquer informação de usuário e domínio introduzida pelo usuário é excluída, e as informações de domínio do servidor são utilizadas. Nome de usuário e domínio - O usuário deve digitar todo o domínio e a sintaxe do nome de usuário. Exemplo: mycompany\gchristie\gchristie OU alguém@mycompany. As informações de domínio digitadas no nível do servidor são ignoradas. Em branco - o ADC aceitará tudo o que o usuário inserir e o enviará para o servidor de autenticação. Esta opção é utilizada quando se utiliza MD5.
Frase de passagem	Esta opção não é utilizada nesta versão.
Tempo morto	Não utilizado nesta versão

Regras de Autenticação

A próxima etapa é criar as regras de autenticação para uso com a definição do servidor.

Campo	Descrição
Nome	Adicione um nome adequado para sua regra de autenticação.
Descrição	Adicione uma descrição adequada.
Domínio Raiz	Isto deve ser deixado em branco, a menos que você precise de um único sinal em todos os sub-domínios.
Servidor de Autenticação	Esta é uma caixa drop-down contendo servidores que você configurou.
Autenticação do cliente:	Escolha o valor adequado às suas necessidades: Básico (401) - Este método usa o método de autenticação padrão 401 Formulários - isto apresentará ao usuário o formulário padrão do ADC. Dentro do formulário, você pode adicionar uma mensagem. Você pode selecionar um formulário que você tenha carregado usando a seção abaixo.
Autenticação do servidor	Escolha o valor apropriado. Nenhuma - se seu servidor não tiver nenhuma autenticação existente, selecione esta configuração. Esta configuração significa que você pode adicionar habilidades de autenticação a um servidor que anteriormente não possuía nenhuma. Básico - se seu servidor tem autenticação básica (401) habilitada, então selecione BASIC. NTLM - se seu servidor tem a autenticação NTLM habilitada, então selecione NTLM.
Formulário	Escolha o valor apropriado Padrão - A seleção desta opção resultará no ADC usando sua forma integrada. Personalizado - você pode adicionar um formulário que você projetou e selecioná-lo aqui.
Mensagem	Acrescente uma mensagem pessoal ao formulário.
Desconto de tempo	Adicione um timeout à regra, após o qual o usuário será obrigado a se autenticar novamente. Observe que a definição de timeout só é válida para autenticação baseada em Formulários.

Assinatura única

Se você deseja fornecer um único login para os usuários, complete a coluna Domínio Raiz com seu domínio. Neste exemplo, usamos edgenexus.io. Agora podemos ter vários serviços que utilizarão edgenexus.io como domínio raiz, e você só terá que se logar uma vez. Se considerarmos os seguintes serviços:

· Sharepoint.mycompany.com

· usercentral. mycompany.com

· appstore. mycompany.com

Estes serviços podem residir em um VIP ou podem ser distribuídos entre 3 VIPs. Um usuário acessando o site usercentral. mycompany.com pela primeira vez receberá um formulário solicitando que faça o login, dependendo da regra de autenticação utilizada. O mesmo usuário pode então conectar-se à appstore. mycompany.com e será autenticado automaticamente pelo ADC. Você pode definir o tempo limite, o que forçará a autenticação uma vez que este período de inatividade tenha sido alcançado.

Formulários

Esta seção permitirá que você faça o upload de um formulário personalizado.

Como criar seu formulário personalizado

Embora a forma básica que o ADC fornece seja suficiente para a maioria das finalidades, haverá ocasiões em que as empresas desejarão apresentar sua própria identidade ao usuário. Você pode criar seu formulário personalizado que será apresentado aos usuários para preencher em tais casos. Este formulário deve estar no formato HTM ou HTML.

Opção	Descrição
Nome	nome do formulário = formulário de login ação = %JNURL% Método = POST
Nome de usuário	Sintaxe: nome = "JNUSER".
Senha:	name="JNPASS"
Mensagem Opcional1:	%JNMESSAGE%
Mensagem Opcional2:	%JNAUTHMESSAGE%
Imagens	Se você deseja adicionar uma imagem, por favor, adicione-a em linha usando a codificação Base64.

Exemplo de código html de uma forma muito básica e simples

<HTML>

<CABEÇA>

<TÍTULO>FORMULÁRIO DE AMOSTRA</TÍTULO>

</HEAD>

<CORPO>

%JNMESSAGE%<br>

<form name="loginform" action="%JNURL%" method="post"> USUÁRIO: <input type="text" name="JNUSER" size="20" value=""></br>

PASS: <input type="password" name="JNPASS" size="20" value=""></br>

</form>

</BORBINÁRIO>

</HTML>

Adicionando um formulário personalizado

Uma vez criado um formulário personalizado, você pode adicioná-lo usando a seção Formulários.

1. Escolha um nome para seu formulário

2. Navegue localmente para seu formulário

3. Clique em Upload

Pré-visualização de seu formulário personalizado

Para visualizar o formulário personalizado que você acabou de carregar, você o seleciona e clica em Pré-visualizar. Você também pode usar esta seção para excluir os formulários que não são mais necessários.

Cache

O ADC é capaz de armazenar dados em cache dentro de sua memória interna e periodicamente descarrega este Cache para o armazenamento interno do ADC. As configurações que gerenciam esta funcionalidade são fornecidas dentro desta seção.

Configurações de Cache Global

Tamanho Máximo do Cache (MB)

Este valor determina o máximo de RAM que o Cache pode consumir. O Cache ADC é um cache in-memory que também é periodicamente lavado no meio de armazenamento para manter a persistência do cache após reinicializações, reinicializações e operações de desligamento. Esta funcionalidade significa que o tamanho máximo do cache deve caber dentro da área de memória do aparelho (em vez de espaço em disco) e não deve ser mais da metade da memória disponível.

Tamanho desejado do Cache (MB)

Este valor denota a RAM ótima para a qual o Cache será aparado. Enquanto o tamanho máximo de cache representa o limite superior absoluto do Cache, o tamanho de cache desejado é pretendido como o tamanho ideal que o Cache deve tentar atingir sempre que for feita uma verificação automática ou manual do tamanho do cache. A lacuna entre o tamanho máximo e o tamanho desejado do cache existe para acomodar a chegada e a sobreposição de novo conteúdo entre as verificações periódicas do tamanho do cache para aparar o conteúdo expirado. Mais uma vez, pode ser mais eficaz aceitar o valor padrão (30 MB) e revisar periodicamente o tamanho do Cache em "Monitor -> Estatísticas" para o dimensionamento apropriado.

Tempo de Cache padrão (D/HH:MM)

O valor aqui inserido representa a vida útil do conteúdo sem um valor de expiração explícito. O tempo de armazenamento padrão é o período durante o qual o conteúdo sem uma diretiva "sem loja" ou tempo de expiração explícita no cabeçalho do tráfego é armazenado.

A entrada de campo toma a forma "D/HH:MM" - assim, uma entrada de "1/01:01" (padrão é 1/00:00) significa que o ADC guardará o conteúdo por um dia, "01:00" por uma hora, e "00:01" por um minuto.

Códigos de resposta HTTP em cache

Um dos conjuntos de dados em cache são as respostas HTTP. Os códigos das respostas HTTP que estão em cache são:

· 200 - Resposta padrão para solicitações HTTP bem sucedidas

· 203 - Os cabeçalhos não são definitivos, mas são coletados a partir de uma cópia local ou de uma cópia de terceiros

· 301 - O recurso solicitado foi atribuído a um novo URL permanente

· 304 - Não modificado desde a última solicitação e cópia em cache local deve ser utilizado em seu lugar

· 410 - O recurso não está mais disponível no servidor, e nenhum endereço de encaminhamento é conhecido

Este campo deve ser editado com cautela, pois os códigos de resposta em cache mais comuns já estão listados.

Tempo de Verificação de Cache (D/HH:MM)

Esta configuração determina o intervalo de tempo entre as operações de acabamento do cache.

Contagem de Cache-Fill

Esta configuração é uma instalação de ajuda para ajudar a preencher o Cache quando um certo número de 304's tiver sido detectado.

Aplicar a regra de Cache

Esta seção permite que você aplique uma regra de cache a um domínio:

· Adicionar domínio manualmente com o botão Adicionar Registros. Você deve usar um nome de domínio totalmente qualificado ou um endereço IP em notação ponto-decimal. Exemplo www. mycompany.com ou 192.168.3.1:80

· Clique na seta suspensa e escolha seu domínio a partir da lista

· A lista será preenchida desde que o tráfego tenha passado por um serviço virtual e que uma estratégia de cache tenha sido aplicada ao serviço virtual

· Escolha sua regra de cache clicando duas vezes na coluna Caching Rulebase e selecionando da lista

Criar Regra de Cache

Esta seção permite criar várias regras de cache diferentes que podem então ser aplicadas a um domínio:

· Clique em Adicionar Registros e dê um nome e descrição à sua regra

· Você pode digitar suas condições manualmente ou usar a Condição Adicional

Para adicionar uma condição usando a base de regras de seleção:

· Escolha Incluir ou Excluir

· Escolha todas as imagens JPEG

· Clique no símbolo + Adicionar

· Você verá que 'incluir *.jpg' foi agora adicionado às condições

· Você pode acrescentar mais condições. Se você optar por fazer isto manualmente, você precisa adicionar cada condição em uma NOVO linha. Observe que suas regras serão exibidas na mesma linha até que você clique na caixa Condições, então elas serão exibidas em uma linha separada

flightPATH

flightPATH é a tecnologia de gerenciamento de tráfego incorporada no ADC. flightPATH permite inspecionar o tráfego HTTP e HTTPS em tempo real e realizar ações baseadas em condições.

As regras do flightPATH devem ser aplicadas a um VIP quando objetos IP são utilizados dentro das regras.

Uma regra de percurso de vôo consiste em quatro elementos:

1. Detalhes, onde você define o nome do FlightPATH e o serviço ao qual ele está anexado.

2. Condição(ões) que pode(m) ser definida(s) e que provoca(m) o acionamento da regra.

3. Avaliação que permite a definição de variáveis que podem ser utilizadas dentro de Ações

4. Ações que são usadas para administrar o que deve acontecer quando as condições são cumpridas

Detalhes

A seção de detalhes mostra as regras de flightPATH disponíveis. Você pode adicionar novas regras flightPATH e remover as regras definidas desta seção.

Adicionando uma nova regra de vooPATH

Campo	Descrição
Nome do FlightPATH	Este campo é para o nome da regra flightPATH. O nome que você fornece aqui aparece e é referenciado dentro de outras partes do ADC.
Aplicado à VS	Esta coluna é somente de leitura e mostra o VIP ao qual a regra flightPATH é aplicada.
Descrição	Valor que representa uma descrição fornecida para fins de legibilidade.

Etapas para acrescentar uma regra de vooPATH

1. Primeiro, clique no botão Adicionar novo, localizado na seção Detalhes.

2. Digite um nome para sua regra. Exemplo Auth2

3. Digite uma descrição de sua regra

4. Uma vez que a regra tenha sido aplicada a um serviço, você verá a coluna Aplicada à autopopulação com um endereço IP e valor de porta

5. Não se esqueça de pressionar o botão Atualizar para salvar suas alterações ou, se você cometer um erro, basta pressionar cancelar e voltar ao estado anterior.

Condição

A regra flightPATH pode ter qualquer número de condições. As condições funcionam com base no "AND", permitindo estabelecer a condição na qual a ação é acionada. Se você quiser usar uma condição OR, crie uma regra flightPATH adicional e a aplique ao VIP na ordem correta.

Você também pode usar RegEx selecionando Match RegEx no campo Check e o valor RegEx no campo Value. A inclusão da avaliação do RegEx amplia tremendamente a capacidade do flightPATH.

Criando uma nova condição de vooPATH

Condição

Fornecemos várias Condições como pré-definidas dentro do drop-down e cobrimos todos os cenários previstos. Quando novas Condições são adicionadas, estas estarão disponíveis através de atualizações Jetpack.

As opções disponíveis são:

CONDIÇÃO	DESCRIÇÃO	EXEMPLO
<form>	Os formulários HTML são usados para passar dados para um servidor	Exemplo "o formulário não tem comprimento 0".
Localização GEO	Compara o endereço IP de origem com os Códigos de Países ISO 3166	GEO Location faz igual a GB, OU GEO Location faz igual à Alemanha
Anfitrião	Host extraído da URL	www.mywebsite.com ou 192.168.1.1
Idioma	Idioma extraído do cabeçalho HTTP do idioma	Esta condição produzirá uma queda com uma lista de idiomas
Método	Drop-down dos métodos HTTP	Drop-down que inclui GET, POST, etc.
Origem IP	Se o upstream proxy suporta X-Forwarded-for (XFF), ele usará o verdadeiro endereço de origem	IP do cliente. Também pode utilizar múltiplos IPs ou sub-redes. 10.1.2.* é 10.1.2.0 /24 subnet10 10. 1.2.3\|10.1.2.4 Utilização \| para múltiplos IP's
Caminho	Caminho do site	/mywebsite/index.asp
POST	Método de solicitação POST	Verificar os dados que estão sendo carregados em um site
Consulta	Nome e valor de uma consulta, e pode aceitar o nome da consulta ou um valor também	"Best=jetNEXUS" Onde a partida é melhor e o valor é edgeNEXUS
Consulta String	Toda a cadeia de consulta após o caractere ?
Solicite um Cookie	Nome de um cookie solicitado por um cliente	MS-WSMAN=afYfn1CDqqCDqUD::
Cabeçalho de solicitação	Qualquer cabeçalho HTTP	Referidor, Usuário-Agente, De, Data
Versão de solicitação	A versão HTTP	HTTP/1.0 OU HTTP/1.1
Corpo de resposta	Uma cadeia definida pelo usuário no corpo de resposta	Servidor UP
Código de resposta	O código HTTP para a resposta	200 OK, 304 Não modificado
Cookie de resposta	O nome de um cookie enviado pelo servidor	MS-WSMAN=afYfn1CDqqCDqUD::
Cabeçalho de resposta	Qualquer cabeçalho HTTP	Referidor, Usuário-Agente, De, Data
Versão de resposta	A versão HTTP enviada pelo servidor	HTTP/1.0 OU HTTP/1.1
Fonte IP	Seja o IP de origem, IP do servidor proxy, ou algum outro endereço IP agregado	ClientIP , Proxy IP, Firewall IP. Também pode utilizar múltiplos IP e sub-redes. Você deve escapar dos pontos, pois estes são RegEX. Exemplo 10\.1\.2\.3 é 10.1.2.3

Combinar

O campo de partida pode ser um valor drop-down ou um valor de texto e pode ser definido dependendo do valor no campo Condição. Por exemplo, se a Condição for definida como Anfitrião, o campo Correspondência não está disponível. Se a Condição for definida como <form>, o campo Correspondência é mostrado como um campo de texto, e se a Condição for POST, o campo Correspondência é apresentado como um drop-down contendo os valores pertinentes.

As opções disponíveis são:

MATCH	DESCRIÇÃO	EXEMPLO
Aceitar	Tipos de conteúdo que são aceitáveis	Aceitar: texto/plainar
Aceitar-Codificação	Codificações aceitáveis	Aceitar-Codificação: <comprimir \| gzip \| esvaziar \| sdch \| identidade>
Aceitar-Língua	Idiomas aceitáveis para resposta	Aceitar-Língua: pt-US
Aceito-Alterações	Que tipo de conteúdo parcial este servidor suporta	Intervalos de aceitação: bytes
Autorização	Credenciais de autenticação para autenticação HTTP	Autorização: Básico QWxhZGRpbjpvcGVuIHNlc2FtZQ=====
Carga-To	Contém informações de conta para os custos da aplicação do método solicitado
Codificação de conteúdo	O tipo de codificação utilizada	Codificação do conteúdo: gzip
Comprimento do conteúdo	O comprimento do corpo de resposta em Octets (bytes de 8 bits)	Comprimento do conteúdo: 348
Tipo de conteúdo	O tipo de mímica do corpo do pedido (usado com pedidos POST e PUT)	Tipo de conteúdo: aplicação/x-www-form-urlencoded
Cookie	Um cookie HTTP previamente enviado pelo servidor com Set-Cookie (abaixo)	Cookie: $Version=1; Skin=new;
Data	Data e hora em que a mensagem foi originada	Data = "Data" ":" HTTP-date
ETag	Um identificador para uma versão específica de um recurso, muitas vezes uma digestão de mensagem	ETag: "aed6bdb8e090cd1:0"
De	O endereço de e-mail do usuário que faz o pedido	De: user@example.com
Se-Modificado - desde	Permite que um 304 Não modificado seja devolvido se o conteúdo não for alterado	Se-Modificado - Desde: Sábado, 29 de outubro de 1994 19:43:31 GMT
Última Modificação	A última data modificada para o objeto solicitado, no formato RFC 2822	Modificado por último: Ter, 15 Nov 1994 12:45:26 GMT
Pragma	Implementação: Cabeçalhos específicos que podem ter vários efeitos em qualquer lugar ao longo da cadeia de resposta ao pedido.	Pragma: sem cache
Referência	Endereço da página web anterior a partir do qual um link para a página atualmente solicitada foi seguido	Referência: HTTP://www.edgenexus.io
Servidor	Um nome para o servidor	Servidor: Apache/2.4.1 (Unix)
Set-Cookie	Um cookie HTTP	Set-Cookie: UserID=JohnDoe; Max-Age=3600; Versão=1
Agente-usuário	A cadeia do agente de usuário do agente de usuário	Usuário-Agente: Mozilla/5.0 (compatível; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)
Vary	Diz aos procuradores abaixo como combinar futuros cabeçalhos de solicitação para decidir se a resposta em cache pode ser usada em vez de solicitar uma nova solicitação do servidor de origem.	Vary: Usuário-Agente
X-Powered-By	Especifica a tecnologia (por exemplo, ASP.NET, PHP, JBoss) que suporta a aplicação web	X-Powered-By: PHP/5.4.0

Sentido

O campo Sentido é um campo booleano de queda e contém opções de Fazer ou Não Fazer.

Verifique

O campo Verificar permite a definição de valores de verificação em relação à Condição.

As opções disponíveis são: Contain, End, Equal, Exist, Have Length, Match RegEx, Match List, Start, Exceed Length

VERIFIQUE	DESCRIÇÃO	EXEMPLO
Existente	Isto não se preocupa com o detalhe da condição apenas que ela existe/não existe	Anfitrião - Existe - Existe
Início	A cadeia começa com o Valor	Caminho - Faz - Começa - /secura
Fim	O fio termina com o Valor	Caminho - Faz - Termina - .jpg
Conter	O fio contém o Valor	Solicitar cabeçalho - Aceitar - Fazer - Conter - Imagem
Igual	O fio faz igualar o valor	Host - Does - Equal - www.jetnexus.com
Ter Comprimento	O fio tem um comprimento do valor	Host - Does - Have Length - 16www.jetnexus.com = TRUEwww.jetnexus.co.uk = FALSE
Combinar RegEx	Permite que você insira uma expressão regular totalmente compatível com Perl	Origem IP - Faz - Combina Regex - 10/11.* \| 11/11.*

Passos para acrescentar uma Condição

Adicionar um novo FlightPATH Condition é muito fácil. Um exemplo é mostrado acima.

1. Clique no botão Add New dentro da área Condition.

2. Escolha uma condição a partir da caixa drop-down. Tomemos como exemplo o Host. Você também pode digitar no campo, e o ADC mostrará o valor em uma caixa suspensa.

3. Escolha um Sentido. Por exemplo, o

4. Escolha um cheque. Por exemplo, Conter

5. Escolha um valor. Por exemplo, mycompany.com

O exemplo acima mostra que há duas condições que ambas têm de ser VERDADEIRAS para que a regra seja completada

· A primeira é verificar se o objeto solicitado é uma imagem

· O segundo verifica se o host na URL é www.imagepool.com

Avaliação

A capacidade de adicionar variáveis definíveis é uma capacidade convincente. Os ADCs regulares oferecem esta capacidade usando opções de script ou linha de comando que não são ideais para ninguém. O ADC permite que você defina qualquer número de variáveis usando uma GUI fácil de usar, como mostrado e descrito abaixo.

A definição variável flightPATH compreende quatro entradas que precisam ser feitas.

· Variável - este é o nome da variável

· Fonte - uma lista drop-down de possíveis pontos de origem

· Detalhe - selecione valores de um drop-down ou digitados manualmente.

· Valor - o valor que a variável detém e pode ser um valor alfanumérico ou um RegEx para ajuste fino.

Variáveis incorporadas:

As variáveis embutidas já foram codificadas de forma rígida, portanto, não é necessário criar uma entrada de avaliação para elas.

Você pode usar qualquer uma das variáveis listadas abaixo na seção Ação.

A explicação para cada variável está localizada na tabela "Condição" acima.

· Método = $method$

· Caminho = $caminho$

· Querystring = $querystring $querystring

· Sourceip = $sourceip$

· Código de resposta (o texto também incluía "200 OK") = $respresp...

· Anfitrião = $host$

· Versão = $version$

· Clientport = $clientport$

· Clientip = $clientip$

· Geolocalização = $geolocalização$".

AÇÃO	META
Ação = Redirecionar 302	Alvo = HTTPs://$host$/404.html
Ação = Log	Meta = Um cliente de $sourceip$:$sourceport$ acabou de fazer um pedido $path$ página

Explicação:

· Um cliente que acesse uma página que não existe normalmente seria apresentado com a página de erro 404 do navegador.

· Em vez disso, o usuário é redirecionado para o hostname original que usou, mas o caminho incorreto é substituído pelo 404.html

· Uma entrada é adicionada ao Syslog dizendo: "Um cliente de 154.3.22.14:3454 acabou de solicitar a página wrong.html".

Ação

A próxima etapa do processo é acrescentar uma ação associada à regra e condição do flightPATH.

Neste exemplo, queremos reescrever a parte do caminho da URL para refletir a URL digitada pelo usuário.

· Clique em Add New (Adicionar novo)

· Escolha Rewrite Path (Reescrever caminho) no menu suspenso Action (Ação)

· No campo Alvo, digite em $path$/myimages

· Clique em Atualizar

Esta ação adicionará /myimages ao caminho, de modo que a URL final se torna www.imagepool.com/myimages

Aplicando a regra flightPATH

A aplicação de qualquer regra flightPATH é feita dentro da aba flightPATH de cada VIP/VS.

· Navegue até Serviços > Serviços IP e escolha o VIP ao qual você deseja atribuir a regra flightPATH.

· Você verá a lista de Servidores Reais mostrada abaixo

· Clique na aba flightPATH

· Selecione a regra flightPATH que você configurou ou uma das regras pré-construídas suportadas. Você pode selecionar várias regras flightPATH, se necessário.

· Arraste e solte o conjunto selecionado para a seção PAATOS DE VOOO APLICADOS ou clique no botão >> seta.

· A regra será movida para o lado certo e aplicada automaticamente.