pfSense como servidor e cliente VPN: dous camiños, un só router

Un só equipo pode mirar en dúas direccións á vez: os usuarios itinerantes conéctanse cara a dentro, e a mesma caixa conéctase cara a fóra a un provedor de saída para que o tráfico seleccionado saia por outra rede. Habilitar ambos os servizos leva minutos; facelos convivir esixe un deseño, porque o segundo rol reescribe a táboa de rutas da que depende o primeiro. Tres condicións deciden se o arranxo funciona, a saber, se o servizo de entrada conserva a súa propia ruta de retorno, se o túnel de saída segue alcanzando o seu par e se o tráfico que querías reenviar queda seleccionado para a saída. Se fallas nunha, obtés dous túneles que ambos informan de conectado mentres nada útil cruza entre eles. As comprobacións de abaixo establecen cada condición na orde en que adoitan aparecer os fallos.

Nomea os dous roles antes de tocar calquera axuste

Anota catro feitos por cada instancia: o seu par remoto, o seu material de autenticación, o conxunto de enderezos que reparte e as redes que ten detrás. As dúas instancias son obxectos separados no equipo e tamén deben seguir separadas nas túas notas. Case todos os síntomas confusos posteriores veñen de mesturar os seus valores, e dúas instancias que comparten un xogo de notas é como o conxunto equivocado acaba no campo equivocado.

O servizo de entrada necesita unha rede de túnel que non se solape coas direccións do túnel de saída nin con ningunha rede privada que o equipo enrute. O solapamento é o único erro que produce síntomas en ambos os roles á vez, e é moito máis barato detectalo sobre o papel. Compara ambos os conxuntos e cada rede privada enrutada nun só lugar antes de configurar calquera dos servizos.

O hardware compartido non implica credenciais compartidas, e un certificado de cliente do conxunto de acceso remoto non debería servir contra o provedor de saída. O material separado tamén converte a revocación nunha decisión local en lugar dun acontecemento para toda a frota.

Mantén as respostas do servidor no camiño WAN

As respostas que o equipo xera por si mesmo son a primeira vítima dunha ruta por defecto descoidada. Cando chega un paquete encapsulado dun usuario itinerante, a resposta é tráfico de orixe local e ten que saír pola interface pola que chegou ese usuario. Se o cliente de saída instalou unha ruta por defecto que a captura, a resposta entra no túnel equivocado e a sesión atasca mentres o servizo aínda parece san.

Non hai unha soa casela que o resolva, porque a decisión vai sobre que tráfico pode capturar o cliente de saída. Ou ben non traes ningunha ruta e dirixes só o que selecciones, ou ben traes rutas e engades as excepcións que manteñen en marcha os servizos propios do equipo. Escribe a elección xunto á instancia, ou a seguinte persoa suporá a outra.

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

Le a táboa de rutas pola coincidencia máis longa e non pola orde en que configuraches algo. A pregunta é que entrada gaña para o enderezo do par de saída e que entrada gaña para a resposta do servizo de entrada, e esas dúas respostas poden diferir.

Non deixes que o túnel de saída coma o seu propio extremo

O cliente de saída ten que alcanzar o enderezo público do seu par para establecer o túnel sequera. Se ese enderezo se enruta dentro do túnel, o cliente perséguese a cola: o transporte nunca sobe, ou sobe e cae no momento en que se instala a ruta. O rexistro parece un tempo de espera de autenticación e non unha falla de enrutamento, e por iso a ruta merece a primeira comprobación.

Comproba a ruta antes das credenciais e de novo unha vez arriba o túnel, porque unha entrada pode ser correcta ao arrancar e equivocada un minuto despois. O enderezo do par debe apuntar ao camiño WAN ordinario, nunca ao dispositivo de túnel. Cando o transporte se estabiliza, a pregunta interesante pasa ao tráfico reenviado, que é a decisión seguinte.

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

Escolle que usuarios reciben a saída

A política de orixe corresponde á entrada onde o tráfico entra no equipo, así que selecciona o conxunto de acceso remoto, ou identidades máis estreitas dentro del. Conserva os destinos privados e as excepcións de xestión que nunca deben enviarse á saída, e coloca esas regras antes da ampla. O camiño de saída necesita entón a súa propia tradución ou un arranxo de retorno enrutado, que para a maioría dos deseños significa NAT de saída na interface de saída que cubra o conxunto. A tradución non escolle unha saída; só reescribe o que xa saíu, así que unha regra NAT nun WAN alleo non cambia nada na selección.

Confirma que o extremo remoto permite o tráfico reenviado deste deseño, porque algúns provedores si e outros non. A diferenza vese como un túnel que conecta e non transporta nada, o que é fácil de ler mal como un fallo local. Proba os tres fluxos por separado, porque fallan de forma independente e dous de tres é un deseño a medio construír.

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 conexión exterior do usuario itinerante, e funciona cando o cliente informa de que a secuencia de inicialización se completou. O segundo, executado desde ese portátil conectado, debería informar do enderezo do provedor de saída en lugar do teu enderezo WAN. O terceiro execútase no equipo ligado a un enderezo do conxunto, e proba a política de orixe para o tráfico reenviado sen implicar ningún usuario remoto. Se en cambio responde desde a WAN, a política non coincidiu, e ningunha cantidade de edición de NAT arranxa un problema de selección.

Decide que ocorre cando a saída falla

Escribe o comportamento ante o fallo antes de que ocorra: cando o túnel de saída cae, os usuarios volven á WAN ordinaria ou quedan bloqueados ata que a saída regresa? Ambas as respostas son defendibles, e o equipo non elixirá por ti. Unha ruta eliminada ou unha política que apunta a unha pasarela morta non producen automaticamente un resultado de bloqueo total. Se queres bloqueo, a política ten que dicilo explicitamente, e hai que probalo quitando a saída en lugar de razoar sobre ela. Se queres retroceso, publícao aos usuarios, porque o tráfico que toma en silencio o camiño ordinario é exactamente o tráfico que alguén cría cuberto.

Desactiva a instancia de cliente, observa a que pode chegar aínda un usuario conectado e volve arrancala. Unha petición que expira é o resultado de bloqueo total que pediches; unha que responde co enderezo WAN é o retroceso que non documentaches. Repite a comprobación para IPv6 e para DNS, porque unha política escrita para IPv4 non di nada sobre o tráfico AAAA e un resolvedor empurrado por calquera dos túneles responde desde onde realmente sae a consulta.

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 de Netgate para OpenVPN enrutado mostra como encaixan a política de orixe, a asignación de interfaces e a tradución de saída, e o seu alcance entre sitios é a parte que non hai que copiar enteira. O que non che dirá é cal das tres condicións de arriba xa rompeu o teu propio deseño.