NAT da LAN a través de tun0 nunha pasarela VPN OpenBSD

Dous enxeñeiros coa mesma pasarela OpenBSD adoitan darte dous conxuntos de regras distintos para chegar a unha rede remota, e ambos se poden defender. A escolla entre tradución de orixe e unha ruta de retorno non é en absoluto unha cuestión de sintaxe. Depende do que o outro lado xa sabe sobre 192.168.88.0/24 e do que necesitas conservar nos teus rexistros. Se erras niso, a liña nat-to parecerá perfectamente correcta mentres as respostas desaparecen na pasarela predeterminada remota.

O encamiñamento e a reescritura responden a preguntas distintas

A táboa de encamiñamento decide que 172.20.0.0/16 é alcanzable por tun0, e esa decisión prodúcése antes de consultar calquera tradución de pf. A tradución de orixe cambia despois a cabeceira do paquete para que o extremo remoto vexa o enderezo do túnel da pasarela en lugar dunha máquina da LAN. Ningún dos dous mecanismos substitúe o outro: unha regra nat non pode facer xurdir unha ruta, e unha ruta non pode convencer un enrutador remoto que nunca oíu falar da túa subrede privada. Cando o lado remoto carece de camiño de retorno, as respostas descártanse ou envíanse cara á súa pasarela predeterminada, e ningunha cantidade de axuste de regras arranxa iso.

Dito claramente, o reenvío responde a onde vai o tráfico e a tradución responde de onde parece vir. Mantén ambos en caixas mentais separadas mentres deseñas o conxunto de regras.

Tres condicións que deciden

Fai tres preguntas en orde e o deseño adoita escollerse só. Ten a rede remota unha ruta estática que apunte ao enderezo do túnel para 192.168.88.0/24, ou o seu administrador controla os enrutadores dese camiño? Se si, deixa que os enderezos da LAN viaxen sen modificar e prescinde da tradución por completo. Necesitas visibilidade por cliente no lado remoto, xa sexa para política de acceso ou para unha pista de auditoría? Se si, conservar a orixe paga a pena o traballo de encamiñamento. É o enderezo do túnel abondo estable como para escribilo nunha ruta remota, ou cambia entre reconexións?

Se calquera resposta é non ou descoñecida, nat-to é a opción pragmática, e tamén a reversible. Unha regra de tradución sácase nunha só liña en canto o lado remoto engade unha ruta axeitada. Unha ruta de retorno que nunca se instalou costa che un fío de soporte cada vez que alguén pregunta por que o túnel só funciona nunha dirección.

Colocar o fragmento para que pf o avalíe de verdade

O fragmento seguinte asume que a LAN é 192.168.88.0/24, a rede remota é 172.20.0.0/16 e a interface do túnel é tun0. Nada nel escolle un seguinte salto. Só reescribe a orixe nos paquetes que xa saen polo túnel.

match out on tun0 inet from 192.168.88.0/24 to 172.20.0.0/16 nat-to (tun0)
pass in on em0 inet from 192.168.88.0/24 to any keep state

Dous detalles desa primeira liña levan a maior parte do peso. Os parénteses arredor de tun0 dínlle a pf que lea o enderezo da interface cada vez que constrúe unha entrada de estado, o que importa cando o túnel se renumera tras unha reconexión. A palabra match significa que a regra reescribe e despois continúa, así que unha regra pass separada aínda ten que admitir o fluxo. A interface nomeada na liña match tamén ten que ser a que selecciona a táboa de encamiñamento, ou pf avaliará a regra nun camiño de saída distinto do que o paquete toma realmente.

Non esquezas o lado do núcleo. O reenvío IPv4 ten que estar activado, e as regras pass con estado para túnel e LAN teñen que existir antes de que nada disto teña sentido. A sección PF NAT das preguntas frecuentes de OpenBSD é a referencia axeitada para a orde de palabras clave aquí.

Comproba o conxunto de regras antes de confiar no tráfico

Comproba primeiro a sintaxe con pfctl -nf /etc/pf.conf, que analiza o ficheiro sen cargalo. Despois carga a política e volve ler o que o núcleo ten realmente, porque unha regra que se analizou limpa aínda pode quedar tapada ou ligada á interface incorrecta. pfctl -sn imprime as regras de tradución na súa forma cargada, e pfctl -sr imprime as regras de filtrado en orde de avaliación.

Vixía despois o cable. Na pasarela, tcpdump -ni tun0 'host 172.20.0.10' mostra se o enderezo de orixe que sae do túnel é o do túnel ou o da máquina da LAN. Un rápido netstat -rn -f inet confirma a que interface se resolve o destino. Unha vez flúe o tráfico, pfctl -ss lista as entradas de estado; se un fluxo non produciu estado, o paquete nunca coincidiu cunha regra que o cree.

Se o lado do túnel parece correcto e as respostas aínda non chegan, deixa de editar pf. O fallo restante está no enrutador remoto, onde a resposta se envía cara a un enderezo privado que ese lado non pode alcanzar.

Cando a tradución custa máis do que aforra

A tradución agocha clientes, e ás veces ese é exactamente o intercambio equivocado. As subredes solapadas son un caso: se o lado remoto tamén usa 192.168.88.0/24 internamente, presentar as máquinas da LAN como a pasarela empeora a colisión en vez de mellorala. As políticas IPsec que seleccionan tráfico por par de enderezos son outro, porque a base de datos de política de seguridade se compara antes da tradución e nunca ve o teu paquete reescrito. Calquera despregamento que facture, limite ou audite por usuario tamén perde a identidade que necesita no momento en que a orixe se reduce a un enderezo.

Os derivados portátiles de pf son unha trampa aparte. Os produtos que xeran os seus propios ficheiros de regras esperan que NAT se configure a través da súa interface, e os fragmentos editados a man sobrescríbense na seguinte recarga. Os conxuntos de regras copiados de guías escritas antes de que existise a palabra clave match non cargarán nun núcleo actual, así que porta a sintaxe e le o erro en vez de adiviñar.

A regra de decisión que sobrevive ao contacto coas redes reais é curta: instala unha ruta de retorno cando poidas, traduce cando non poidas, e anota cal das tres condicións che fixo escoller. Ese apuntamento aforra unha tarde á próxima persoa.