VPN da filial em 4G: mantenha a identidade estável quando o IP muda

Comece pela própria filial, na página de estado WAN do router 4G. Se o endereço que vê estiver na faixa privada da operadora em vez de uma pública, nenhum encaminhamento de porta nessa caixa permitirá alguma vez que o hub ligue para dentro, e o túnel tem de ser construído para fora a partir da filial. Essa única observação decide o desenho. O resto do trabalho é garantir que o hub reconhece a filial por algo melhor do que um endereço que muda a cada poucas horas.

Onde o túnel tem de começar

Verifique o endereço contra o espaço de endereçamento partilhado que as operadoras usam para o seu próprio NAT, 100.64.0.0/10, e contra as faixas privadas habituais. Ver um deles num uplink móvel significa normalmente que há NAT de operadora entre a filial e a internet, e que as ligações de entrada não estão disponíveis por nenhum preço que a filial possa pagar. Quando o endereço WAN é público mas muda, tem outro problema, mais fácil.

O DNS dinâmico só ajuda no segundo caso. Dá a um endereço público variável um nome estável para ligar, e não pode criar um mapeamento que a operadora nunca forneceu. Ainda assim vale a pena configurá-lo para o caso público, porque elimina o único passo manual de uma renumeração. No que não deve tornar-se é na resposta para uma filial que a operadora nunca tornou alcançável.

Separe o endereço que marca da identidade que compara

O hub precisa de algo estável onde ser encontrado, um endereço fixo aprovado ou um nome de anfitrião mantido. A filial precisa de uma forma estável de ser reconhecida, e no IKEv2 isso é o payload de identidade que apresenta durante a autenticação, independentemente do endereço de origem que os seus pacotes transportam. Uma cadeia como @branch-a.vpn.example funciona como essa identidade mesmo enquanto o endereço móvel muda a cada hora.

Essa cadeia é comparada com a política, não resolvida por DNS, por isso não espere uma consulta ao estabelecer o túnel. A configuração do hub tem de nomear explicitamente a identidade esperada, e com autenticação por certificado a identidade também tem de corresponder ao que o certificado realmente afirma.

Aceitar qualquer identidade porque o endereço de origem parece plausível é o modo de falha a evitar. Num responder isso significa aceitar qualquer par, com um curinga de identidade e um segredo partilhado, o que autentica uma cadeia e não um dispositivo.

Escreva o lado do hub como um par nomeado

Em termos de strongSwan, o lado do responder é uma ligação com right=%any, que aceita um par de qualquer endereço de origem, mais [email protected], que fixa o que esse par tem de declarar ser. Acrescente rightsubnet=10.20.0.0/16 para as LAN da filial, auto=add para que a ligação seja carregada sem ser marcada, dpd_delay=30s para vitalidade e mobike=yes para que uma mudança de endereço seja absorvida em vez de tratada como um novo par.

Outros fabricantes exprimem os mesmos objetos com nomes diferentes, normalmente um tipo de par dinâmico ou de filial com um campo de identidade e um campo de sub-rede protegida. Preencha ambos; uma caixa genérica de dinâmico não é um plano de compatibilidade.

Mantenha a filial como iniciador

Na filial aplica-se a imagem espelhada: left=%defaultroute para que o endereço móvel local seja usado tal como está agora, [email protected] para apresentar a identidade, right=hub.example.com para o nome estável do hub e auto=start para que o túnel suba sem uma pessoa. Quando a ligação móvel se reconecta, a filial volta a iniciar e o hub compara a mesma identidade com o mesmo objeto de política.

Permita IKE em UDP 500, a passagem por NAT em UDP 4500 e o ESP encapsulado que se segue, dos dois lados. Depois deixe-os permitidos: uma regra que só abre durante o horário de trabalho parecerá um túnel intermitente.

Teste a mudança de endereço, não apenas o primeiro aperto de mão

Levante o túnel, confirme-o e depois force a filial para um novo endereço ligando e desligando os dados móveis ou o modo de avião durante um minuto. Observe a lista de associações de segurança no hub e verifique que o endereço do par mudou enquanto a identidade não. Um túnel que só funciona até à primeira reatribuição da operadora não foi testado de todo.

Depois verifique as sub-redes protegidas separadamente. Uma SA estabelecida diz que os pares se autenticaram; não diz que o hub tem uma rota para a LAN da filial nem que a filial aceita tráfego do lado do hub. Leia a tabela de encaminhamento e a política da firewall separadamente e depois envie um ping a partir de um anfitrião e não do gateway, pois o gateway é o dispositivo menos representativo de qualquer rede.

Uma identidade estável transforma a filial num objeto de política que o hub pode nomear. Não torna um endereço NAT de operadora alcançável, e não dá por si só ao resto da organização acesso à filial.