iptables: deixeu que els clients VPN arribin a un sol equip i a res més

La regla que voleu és a FORWARD, no a INPUT. Admeteu una destinació per al pool de VPN, rebutgeu la resta i després demostreu-ho amb comptadors i una ordre de reversió.

Dos tiquets de suport que semblen sense relació resulten tenir una sola causa. Al primer, un administrador vol que el servidor accepti connexions només del túnel; al segon, els usuaris de VPN haurien d’arribar a un únic equip intern i a res més. Totes dues polítiques pertanyen a FORWARD, i totes dues s’intenten normalment a INPUT. El resultat sembla un tallafoc i es comporta com un farciment.

Quina cadena respon la vostra pregunta

Els paquets que un client VPN envia a un equip de la LAN, o més enllà cap a internet, els reenvia el nucli i s’avaluen a FORWARD. INPUT i OUTPUT només veuen el trànsit que acaba al servidor o que hi té origen. Per tant, un rebuig de tot el que no arriba per tun0 protegeix els propis oients del servidor, i també acabarà la vostra sessió SSH tret que primer s’admetin els fluxos establerts. No canvia res sobre on poden anar els clients.

Primer poseu nom a la pregunta: qui pot arribar al servidor, o on poden anar els clients. La majoria de xarxes necessiten les dues respostes, en cadenes diferents.

Primer l’estat, després el permís i després la negativa

Una llista d’admesos només funciona si el permís concret se situa per sobre de la negativa general i si el trànsit de tornada s’admet per sobre de tots dos. Inseriu les regles en posicions explícites i després aboqueu la cadena amb iptables -S FORWARD perquè l’ordre sigui visible i no suposat.

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

Dos detalls decideixen si això sobreviu al contacte amb trànsit real. Sense la regla d’estat, les respostes a les connexions que acabeu de permetre s’avaluen elles mateixes contra la negativa i es descarten. Una regla LOG sense límit pot esgotar una partició petita la primera vegada que un escaneig hi arriba, així que afegiu -m limit --limit 10/min abans de continuar registrant. REJECT retorna un error immediatament, cosa que és més amable mentre ajusteu la llista; DROP descarta en silenci, de manera que cada error es presenta com un temps d’espera exhaurit. Trieu-ne un a propòsit i escriviu l’elecció al registre de canvis.

El reenviament i el NAT ja han de funcionar

El filtratge no pot demostrar que existeixi un camí. Confirmeu primer que el nucli reenviï de tot, i feu aquest paràmetre persistent en lloc d’una ordre puntual de l’intèrpret. El filtre és l’última capa, no la primera.

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

On va l’emmascarament depèn d’on surten els clients. Si surten cap a una xarxa remota a través del túnel, la regla NAT va en aquesta interfície i no en la interfície WAN. Després mireu els comptadors: si el comptador de POSTROUTING no es mou mai mentre el recompte d’admesos a FORWARD puja, el camí de tornada està trencat i el filtre està bé. Aquesta lectura estalvia un migdia reescrivint regles que mai no eren el problema.

El bloc de correu pertany una cadena més enllà

Bloquejar el port 25 a INPUT només atura el correu adreçat al servidor VPN. Un client compromès que envia correu pel túnel es reenvia, així que el bloc ha de seure a FORWARD al costat de 465 i 587. Si una aplicació reenvia correu legítimament, poseu la seva destinació i el seu port per sobre d’aquesta regla.

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

Deixeu córrer el comptador de rebuigs una setmana abans de tensar res més. El nombre que deixa de pujar és el flux legítim que acabeu de trencar.

Torneu-ho a llegir i després demostreu-ho des d’un client

Llegiu el conjunt de regles tal com el reporta el nucli, no tal com el va escriure el vostre script. Comenceu amb iptables -S FORWARD, després la taula NAT amb iptables -t nat -L POSTROUTING -n -v, i després l’entrada de conntrack del flux que esteu provant. Mantingueu una ordre de reversió o un buidatge programat mentre duri la feina. Cada invocació necessita -w, o dos administradors xocaran al pany d’xtables. Res d’això no és opcional durant una finestra de canvi.

Acabeu provant des d’un client dins del pool i des d’un de fora. Una regla que només funciona des de la màquina on l’heu escrita no és una política.

Articles relacionats