CIDR de grupo no Access Server: endereços dos membros ou rede de recursos

Num grupo do Access Server, dois campos aceitam um CIDR e, à primeira vista, parecem o mesmo tipo de entrada: um descreve os endereços entregues aos membros da VPN, o outro descreve as redes que esses membros podem alcançar. Preencher o campo errado é aceito sem erro, e é exatamente isso que torna o equívoco caro. O primeiro muda o plano de endereçamento do túnel, o segundo decide quais destinos são permitidos, e nenhum implica o outro. Há também um terceiro objeto que as pessoas misturam com esses dois, a sub-rede atrás do gateway de uma filial, e ele não pertence a nenhum dos campos.

A mesma sintaxe, perguntas diferentes

Pergunte o que o valor nomeia. Um CIDR de endereços de membros responde quais endereços internos os clientes que se conectam recebem, e a máquina de atribuição o consome antes de qualquer tráfego fluir. Um CIDR de recurso responde quais destinos este grupo pode usar, e as regras de acesso o consomem quando um pacote é avaliado. Um é a definição de um pool, o outro é uma permissão.

As consequências da confusão são opostas. Uma LAN de destino colada no campo do pool pode entregar endereços que já existem nessa LAN e produzir comportamento de endereços duplicados, ou deslocar o pool de modo que quebre em silêncio todas as regras de firewall escritas para a faixa antiga. Um pool colado numa regra de acesso não concede nada útil, porque nenhum destino mora ali. Os dois erros aparecem do mesmo jeito: o túnel está no ar, mas algo está errado.

Atribuição: o espaço de endereços dos membros

O pool não pode sobrepor-se a nenhuma LAN que um membro possa alcançar nem a outro pool VPN da implantação. É uma restrição de planejamento, não um ajuste do produto: quando dois locais usam 10.90.40.0/24 para membros, um membro de um local não consegue rotear para o outro sem tradução, e nenhuma regra de acesso corrige isso.

O modo de atribuição também importa. Um pool dinâmico entrega a cada membro o próximo endereço livre, enquanto uma atribuição estática por usuário o fixa. A atribuição estática é o que você quer quando regras de firewall ou monitoramento se referem a membros individuais, e ela também torna visível uma mudança no plano de endereçamento: o endereço fixado continua dentro do novo pool ou não. Leia o endereço de túnel de um membro conectado antes e depois de qualquer alteração neste campo.

Permissão: as redes de destino ficam nas regras de acesso

A alcançabilidade é expressa nas regras de acesso, que nomeiam o grupo ou os usuários, uma rede ou serviço de destino e o método de acesso. Essa última parte é onde morrem a maioria das configurações pela metade: uma regra pode rotear o tráfego até o destino ou aplicar NAT, e as duas coisas pedem coisas diferentes da rede. Um caminho roteado exige que o lado do destino saiba devolver o tráfego ao pool VPN, enquanto um caminho com NAT esconde os membros atrás de um endereço em que o destino já confia. A documentação de grupos do Access Server mantém a rede do grupo separada das regras de acesso do grupo, e os rótulos mudaram entre versões.

Um destino permitido ainda precisa de um caminho utilizável. A regra permite, a rota entrega, o caminho de volta responde e o serviço no host aceita. Quatro coisas, quatro lugares para olhar, e só a primeira vive na regra de acesso. Uma permissão verde com um traceroute morto costuma significar que falta a rota de volta no gateway do destino, não que a regra esteja errada.

O terceiro objeto: uma sub-rede de filial atrás de um gateway

Declarar que um cliente específico é dono de uma sub-rede é uma afirmação de roteamento sobre um local, não uma atribuição de endereços e não uma permissão. Em termos de Access Server, é a configuração de gateway suportada para uma rede que se conecta, e existe porque um roteador de filial pode anunciar a LAN que tem atrás. Os membros continuam recebendo endereços do pool e continuam precisando de uma regra de acesso para usar essa LAN da filial.

Manter os três separados compensa na revisão. Uma sub-rede de filial registrada como espaço de endereços dos membros do grupo parece correta numa captura de tela e quebra a atribuição para todos do grupo. A mesma sub-rede anotada só numa regra de acesso concede acesso sem a declaração de propriedade, então o tráfego de volta não tem para onde ir. Coloque cada objeto na sua própria coluna do desenho e o erro deixa de ser possível.

Como saber qual você está olhando

Leia o rótulo junto com os vizinhos. Um campo ao lado de um modo de atribuição, de um tamanho de pool ou de uma exceção por usuário trata de atribuição. Um campo ao lado de um seletor de grupo, de um serviço ou porta e de um método de roteamento trata de permissão. As versões renomeiam coisas, mas os vizinhos ficam mais ou menos no lugar, e é por isso que o texto de uma captura antiga é um mau guia de navegação.

Depois verifique com um único membro em vez do grupo inteiro: o grupo efetivo, o endereço de túnel atribuído e a regra que autoriza o destino pretendido. Confirme a rota, o NAT ou o caminho roteado, o tráfego de volta e a permissão do serviço nessa ordem, e altere apenas o campo que corresponde à divergência demonstrada. Mantenha depois os registros de atribuição e de permissão separados, para que uma mudança posterior no pool não seja lida como uma mudança no que o grupo pode alcançar.