Encamiña unha subrede LAN por OpenVPN e conserva a ruta predeterminada

Os equipos que encamiñan para unha LAN e ademais marcan unha VPN acaban na mesma discusión consigo mesmos: o túnel quere posuír a ruta predeterminada e a LAN necesita recuperala. Cando OpenVPN se conecta, pode instalar unha ruta predeterminada polo túnel ou un par de medias rutas predeterminadas, o que é correcto para un portátil e incorrecto para unha pasarela cuxos veciños esperan respostas desde o seu enderezo LAN. A resposta non é saltar a VPN. A resposta é dar ás dúas decisións táboas distintas.

Unha ruta predeterminada, dous propietarios

O tráfico reenviado e o tráfico orixinado localmente non teñen que seguir o mesmo camiño. Os clientes da LAN só necesitan o túnel para os destinos que escollas, mentres que as sesións de xestión do propio host e as súas respostas a eses clientes necesitan a ruta predeterminada da LAN. Mesturar ambas na táboa principal obriga a unha soa resposta a responder dúas preguntas distintas.

OpenVPN ten un conmutador xusto para isto. route-noexec impide que o cliente toque a táboa principal, e os valores que tería usado expórtanse a un script route-up como route_vpn_gateway, dev e os enderezos da interface. Despois decides que táboa recibe que ruta, en código que poderás ler máis adiante.

Táboa de políticas fronte a reescribir a principal

A táboa separada é a única opción que escala máis alá dunha subrede. Dálle un nome unha vez e despois refírete a ela polo nome para que ninguén teña que lembrar un número:

echo "10 vpn" >> /etc/iproute2/rt_tables
ip rule add from 192.168.50.0/24 table vpn
ip route add default via 10.8.0.1 dev tun0 table vpn

Os enderezos de aquí son marcadores. Substituúe o prefixo LAN, a pasarela do túnel e o nome do dispositivo do teu propio despregamento antes de executar nada.

A regra tamén ten que coincidir co host

Unha regra que só coincide co prefixo LAN cobre os paquetes reenviados. Non cobre o tráfico que orixina a propia pasarela nin as respostas que envía aos clientes da LAN, que levan o enderezo LAN da pasarela como orixe. Esas consultas caen a main e aínda poden saír polo túnel.

Engade unha segunda regra para o enderezo LAN propio da pasarela ou amplía a primeira regra a un conxunto que inclúa ambas. A orde importa: pon primeiro a regra máis específica e comproba o resultado cunha consulta que nomee a orixe explicitamente.

ip route get 203.0.113.9 from 192.168.50.1

Se iso informa do dispositivo do túnel para un destino que debería quedar local, o conxunto de regras é incorrecto independentemente do que conteña a táboa.

NAT ou unha ruta no lado remoto

O servidor VPN coñece a subrede do túnel e nada máis. Os paquetes que chegan cun enderezo de orixe LAN non teñen camiño de volta a menos que alguén o proporcione, e hai exactamente dúas formas de proporcionalo. Engadir unha ruta para o prefixo LAN no servidor mantén a orixe orixinal visible de extremo a extremo, que é o que adoitaba querer un deseño auditado. A máscara na pasarela reescribe a orixe ao enderezo do túnel e non necesita ningunha cooperación do servidor.

iptables -t nat -A POSTROUTING -s 192.168.50.0/24 -o tun0 -j MASQUERADE

Escolle NAT cando non controlas o servidor e non podes engadir rutas alí. Escolle a ruta no lado do servidor cando importan os rexistros, o control de acceso ou a simetría do camiño de volta, porque a máscara borra o enderezo orixinal de todo o que rexistra o lado remoto.

En calquera caso, o reenvío ten que estar activado, e o filtrado estrito do camiño inverso pode descartar a resposta cando main non tería escollido o túnel para esa orixe. Comproba o valor efectivo antes de culpar o túnel.

Fai que a división sobreviva a unha reconexión

As regras e rutas engadidas a man desaparecen cando se recrea a interface, e unha entrada de táboa obsoleta pode sobrevivir á sesión que a xustificaba. Pon a regra de táboa, a ruta do túnel e a entrada de máscara dentro do script route-up do cliente, e baleira a táboa ao comezo do script para que unha pasarela antiga non poida sobrevivir á nova sesión.

Verifica desde ambos os extremos: unha consulta na pasarela coa orixe LAN e unha petición real dun cliente da LAN a un destino que deba atravesar o túnel. Unha ruta que existe pero nunca se selecciona compórtase exactamente como ningunha ruta ata que leas os contadores.