Puerto p\u00fablico con filtro por IP<\/strong>: nuestro caso. Un cliente externo (una instancia de phpMyAdmin en otro servidor) tiene que poder conectarse.<\/li>\n<\/ol>\nPara el caso 4 hace falta un cortafuegos que filtre correctamente el tr\u00e1fico de los puertos publicados por Docker.<\/p>\n
4. Segundo problema: error de iptables al arrancar<\/h2>\n
Despu\u00e9s de tocar el cortafuegos, docker compose up<\/code> devolvi\u00f3.<\/p>\nfailed to create network mysql57_default: Error response from daemon:\nFailed to Setup IP tables: Unable to enable ACCEPT OUTGOING rule:\n(iptables failed: iptables --wait -t filter -A DOCKER-FORWARD -i br-... -j ACCEPT:\niptables: No chain\/target\/match by that name.\n<\/code><\/pre>\nEl error no depende del compose: la cadena DOCKER-FORWARD<\/code> (introducida en las versiones recientes de Docker) ya no exist\u00eda. La hab\u00eda borrado algo que limpi\u00f3 las reglas despu\u00e9s<\/strong> de arrancar el demonio. Reiniciar Docker (systemctl restart docker<\/code>) la recrea, pero el problema reaparece mientras no se elimine al verdadero culpable.<\/p>\nEl culpable: flush ruleset<\/code><\/h3>\nNuestro \/etc\/nftables.conf<\/code> empezaba con.<\/p>\nflush ruleset\n<\/code><\/pre>\nEste comando borra todas<\/strong> las tablas de nftables, incluidas las creadas por Docker. Adem\u00e1s, el archivo conten\u00eda una copia est\u00e1tica de las reglas de Docker. Llevaba el nombre del bridge (br-278550235c3f<\/code>) y la IP del contenedor (172.18.0.2<\/code>) escritos a mano. Pero el nombre del bridge cambia cada vez que se recrea la red de Compose. As\u00ed, la copia quedaba obsoleta enseguida, y la tabla ip nat<\/code> entraba en conflicto con la gestionada por Docker.<\/p>\nRegla de oro:<\/strong> con Docker, en el archivo de nftables no se usa flush ruleset<\/code> y no se copian sus reglas. Solo se gestiona el cortafuegos propio, en tablas dedicadas.<\/p>\n5. El cortafuegos para MySQL 5.7 en Docker<\/h2>\n
El principio es este. Los puertos publicados por Docker se reescriben con DNAT y luego el host los reenv\u00eda al contenedor. As\u00ed, atraviesan la cadena forward<\/code><\/strong>, no input<\/code>. Una regla drop<\/code> en una cadena nuestra, forward<\/code>, con una prioridad ligeramente m\u00e1s baja (es decir, evaluada antes) descarta el paquete sin importar las reglas accept<\/code> de Docker.<\/p>\nPara no tocar las tablas ajenas usamos el patr\u00f3n table ...<\/code> + delete table ...<\/code>: hace que el archivo se pueda volver a ejecutar sin errores y sin flush<\/code>.<\/p>\n\/etc\/nftables.conf<\/code>.<\/p>\n#!\/usr\/sbin\/nft -f\n\n# NIENTE \"flush ruleset\": cancellerebbe anche le tabelle di Docker\n\n# ---------------- firewall host ----------------\ntable inet filter\ndelete table inet filter\n\ntable inet filter {\n\n chain input {\n type filter hook input priority filter; policy drop;\n ct state established,related accept\n iifname \"lo\" accept\n ip6 nexthdr icmpv6 accept\n iifname \"enp7s0\" accept # rete privata\n ip saddr 203.0.113.20 tcp dport 22 accept # SSH da host fidato\n ip saddr 203.0.113.30 tcp dport 22 accept # SSH da VPN\n ip saddr 203.0.113.20 icmp type echo-request accept\n tcp dport { 80, 443 } accept\n }\n\n chain output {\n type filter hook output priority filter; policy accept;\n }\n}\n\n# ---------------- guardia MySQL (porta pubblicata da Docker) ----------------\ntable ip mysql_guard\ndelete table ip mysql_guard\n\ntable ip mysql_guard {\n set allowed {\n type ipv4_addr\n flags interval\n elements = {\n 203.0.113.10 # phpMyAdmin\n }\n }\n\n chain forward {\n type filter hook forward priority filter - 5; policy accept;\n iifname \"enp7s0\" accept\n ct status dnat tcp dport 3306 ip saddr @allowed accept\n ct status dnat tcp dport 3306 counter drop\n }\n}\n<\/code><\/pre>\nC\u00f3mo funciona la guardia.<\/p>\n
\nct status dnat<\/code> selecciona solo los paquetes que han pasado por el DNAT, es decir, los dirigidos a los puertos publicados por Docker.<\/li>\n- La primera regla acepta a quien est\u00e9 en el conjunto
allowed<\/code>. La segunda descarta a todos los dem\u00e1s y los cuenta (counter<\/code>).<\/li>\n- El tr\u00e1fico local (
127.0.0.1<\/code>) y el que va entre contenedores de la misma red no pasa por el forward del router. As\u00ed que no se toca.<\/li>\n<\/ul>\n\nCompatibilidad:<\/strong> en una primera versi\u00f3n us\u00e1bamos ct original proto-dst 3306<\/code>. Pero algunas versiones de nft<\/code> responden con \u00abCan’t parse symbolic invalid expressions\u00bb<\/em>. En el hook forward<\/code> el DNAT ya ha ocurrido y el puerto del contenedor coincide con el publicado (3306:3306<\/code>). Por eso tcp dport 3306<\/code> combinado con ct status dnat<\/code> es equivalente y funciona en todas partes. Si cambias el mapeo (p. ej. 3307:3306<\/code>), la regla debe adaptarse al puerto interno.<\/p>\n<\/blockquote>\nAplicar los cambios sin quedarse fuera<\/h3>\n
Mant\u00e9n abierta una sesi\u00f3n SSH de reserva y despu\u00e9s.<\/p>\n
nft -c -f \/etc\/nftables.conf # solo verifica della sintassi\nnft delete table ip nat # una tantum: elimina la vecchia copia statica\nnft -f \/etc\/nftables.conf\nsystemctl restart docker # Docker ricrea le sue tabelle pulite\ncd \/opt\/mysql57 && docker compose up -d\n<\/code><\/pre>\nPara la carga en el arranque, aseg\u00farate de que el servicio est\u00e9 activo (systemctl enable --now nftables<\/code>). Comprueba tambi\u00e9n que \/etc\/nftables.conf<\/code> no contenga flush ruleset<\/code>.<\/p>\nGestionar las IP en tiempo de ejecuci\u00f3n<\/h3>\nnft add element ip mysql_guard allowed { 203.0.113.50 }\nnft delete element ip mysql_guard allowed { 203.0.113.50 }\n<\/code><\/pre>\nPara hacerlo permanente, actualiza tambi\u00e9n el conjunto en el archivo.<\/p>\n
6. Verificaci\u00f3n del acceso a MySQL 5.7 en Docker<\/h2>\n
Desde el servidor autorizado.<\/p>\n
nc -zv IP_PUBBLICO_DB 3306 # deve rispondere \"succeeded\"\n<\/code><\/pre>\nDesde cualquier otra IP.<\/p>\n
nmap -Pn -p 3306 IP_PUBBLICO_DB # deve risultare \"filtered\" \/ timeout\n<\/code><\/pre>\nEn el servidor, el contador de la regla de descarte debe crecer con cada intento no autorizado.<\/p>\n
nft list chain ip mysql_guard forward\nss -tlnp | grep 3306\n<\/code><\/pre>\n7. Segunda barrera: los usuarios de MySQL<\/h2>\n
El cortafuegos no sustituye los permisos de la base de datos. Crea el usuario con el host limitado a la IP del cliente.<\/p>\n
CREATE USER 'pma_user'@'203.0.113.10' IDENTIFIED BY 'password_robusta';\nGRANT ALL ON nome_db.* TO 'pma_user'@'203.0.113.10';\nFLUSH PRIVILEGES;\n<\/code><\/pre>\nSi la conexi\u00f3n TCP se establece pero MySQL responde Access denied<\/code>, el problema est\u00e1 aqu\u00ed y no en el cortafuegos.<\/p>\n
![\"MySQL](\"https:\/\/www.cisilino.com\/wp-content\/uploads\/2026\/10\/mysql-5-7-docker-nftables-cortafuegos.webp\")
<\/figure>\n