pfSense OpenVPN: alcançar uma rede atrás de outro router

O seu portátil alcança a LAN do pfSense através da VPN e mesmo assim não consegue chegar a um serviço dois saltos mais adiante, e a diferença é uma decisão de encaminhamento por proprietário. Três dispositivos têm de concordar antes de um pacote completar a viagem de ida e volta: o cliente, a firewall e o router que realmente possui a rede de destino. Falte um deles e o sintoma parece idêntico.

Siga um pacote por essas três decisões antes de alterar uma regra, porque cada proprietário tem um controlo diferente e um modo de falha diferente.

Um pacote, três decisões de encaminhamento

O cliente decide se o destino pertence ao túnel, e só pode decidir a partir do que sabe: uma rota empurrada, uma rota local ou uma rota predefinida que já abrange tudo. O pfSense decide para onde enviar o pacote a seguir, o que para uma rede atrás de outro router significa uma rota estática através de um gateway alcançável na interface correta. O router de baixo decide se conhece um caminho de volta ao grupo da VPN, e se não conhecer, a resposta é descartada ou enviada para um lugar inútil. Cada decisão é independente das outras duas.

A falha de qualquer uma delas produz o mesmo relato do utilizador. É por isso que a ordem de depuração importa mais do que as ferramentas.

Dê ao cliente um prefixo, não um palpite

Num servidor pfSense SSL/TLS com uma rede de túnel IPv4 maior do que um /30, o campo IPv4 Local network(s) distribui rotas aos clientes quando estes se ligam. Acrescente aí o prefixo de baixo em vez de contar com o cliente para inventar um. Depois leia a tabela real do cliente após a ligação, porque um perfil com route-nopull ou um filtro de rotas pode ignorar o que o servidor enviou. O servidor pode estar perfeitamente correto enquanto o cliente nada instala.

Outros modos de servidor e topologias têm limites diferentes, e uma política por cliente ou por ligação pode mudar o que um cliente específico recebe. Verifique no cliente que importa, não naquele que por acaso testou primeiro.

Aponte o pfSense para o router interno

Uma rota estática no pfSense precisa de um gateway definido e alcançável, e a interface escolhida para esse gateway tem de ser a que realmente lá chega, como descreve o guia de rotas estáticas da Netgate. Numa disposição ilustrativa, a ligação de trânsito é 192.168.77.1 na firewall e 192.168.77.2 no router interno, com a rede de serviços em 172.16.30.0/25 atrás. A rota nomeia então o prefixo e o próximo salto, não o endereço do serviço. Usar um endereço da rede remota como gateway é uma forma comum de construir uma rota que parece correta e não encaminha para lado nenhum.

Dar um nome a uma interface não descreve as redes por trás dela. A rota estática é essa descrição.

O lado remoto tem de conhecer o grupo

O router de baixo precisa de uma rota de retorno para o grupo, neste exemplo 10.55.0.0/24 via 192.168.77.1, a menos que uma rota predefinida ou um protocolo dinâmico já forneça uma. O gateway do próprio anfitrião do serviço tem de apontar para esse router, o que normalmente é verdade quando o router é o seu gateway predefinido e falso quando o anfitrião foi configurado à mão. O encaminhamento por políticas na firewall também pode substituir a tabela para tráfego específico, por isso verifique se uma regra seleciona outro gateway antes de concluir que a rota está errada.

Este desenho não requer tradução, e manter visível o endereço de origem do cliente permite que a rede de baixo aplique a sua própria política.

Para aceitação, siga um pedido novo através da entrada do túnel, da saída interna da firewall e da resposta do destino. Se em vez disso se usar tradução deliberadamente, registe que origem vê a rede de baixo e como se espera que a resposta volte.

Guarde o plano dos três proprietários junto da aplicação permitida, para que o próximo administrador possa reconstruir o caminho em vez de o redescobrir.