Um hub OpenVPN, três LANs: plano de endereços e arquivos iroute

Três LANs privadas podem se encontrar em um único hub sem que nenhum site precise conhecer a estrutura interna dos outros, e todo o desenho repousa sobre quatro decisões curtas de configuração. O que faz funcionar não é um recurso exótico de protocolo, mas um plano de endereços que ninguém precisa adivinhar, além de rotas por cliente que dizem ao hub qual filial possui qual prefixo. Erre uma das duas e o túnel ainda sobe, e é exatamente isso que torna a falha confusa.

Siga as etapas na ordem. Cada uma depende do plano da etapa anterior, e nenhuma exige uma nova autoridade certificadora.

Comece com um plano que ninguém precisa adivinhar

Anote quatro prefixos disjuntos antes de tocar em um arquivo de configuração: a LAN do próprio hub, a LAN de cada filial e o pool entregue aos clientes nômades. A disjunção é o que mantém todo o resto simples, porque faixas sobrepostas transformam o roteamento em um quebra-cabeça de maior correspondência que nenhuma configuração por cliente conserta. Em seguida, confirme qual máquina é o gateway padrão de cada LAN, já que um roteador de filial que não é o gateway da própria LAN precisa instalar as rotas remotas em outro lugar por completo. Por fim, fixe os nomes autenticados que identificam cada filial, porque esses nomes são as chaves pelas quais os arquivos por cliente são procurados.

Um plano ilustrativo mantém o pool bem longe das três LANs. O seu será diferente, e a única regra dura é que duas faixas não se sobreponham.

Hub LAN        172.20.0.0/24
Branch A LAN   172.21.0.0/24
Branch B LAN   172.22.0.0/24
VPN pool       10.77.0.0/24

identity branch-a owns 172.21.0.0/24
identity branch-b owns 172.22.0.0/24

Diga ao kernel do hub onde estão as filiais

O hub precisa de duas informações por filial: uma rota de kernel que envia o prefixo para o dispositivo de túnel e uma entrada iroute que diz ao processo OpenVPN qual cliente é o dono dela. A rota de kernel sozinha entrega os pacotes ao túnel e para ali, porque o daemon ainda precisa decidir qual peer deve recebê-los. A entrada iroute sozinha deixa esses pacotes no kernel sem rota a seguir. As duas linhas pertencem à configuração que o daemon realmente carrega, e vale verificar isso antes de depurar qualquer outra coisa.

dev tun
topology subnet
server 10.77.0.0 255.255.255.0
disable-dco

route 172.21.0.0 255.255.255.0
push "route 172.20.0.0 255.255.255.0"
client-config-dir /etc/openvpn/ccd
route 172.22.0.0 255.255.255.0

Mantenha o client-to-client desligado quando o kernel deve ser o ponto de aplicação das regras. Essa opção encaminha o tráfego entre peers dentro do daemon, o que é conveniente e também significa que suas regras de encaminhamento nunca veem o fluxo. Tudo abaixo pressupõe que o kernel vê cada pacote entre filiais.

Dê a cada filial as rotas de que precisa

Cada filial precisa de rotas para as outras filiais e para a LAN do hub, e não precisa de uma para a própria LAN conectada. Empurre os prefixos remotos a partir do hub em vez de colá-los em cada roteador, para que um quarto site mais tarde signifique um novo arquivo por cliente em vez de quatro edições. O arquivo por cliente também carrega a linha iroute, que mantém propriedade e anúncio no mesmo lugar. Torne o diretório e seus arquivos legíveis segundo o modelo de privilégios do servidor, ou a busca falha sem mensagem.

# /etc/openvpn/ccd/branch-a
iroute 172.21.0.0 255.255.255.0
push "route 172.22.0.0 255.255.255.0"

Um quarto site segue o mesmo padrão: um nome autenticado distinto, um prefixo próprio, uma rota de kernel no hub, uma entrada iroute e anúncios apenas para os sites autorizados a alcançá-lo.

Teste nas duas direções antes de dar por concluído

Ative o encaminhamento IPv4 nos três roteadores e depois confirme que o firewall permite os fluxos pretendidos nas duas direções, porque um teste de mão única passa com um caminho de retorno quebrado mais vezes do que qualquer um espera. Entre sites não é necessário traduzir o endereço de origem, e preservar a origem original é justamente o que permite a cada filial aplicar sua própria política a uma requisição.

Teste de um host em uma LAN de filial para um serviço em outra, depois inverta a direção e então teste de uma filial para a LAN do hub. Esses três resultados são evidências diferentes, e nenhum implica os outros. Se um roteador de filial não é o gateway padrão da própria LAN, instale os prefixos remotos no gateway real e inclua também o pool quando os clientes do túnel precisarem iniciar conexões para essa LAN.

Registre o plano, os arquivos por cliente e as regras de firewall como um único documento, porque a próxima adição de site será julgada com base neles.

O desenho se sustenta porque cada camada tem uma tarefa: o plano mantém os prefixos únicos, a rota de kernel move os pacotes, iroute nomeia o proprietário e o firewall decide o que é permitido. Quando algo quebra, essa lista também é a ordem de verificação.