Pode uma única interface WAN servir a VPN entre sites e o acesso remoto?

Um único endereço público pode servir ao mesmo tempo um túnel de filial e um pool de utilizadores em mobilidade. Mas não pode servir uma única regra de admissão partilhada. O par da filial e o utilizador em mobilidade diferem em quem dizem ser, em como essa prova é verificada, nos endereços que recebem e nos prefixos que lhes podem responder. Assim que trata o endereço externo como um detalhe de transporte e não como uma identidade, o desenho torna-se muito mais simples.

Um teste rápido de bom senso: tente escrever os dois registos de admissão antes de tocar no router. Se uma única condição de correspondência tiver de cobrir ambos, a política já é ambígua, e o primeiro sintoma parecerá uma falha de encaminhamento ou de firewall quando na verdade é uma falha de identidade.

Dois registos antes de qualquer configuração

O registo da filial é curto e estável. Enumera o endereço do par ou o nome do certificado, a chave pré-partilhada ou o trustpoint do certificado, as sub-redes protegidas dos dois lados, a interface do túnel e a rota estática que envia o tráfego para a filial dentro desse túnel. Cada campo diz respeito a um par conhecido e a um conjunto fixo de prefixos.

O registo da mobilidade é mais amplo e mais pessoal. Enumera o protocolo e a porta do cliente, como um utilizador ou dispositivo se autentica, o pool de endereços atribuído na ligação, os recursos que esse pool pode alcançar, os prefixos do túnel dividido, os servidores DNS empurrados para o cliente e qualquer segundo fator. Cada campo responde a uma pergunta sobre um número desconhecido de utilizadores e não sobre um único gateway.

Essa diferença de granularidade é toda a razão pela qual os dois papéis divergem. Um perfil de filial pode confiar em segurança numa única chave porque a chave pertence a um único dispositivo num único local. Um perfil de mobilidade que confia numa única chave de grupo para todos colapsa a responsabilidade por utilizador, e isso costuma descobrir-se mais tarde, na revisão de um incidente e não no lançamento.

Onde divergem o emparelhamento de pares e a autenticação

No IOS XE o perfil IKEv2 transporta os parâmetros que não podem ser negociados e as condições usadas para selecionar o par. Isso significa que o lado da filial e o lado da mobilidade precisam cada um do seu próprio perfil, mesmo quando terminam na mesma interface e mesmo quando partilham uma mesma PKI criptográfica. A Cisco documenta os papéis do perfil, da autenticação e do emparelhamento no seu guia de configuração de IKEv2 para IOS XE 17.

O perfil da filial costuma corresponder a uma identidade estreita: um endereço remoto, um FQDN ou um sujeito de certificado. Algo como match identity remote address 198.51.100.10 255.255.255.255 fixa um único par, e authentication remote pre-share com uma chave guardada por local é suficiente. Mantenha a correspondência tão específica quanto o inventário de pares permitir, porque um wildcard sobreposto mais acima na ordem de seleção pode arrastar o tráfego da filial para o perfil errado.

O perfil da mobilidade não pode fixar um endereço, por isso corresponde a um grupo, a um key-id ou a um campo do certificado, e depois entrega a verificação real do utilizador ao AAA ou à política de autorização ligada ao perfil. Essa separação importa: a autenticação do par responde se o cliente pode construir um túnel, e a autorização por utilizador responde qual o pool e os recursos que recebe. Usar a chave da filial como início de sessão universal deita fora a segunda resposta.

O encaminhamento e a tradução precisam da mesma separação

A admissão e a acessibilidade são problemas distintos. Uma troca de IKE e IPsec bem-sucedida prova que as partes concordam nas chaves; não cria uma rota para o pool que o cliente recebeu. Por isso os pools de acesso remoto precisam de um caminho de retorno, quer uma rota estática a apontar para a interface do túnel, quer um protocolo de encaminhamento que injete o resumo do pool. Os prefixos da filial chegam normalmente pelo mesmo processo de encaminhamento que serve o resto do local.

A tradução é onde os dois papéis colidem com mais frequência. O tráfego entre locais que tem de conservar os seus endereços privados precisa de uma isenção de NAT limitada a esses dois prefixos, nos dois sentidos. Os clientes em mobilidade também costumam precisar de isenção para o tráfego dentro do túnel, mas o seu tráfego para a internet ou contorna o túnel pelo túnel dividido ou sai no concentrador depois do NAT. Isentar tudo o que vem de um túnel é o erro clássico, porque também retira a tradução a tráfego que dela precisa mesmo.

Mantenha as regras de isenção tão estreitas como as regras de admissão. Se um resumo de pool e um prefixo de filial se sobrepuserem, o caminho de retorno torna-se ambíguo muito antes de qualquer pacote ser descartado, e o sintoma aparece como um local que perde uma sub-rede de vez em quando e não como uma falha limpa do túnel.

Casos de aceitação que expõem uma política cruzada

Construa quatro casos e execute-os por ordem. Um anfitrião da filial alcança um recurso só da filial. Um cliente em mobilidade alcança o mesmo recurso através do endereço do seu pool. Um cliente em mobilidade tenta um prefixo da filial que não devia tocar. Um par da filial tenta obter um endereço do pool de acesso remoto. Os dois últimos são os que apanham um perfil partilhado, porque falham em silêncio na monitorização normal.

Depois confirme o plano de dados e não a configuração. show crypto ikev2 sa e show crypto ipsec sa dizem que perfil e que seletores transportaram cada fluxo, enquanto show ip nat translations e os contadores do túnel mostram se o caminho de retorno e a isenção coincidiram de facto. Um tracer ou uma captura de pacotes na interface do túnel fecha o ciclo.

Escreva a identidade observada, o endereço do pool e a política escolhida ao lado de cada resultado. A ronda termina quando cada caso corresponde exatamente a um registo e nenhum caso precisa de uma exceção temporária para passar.