pfSense como servidor e cliente VPN: dois caminhos, um só roteador

Um só aparelho pode olhar em duas direções ao mesmo tempo: os utilizadores nómadas ligam-se para dentro, e a mesma caixa liga-se para fora a um fornecedor de saída para que o tráfego selecionado saia por outra rede. Ativar ambos os serviços leva minutos; fazê-los coexistir exige um desenho, porque o segundo papel reescreve a tabela de rotas de que o primeiro depende. Três condições decidem se o arranjo funciona, a saber, se o serviço de entrada conserva o seu próprio caminho de retorno, se o túnel de saída ainda alcança o seu par e se o tráfego que querias reencaminhar é selecionado para a saída. Erra uma e obténs dois túneis que ambos reportam ligado enquanto nada de útil atravessa entre eles. As verificações abaixo estabelecem cada condição na ordem em que as falhas costumam aparecer.

Nomeia os dois papéis antes de tocar em qualquer definição

Anota quatro factos por cada instância: o seu par remoto, o material de autenticação, o conjunto de endereços que distribui e as redes por trás dele. As duas instâncias são objetos separados no aparelho e devem continuar separadas nas tuas notas também. Quase todos os sintomas confusos posteriores vêm de misturar os seus valores, e duas instâncias que partilham um conjunto de notas é como o conjunto errado acaba no campo errado.

O serviço de entrada precisa de uma rede de túnel que não se sobreponha aos endereços do túnel de saída nem a qualquer rede privada que o aparelho encaminhe. A sobreposição é o único erro que produz sintomas nos dois papéis ao mesmo tempo, e é muito mais barato apanhá-lo no papel. Compara os dois conjuntos e cada rede privada encaminhada num só lugar antes de configurares qualquer um dos serviços.

Hardware partilhado não implica credenciais partilhadas, e um certificado de cliente do conjunto de acesso remoto não deveria ser utilizável contra o fornecedor de saída. Material separado também transforma a revogação numa decisão local em vez de um evento para toda a frota.

Mantém as respostas do servidor no caminho WAN

As respostas que o aparelho gera por si mesmo são a primeira vítima de uma rota predefinida descuidada. Quando chega o pacote encapsulado de um utilizador nómada, a resposta é tráfego de origem local e tem de sair pela interface por onde esse utilizador entrou. Se o cliente de saída instalou uma rota predefinida que a captura, a resposta entra no túnel errado e a sessão bloqueia enquanto o serviço ainda parece saudável.

Não há uma única caixa que resolva isto, porque a decisão é sobre que tráfego o cliente de saída pode capturar. Ou não puxas rota nenhuma e encaminhas apenas o que selecionas, ou puxas rotas e acrescentas as exceções que mantêm os próprios serviços do aparelho a funcionar. Escreve a escolha ao lado da instância, ou a pessoa seguinte assumirá a outra.

netstat -rn | head -20
pfctl -sr | grep -i vpn
ifconfig | grep -A3 ovpn

Lê a tabela de rotas pela correspondência mais longa e não pela ordem em que configuraste algo. A pergunta é que entrada ganha para o endereço do par de saída e que entrada ganha para a resposta do serviço de entrada, e essas duas respostas podem diferir.

Não deixes o túnel de saída comer o seu próprio extremo

O cliente de saída tem de alcançar o endereço público do seu par para estabelecer o túnel, sequer. Se esse endereço for ele próprio encaminhado para dentro do túnel, o cliente persegue a própria cauda: o transporte nunca sobe, ou sobe e cai no momento em que a rota é instalada. O registo parece um tempo de espera de autenticação e não uma falha de encaminhamento, e por isso a rota merece a primeira verificação.

Verifica a rota antes das credenciais e de novo depois de o túnel estar em cima, porque uma entrada pode estar correta no arranque e errada um minuto depois. O endereço do par deve apontar para o caminho WAN comum, nunca para o dispositivo de túnel. Quando o transporte estabiliza, a pergunta interessante passa para o tráfego reencaminhado, que é a decisão seguinte.

netstat -rn | grep -F '198.51.100.10'
traceroute -n 198.51.100.10

Escolhe que utilizadores recebem a saída

A política de origem pertence à entrada onde o tráfego entra no aparelho, por isso escolhe o conjunto de acesso remoto, ou identidades mais estreitas dentro dele. Preserva os destinos privados e as exceções de gestão que nunca devem ser enviadas para a saída, e coloca essas regras antes da ampla. O caminho de saída precisa então da sua própria tradução ou de um arranjo de retorno encaminhado, o que na maioria dos desenhos significa NAT de saída na interface de saída que cubra o conjunto. A tradução não escolhe uma saída; apenas reescreve o que já saiu, por isso uma regra NAT numa WAN alheia não muda nada na seleção.

Confirma que a extremidade remota permite o tráfego reencaminhado deste desenho, porque alguns fornecedores permitem e outros não. A diferença aparece como um túnel que liga e não transporta nada, o que é fácil de ler mal como uma falha local. Testa os três fluxos em separado, porque falham de forma independente e dois de três é um desenho a meio construir.

openvpn --config user07.ovpn
curl -sS https://ifconfig.me
curl --interface 10.10.10.1 -sS https://intranet.corp.example/health

O primeiro comando é a ligação exterior do utilizador nómada, e funciona quando o cliente relata que a sequência de inicialização está completa. O segundo, executado a partir desse portátil ligado, deveria relatar o endereço do fornecedor de saída em vez do teu endereço WAN. O terceiro corre no aparelho ligado a um endereço do conjunto, e testa a política de origem para o tráfego reencaminhado sem envolver qualquer utilizador remoto. Se em vez disso responder pela WAN, a política não coincidiu, e nenhuma edição de NAT corrige um problema de seleção.

Decide o que acontece quando a saída falha

Escreve o comportamento em caso de falha antes de ela acontecer: quando o túnel de saída cai, os utilizadores voltam à WAN comum ou ficam bloqueados até a saída regressar? Ambas as respostas são defensáveis, e o aparelho não escolherá por ti. Uma rota removida ou uma política que aponta para uma gateway morta não produzem automaticamente um resultado de bloqueio total. Se queres bloqueio, a política tem de o dizer explicitamente, e tem de ser testada retirando a saída em vez de raciocinando sobre ela. Se queres retrocesso, publica-o aos utilizadores, porque o tráfego que toma silenciosamente o caminho comum é exatamente o tráfego que alguém julgava coberto.

Desativa a instância de cliente, observa a que ainda chega um utilizador ligado e volta a arrancá-la. Um pedido que expira é o resultado de bloqueio total que pediste; um que responde com o endereço WAN é o retrocesso que não documentaste. Repete a verificação para IPv6 e para DNS, porque uma política escrita para IPv4 não diz nada sobre tráfego AAAA e um resolvedor empurrado por qualquer dos túneis responde de onde o pedido realmente sai.

pfSsh.php playback svc stop openvpn client 2
curl --max-time 6 -sS https://ifconfig.me
pfSsh.php playback svc start openvpn client 2

A receita da Netgate para OpenVPN encaminhado mostra como a política de origem, a atribuição de interfaces e a tradução de saída encaixam, e o seu âmbito entre sites é a parte que não se deve copiar inteira. O que não te dirá é qual das três condições acima o teu próprio desenho já quebrou.