Abrir o porto VPN non fai que os clientes cheguen á LAN

O túnel levanta, o cliente autentícase e a LAN detrás da pasarela segue invisible. A regra que debía corrixilo permite o porto VPN e funciona exactamente como está escrita, porque esa regra goberna os paquetes dirixidos á propia pasarela. O tráfico do cliente cara a un host detrás da pasarela ten outro destino e outra cadea. Un inicio de sesión correcto non cambia cal das dúas cadeas consulta o núcleo.

Dúas cadeas, dous destinos distintos

O destino dun paquete decídeo cara a onde vai, non como chegou. O tráfico dirixido a un enderezo da pasarela entrégase localmente e avalíase coas regras de entrada. O tráfico que a pasarela reenvía avalíase coas regras de reenvío. A mesma interface de túnel pode producir ambos os tipos de paquete, por iso unha soa regra non pode cubrir as dúas tarefas.

Todo o mito nunha frase: permitir o escoitante non di nada sobre permitir a rede que está detrás. Son dúas decisións separadas con probas separadas, e un nome de interface nas dúas non as fusiona.

Que admite realmente a regra do escoitante

Os paquetes do escoitante rematan no proceso VPN, e iso é o que permite establecer o túnel. A páxina de administración da pasarela e unha resposta de diagnóstico local tamén usan a ruta de entrada do propio host, por iso unha proba cara á pasarela funciona mentres todo o que está detrás falla. Ambos os resultados son correctos e ningún trata da LAN.

Cando o proceso desencapsula o tráfico do cliente para outro destino, o paquete entra na ruta de reenvío e alí necesita permiso. A autenticación correcta resolve quen é o cliente; non resolve a onde pode ir. As dúas preguntas teñen donos distintos, rexistros distintos e mensaxes de erro distintas.

Probe desde un cliente, nunca desde a pasarela

Unha proba xerada na pasarela segue a ruta de saída do propio host e pode pasar mentres a ruta reenviada está pechada. Comece a proba desde o cliente e observe ambos os extremos do fluxo.

nc -vz 10.40.7.25 445
tcpdump -ni tun0 host 10.40.7.25

Se a petición aparece en tun0 e nada chega ao destino, o paquete descártase tras a chegada, o que apunta ás regras de reenvío ou ao filtrado propio do destino. Se non aparece nada en tun0, o cliente nin sequera a envía ao túnel, e o problema é o encamiñamento no cliente e non a política na pasarela. Compáreo cunha petición que sae correctamente e non devolve nada, que é o caso da ruta de volta.

O reenvío necesita tres cousas, non unha

O reenvío do núcleo debe estar activado, unha regra de filtro debe aceptar o fluxo e o destino debe ser alcanzable cun camiño para que volva a resposta. Se falta unha das tres, o silencio é o mesmo desde o punto de vista do cliente.

sysctl net.ipv4.ip_forward
sudo iptables -S FORWARD
sudo iptables -S INPUT

Lea as tres saídas xuntas. Un cero na primeira fai irrelevantes as outras dúas, e unha política de descarte por defecto na segunda descarta os paquetes do cliente mentres o tráfico propio da pasarela segue funcionando. A terceira saída mostra por que a regra do escoitante nunca foi o problema.

Manteña os dous conxuntos de regras separados na documentación

Escriba a regra do escoitante e a regra do servizo reenviado en liñas separadas, con donos e motivos separados. Cando cambia o porto VPN ou se publica un servizo novo, esa separación evita que un cambio amplíe en silencio o outro.

En lugar de tratar cada par autenticado como un membro de confianza da LAN, use regras estreitas para os rangos de clientes e os servizos que as necesitan. As notas de reenvío de StrongSwan describen o lado de ruta de volta e de tradución da mesma fronteira, que é outra terceira decisión.

Por último, manteña as capas rectas cando se rexeita un usuario. Se a petición chega ao host e a aplicación rexeita a conta, repare o permiso da aplicación nesa capa; ampliar o reenvío non pode proporcionar unha credencial de compartición de ficheiros e ampliará o acceso para todos os demais que se conecten correctamente.