pfSense OpenVPN: chegar a unha rede detrás doutro router

O teu portátil chega á LAN de pfSense pola VPN e aínda así non consegue chegar a un servizo dous saltos máis adentro, e a diferenza é unha decisión de encamiñamento por propietario. Tres dispositivos deben poñerse de acordo antes de que un paquete complete a súa viaxe de ida e volta: o cliente, a devasa e o router que realmente posúe a rede de destino. Se falla calquera deles, o síntoma parece idéntico.

Segue un paquete por esas tres decisións antes de cambiar unha regra, porque cada propietario ten un control distinto e un modo de fallo distinto.

Un paquete, tres decisións de encamiñamento

O cliente decide se o destino pertence ao túnel, e só pode decidir a partir do que sabe: unha ruta empuxada, unha ruta local ou unha ruta predeterminada que xa cobre todo. pfSense decide onde enviar o paquete a continuación, o que para unha rede detrás doutro router significa unha ruta estática a través dunha porta de enlace alcanzable na interface correcta. O router de abaixo decide se coñece un camiño de volta ao grupo da VPN, e se non o coñece, a resposta descártase ou envíase a un lugar inútil. Cada decisión é independente das outras dúas.

O fallo de calquera delas produce o mesmo informe de usuario. Por iso a orde de depuración importa máis que as ferramentas.

Dálle ao cliente un prefixo, non unha suposición

Nun servidor pfSense SSL/TLS cunha rede de túnel IPv4 maior ca un /30, o campo IPv4 Local network(s) distribúe rutas aos clientes cando se conectan. Engade alí o prefixo de abaixo en vez de confiar en que o cliente invente un. Despois le a táboa real do cliente tras conectarse, porque un perfil con route-nopull ou un filtro de rutas pode ignorar o que enviou o servidor. O servidor pode ser perfectamente correcto mentres o cliente non instala nada.

Outros modos de servidor e topoloxías teñen límites distintos, e a política por cliente ou por conexión pode cambiar o que recibe un cliente concreto. Verifícao no cliente que importa, non no que probaches primeiro por casualidade.

Apunta pfSense ao router interno

Unha ruta estática en pfSense necesita unha porta de enlace definida e alcanzable, e a interface escollida para esa porta debe ser a que realmente chega a ela, como describe a guía de rutas estáticas de Netgate. Nun deseño ilustrativo, a ligazón de tránsito é 192.168.77.1 na devasa e 192.168.77.2 no router interno, coa rede de servizos en 172.16.30.0/25 detrás. A ruta entón nomea o prefixo e o seguinte salto, non o enderezo do servizo. Usar un enderezo da rede remota como porta de enlace é unha forma habitual de construír unha ruta que parece correcta e non reenvía a ningures.

Asignar un nome a unha interface non describe as redes que hai detrás. A ruta estática é esa descrición.

O lado remoto debe coñecer o grupo

O router de abaixo necesita unha ruta de volta para o grupo, neste exemplo 10.55.0.0/24 vía 192.168.77.1, salvo que unha ruta predeterminada ou un protocolo dinámico xa proporcionen unha. A porta de enlace do propio host do servizo debe levar cara a ese router, o que normalmente é certo cando o router é a súa porta predeterminada e falso cando o host se configurou a man. O encamiñamento por políticas na devasa tamén pode anular a táboa para tráfico concreto, así que comproba se unha regra selecciona outra porta antes de concluír que a ruta é incorrecta.

Este deseño non require tradución, e manter visible o enderezo de orixe do cliente permite que a rede de abaixo aplique a súa propia política.

Para a aceptación, segue unha petición nova a través da entrada do túnel, a saída interna da devasa e a resposta do destino. Se no canto se usa a tradución deliberadamente, rexistra que orixe ve a rede de abaixo e como se espera que volva a resposta.

Garda o plan dos tres propietarios xunto á aplicación permitida, para que o seguinte administrador poida reconstruír o camiño en lugar de volver descubrilo.