iptables: deixe que os clientes VPN cheguen a un só equipo e a nada máis

A regra que precisa está en FORWARD, non en INPUT. Admite un destino para o grupo de VPN, rexeita o resto e despois demóstrao con contadores e unha orde de reversión.

Dous tickets de soporte que parecen non ter relación resultan compartir unha causa. No primeiro, un administrador quere que o servidor acepte conexións só do túnel; no segundo, os usuarios de VPN deberían chegar a un único equipo interno e a nada máis. Ambas as políticas pertencen a FORWARD, e ambas se adoitan tentar en INPUT. O resultado parece un cortalumes e compórtase como un marcador de posición.

Que cadea responde á túa pregunta

Os paquetes que un cliente VPN envía a un equipo da LAN, ou máis alá cara a internet, reenvíaos o núcleo e avalíanse en FORWARD. INPUT e OUTPUT só ven o tráfico que remata no servidor ou que se orixina nel. Por iso, un rexeitamento para todo o que non chega por tun0 protexe os propios oíntes do servidor e ademais rematará a túa sesión SSH salvo que primeiro se admitan os fluxos establecidos. Non cambia nada sobre onde poden ir os clientes.

Primeiro ponlle nome á pregunta: quen pode chegar ao servidor, ou onde poden ir os clientes. A maioría das redes necesita ambas as respostas, en cadeas distintas.

Primeiro o estado, despois o permiso e despois a negativa

Unha lista de permitidos só funciona se o permiso concreto queda por riba da negativa xeral e se o tráfico de volta se admite por riba de ambos. Insire as regras en posicións explícitas e despois volca a cadea con iptables -S FORWARD para que a orde sexa visible e non suposta.

POOL=10.99.0.0/24
iptables -I FORWARD 1 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -I FORWARD 2 -s "$POOL" -d 172.31.20.15 -p tcp -m multiport --dports 443,3389 -j ACCEPT
iptables -I FORWARD 3 -s "$POOL" -j REJECT

Dous detalles deciden se isto sobrevive ao contacto con tráfico real. Sen a regra de estado, as respostas ás conexións que acaba de permitir avalíanse elas mesmas contra a negativa e descártanse. Unha regra LOG sen límite pode esgotar unha partición pequena a primeira vez que unha análise a acada, así que engade -m limit --limit 10/min antes de seguir rexistrando. REJECT devolve un erro de inmediato, o que resulta máis amable mentres axusta a lista; DROP descarta en silencio, así que cada erro se presenta como un tempo de espera esgotado. Escolle un a propósito e escribe a escolla no rexistro de cambios.

O reenvío e o NAT xa deben funcionar

O filtrado non pode demostrar que exista un camiño. Confirma primeiro que o núcleo reenvía sequera, e fai ese axuste persistente en lugar dunha orde puntual na consola. O filtro é a última capa, non a primeira.

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s "$POOL" -o eth0 -j MASQUERADE

Onde vai o enmascaramento depende de por onde saen os clientes. Se saen cara a unha rede remota a través do túnel, a regra NAT vai nesa interface e non na interface WAN. Despois mira os contadores: se o contador de POSTROUTING nunca se move mentres o número de admisións en FORWARD sobe, o camiño de volta está roto e o filtro está ben. Esa lectura aforra unha tarde reescribindo regras que nunca foron o problema.

O bloque de correo pertence unha cadea máis alá

Bloquear o porto 25 en INPUT só detén o correo dirixido ao servidor VPN. Un cliente comprometido que envía correo polo túnel reenvíase, así que o bloque debe estar en FORWARD xunto a 465 e 587. Se unha aplicación retransmite correo de forma lexítima, pon o seu destino e o seu porto por riba desa regra.

iptables -I FORWARD 2 -s "$POOL" -p tcp -m multiport --dports 25,465,587 -j REJECT

Deixa correr o contador de rexeitamentos unha semana antes de apertar calquera outra cousa. O número que deixa de subir é o fluxo lexítimo que acaba de romper.

Volve lelo e despois demóstrao desde un cliente

Le o conxunto de regras tal como o informa o núcleo, non como o escribiu o teu script. Comeza con iptables -S FORWARD, despois a táboa NAT con iptables -t nat -L POSTROUTING -n -v, despois a entrada de conntrack do fluxo que estás probando. Mantén unha orde de reversión ou un baleirado programado mentres dure o traballo. Cada invocación necesita -w, ou dous administradores chocarán no bloqueo de xtables. Nada diso é opcional durante unha xanela de cambios.

Remata probando desde un cliente dentro do grupo e desde un fóra del. Unha regra que só funciona desde a máquina onde a escribiches non é unha política.

Artigos relacionados