Como planear um conjunto de endereços de clientes VPN que caiba
Escolha o conjunto no campo do servidor, depois leia o endereço que um cliente recebe realmente, siga a resposta de volta e registe intervalo, modo, rota e âmbito de DNS.
Comece no campo do conjunto no servidor VPN, não numa folha de cálculo. O que escrever ali torna-se o espaço de endereços interno de cada cliente que se ligue depois, e tem de coexistir com a LAN que esses clientes alcançam, os sites encaminhados por trás dela e qualquer endereço que o cliente já tenha em casa. Ligue um cliente assim que o conjunto for guardado, porque essa primeira ligação diz-lhe se o valor funciona na prática. A partir daí a visita avança para fora: o endereço que o cliente recebeu, o caminho que uma resposta percorre e o registo que deixa atrás.
Comece no campo do conjunto, antes de qualquer cliente se ligar
Cada produto expõe isto de forma diferente, por isso encontre o objeto que realmente atribui endereços. O OpenVPN tem uma diretiva de conjunto do lado do servidor que entrega o próximo endereço livre, um gateway IKEv2 tem uma secção de conjunto ligada à configuração do par, e o WireGuard não tem nenhuma porque cada par transporta o seu próprio endereço no seu ficheiro de configuração. Uma diretiva de conjunto e um endereço por par não são permutáveis, e editar a errada desperdiça o resto da visita.
Depois de ter o campo, liste os intervalos que já existem: a LAN do escritório, cada site encaminhado, a VPC da nuvem e qualquer outro conjunto ainda em serviço. A sobreposição decide-se por aritmética de prefixo, não por os números de anfitrião parecerem familiares, por isso compare o agregado com cada um desses intervalos. Dois intervalos que ambos parecem 10.x são inofensivos quando os seus agregados não se cruzam e um incidente de suporte quando se cruzam.
Depois decida se o endereço é função de quem se liga ou de quando se liga. A atribuição dinâmica entrega o que está livre, enquanto a atribuição por identidade liga um endereço fixo a uma credencial. Escreva a escolha, porque muda o aspeto que uma religação deve ter mais tarde.
Leia o endereço que o cliente recebeu realmente
Ligue um cliente e leia o que o túnel relata, não o que o conjunto prometeu. O cliente mostra o seu endereço interno no estado da ligação, e no Linux a interface transporta-o diretamente.
Compare esse endereço com o intervalo que guardou. Se estiver fora do intervalo, está a ver um caminho de atribuição diferente daquele que editou. Verifique também o comprimento do prefixo, porque um cliente com um /32 não tem par no link e envia cada destino pela sua rota predefinida.
ip -4 addr show tun0
ip route get 192.168.50.20
Um cliente que se liga a partir de um router doméstico que usa o mesmo intervalo liga-se e depois quase não alcança nada. O cliente mantém a sua rota local para esse prefixo, pelo que o endereço do túnel colide com a rede por trás e o tráfego sai pela interface errada. Esse caso não se repara no servidor; o remédio documentado é renumerar a rede doméstica ou escolher um intervalo de conjunto suficientemente remoto para que as colisões continuem raras. Registe tanto a falha como o remédio, porque o serviço de apoio vai encontrá-lo outra vez.
Volte a ligar o mesmo cliente e observe o endereço. Um conjunto dinâmico pode devolver o mesmo valor ou outro e ambos estão corretos, enquanto um conjunto por identidade que muda o endereço não está a respeitar a ligação. Essa verificação leva segundos e decide se o modo que registou na primeira secção é o modo em vigor.
Siga uma resposta de volta desde o serviço
O conjunto só funciona quando as respostas conseguem viajar de volta até ele. Um serviço na LAN responde ao endereço interno, por isso o seu gateway precisa de uma rota para o conjunto ou de uma tradução à frente do serviço. Quando um pedido chega pelo túnel e a resposta sai por um caminho diferente, uma firewall com estado ou uma verificação de caminho inverso descarta-a, e o cliente vê um serviço que se liga e depois fica pendurado. Coloque o conjunto no desenho de encaminhamento como um único bloco resumível em vez de acrescentar rotas por anfitrião.
A tradução muda o que o resto do sistema vê. Quando a origem é reescrita, o endereço na firewall do anfitrião e no registo da aplicação é o traduzido, pelo que uma regra escrita contra o endereço do conjunto não corresponde a nada e uma linha de registo não pode ser rastreada até um cliente. A documentação de encaminhamento do strongSwan cobre a metade do lado do servidor desse caminho para um gateway IKEv2. O DNS transporta a mesma restrição, porque um nome que resolve para um endereço que o cliente não consegue alcançar falha mais tarde e noutro lugar.
Dois clientes, depois uma revogação
Ligue dois clientes ao mesmo tempo e leia ambos os endereços. Têm de ser distintos, utilizáveis e estar dentro do conjunto, e cada um deve alcançar o serviço a que se destina. Um conjunto que entrega endereços duplicados costuma revelar-se aqui e não no primeiro teste com um só cliente.
Revoque uma credencial enquanto o outro cliente continua ligado, depois experimente o serviço a partir do cliente sobrevivente. Uma revogação que perturba a outra sessão aponta para estado partilhado, muito frequentemente uma credencial ou um endereço reutilizado entre dispositivos. Volte a ligar o cliente revogado e confirme que lhe é negado em vez de receber o endereço libertado.
Termine com um destino que devia ser negado. Um cliente que alcança tudo foi ligado, não testado.
Escreva os quatro valores onde a próxima alteração os encontrará
O registo é curto: o intervalo e o prefixo do conjunto, o modo de atribuição, o caminho de retorno ou a tradução em uso e o âmbito de DNS que responde por esses destinos. Coloque-o ao lado da configuração do servidor em vez de num ticket, e date-o. Quem alterar um dos quatro mais tarde precisa dos outros três à frente, porque um redimensionamento do conjunto quebra a rota e uma mudança de rota quebra a resposta DNS.
Guarde com ele a nota de propriedade: o intervalo do túnel pertence ao servidor VPN, e uma reserva feita no âmbito DHCP da LAN não reserva nada para um cliente dentro do túnel. Essa única linha evita o retrabalho mais comum, em que alguém acrescenta uma reserva e espera que o endereço do túnel a siga.