VPN encaminhada ou LAN em ponte para uma ligação entre filial e laboratório

Há duas formas de fazer uma filial chegar a um laboratório caseiro, e a diferença não é uma definição. Pode encaminhar entre prefixos distintos, para que cada site mantenha o seu próprio domínio de difusão, ou pode pôr as duas LAN em ponte numa só, para que as difusões e o tráfego de descoberta se comportem como se todos estivessem na mesma sala. O encaminhamento é o projeto que sobrevive ao contacto com uma rede real. A ponte é o projeto que torna a primeira semana fácil e a primeira falha interessante. A comparação abaixo trata do que cada um lhe dá e do que custa, seguida de como tornar a versão encaminhada testável.

Duas formas de ligar, um compromisso óbvio

Uma ligação encaminhada trata o laboratório caseiro como uma rede remota com o seu próprio endereçamento. A filial pede o prefixo do laboratório, o túnel transporta esses pacotes e a porta de ligação do laboratório responde a partir da sua própria sub-rede. Nada na tabela ARP da filial muda, e nada do âmbito DHCP do laboratório chega à filial.

Uma ligação em ponte estende um único domínio de camada 2 pelos dois sites. Os protocolos de descoberta funcionam, os dispositivos aparecem automaticamente, e cada difusão, cada pedido ARP e cada pacote multicast é agora um candidato a atravessar o túnel, ou seja, uma grande quantidade de tráfego transportada por protocolos concebidos para um segmento local e não para uma WAN com outra MTU e um tempo de ida e volta variável.

O que o encaminhamento lhe dá

O primeiro benefício é o raio da avaria. Um ciclo, um servidor DHCP indesejado ou uma inundação de difusões fica no site que o produziu, porque um encaminhador não reenvia difusões. O segundo é a clareza do endereçamento: o prefixo da filial e o do laboratório são distintos, por isso o destino de um pacote diz-lhe qual site deve responder, e uma regra de firewall pode dizer «filial para sub-rede do laboratório» em vez de «qualquer sítio para qualquer sítio».

O terceiro é que corresponde ao que o túnel transporta de facto. Uma política IPsec é um par de prefixos, e o caminho de reencaminhamento de cada lado é encaminhamento IP comum com o reencaminhamento ativo na porta de ligação:

sysctl -w net.ipv4.ip_forward=1
ip route add 10.20.0.0/24 via 192.168.50.1
ip route get 10.20.0.40

O que perde é a descoberta por difusão. É uma perda real, e deve ser substituída de propósito em vez de contornada pondo tudo em ponte.

O que a ponte custa

A ponte tem de transportar tramas de camada 2 por um túnel, o que implica um encapsulamento como GRE ou VXLAN sobre IPsec em vez de um túnel simples baseado em políticas. Assim que isso existe, os dois sites partilham um domínio de falha. A árvore de expansão vê o túnel como uma ligação, o tráfego de difusão consome largura de banda do túnel, e qualquer dispositivo que assume um segmento de baixa latência comporta-se mal de formas difíceis de atribuir a partir de qualquer dos extremos.

Também remove a verificação de endereçamento que o mantém honesto. Com um prefixo plano, um endereço duplicado não é um erro de encaminhamento mas dois anfitriões a roubar silenciosamente o tráfego um do outro, e os prefixos sobrepostos entre uma filial e um laboratório são comuns em montagens de laboratório caseiro, por isso a ponte não resolve esse conflito; distribui-o.

O argumento de segurança é o que costuma decidir. Uma ponte estende o segmento onde operam os protocolos de ligação local, por isso um dispositivo na filial pode falar com dispositivos do laboratório que nunca deveriam ser alcançáveis do exterior. Se o laboratório tem um hipervisor, uma consola de armazenamento e uma interface de gestão na mesma rede plana, isso passa a ser um só segmento com a filial.

Nomes sem difusão

A razão pela qual as pessoas põem em ponte é geralmente a descoberta: uma impressora, um leitor multimédia ou um anfitrião do laboratório que nunca aparece numa lista. A resposta encaminhada é um serviço de nomes. Publique os anfitriões do laboratório numa zona que o resolvedor da filial consiga alcançar, e depois deixe os utilizadores ligarem-se por nome em vez de varrerem a rede. Isso é mais trabalho no início e bastante menos trabalho em cada mudança futura.

A descoberta multicast é o caso mais difícil, e merece precisão. Protocolos como o mDNS usam multicast de ligação local, que os encaminhadores não reenviam por predefinição, por isso um anfitrião do laboratório ausente de uma lista de descoberta pode continuar alcançável no seu endereço documentado. Se um serviço específico exigir mesmo multicast, planeie esse único protocolo, com um refletor ou uma regra de reencaminhamento dirigida, em vez de pôr a LAN inteira em ponte como reparação geral.

Um refletor também não é uma vitória gratuita. Importa o mesmo tráfego falador que estava a tentar evitar, um serviço de cada vez, e precisa de um responsável que note quando um dispositivo começa a anunciar mais do que antes. Escolha-o por serviço, e escreva porquê. Registe que serviço precisava dele e o que anuncia, porque uma atualização de firmware pode mudar essa lista sem avisar ninguém.

Torne o projeto encaminhado testável

Escolha um alvo, por exemplo uma interface web do laboratório na sua própria sub-rede de servidores, e prove-o nos dois sentidos. A partir de um anfitrião da filial, confirme o endereço e o serviço à escuta localmente, depois ligue-se pelo túnel e repita. Um túnel que está de pé prova que as portas de ligação concordam; não prova nada sobre a firewall do anfitrião nem sobre a rota de regresso.

A porta de ligação normal do laboratório precisa de uma rota de regresso ao prefixo da filial, a menos que o projeto traduza a origem de propósito, e a firewall do próprio servidor tem de aceitar o intervalo remoto permitido. Nenhuma delas é configurada por um túnel bem-sucedido. As notas de reencaminhamento do strongSwan descrevem o caminho dos pacotes que tem de funcionar de cada lado.

Depois teste também um destino negado. Um utilizador da filial que precisa de uma aplicação não precisa da consola do hipervisor, e a única forma de saber que a política é real é tentar precisamente aquilo que ela deve recusar. Registe os prefixos, a dependência do resolvedor e os resultados dos testes, e uma mudança futura em qualquer dos sites pode ser revista em minutos em vez de reconstruída de memória.