Introducción
La aplicación de pedidos de Corner Shop lee y crea registros en una base PostgreSQL privada. Su página funciona, pero Visitor también puede acceder directamente a la base. Que una aplicación funcione no demuestra que su límite de red sea seguro.
Compararás conexiones reales, restringirás el reenvío en Gateway y conservarás los pedidos y un servicio público de estado. Solo se requiere uso básico del terminal. Personas y registros son sintéticos. Los tres nodos de terminal son contenedores con espacios de nombres de red separados que comparten el núcleo de una instancia, no máquinas virtuales independientes.
Sigue un pedido y su ruta de red
En este paso crearás un pedido real y compararás dos rutas a su base. La aplicación es el programa orientado al cliente; la base guarda sus registros. Abre Order Page, busca seed: Green tea, escribe practice-1 en Order reference y pulsa Create tea order. La nueva fila se almacena en PostgreSQL, no solo en la página.
El mapa muestra la dirección IP de cada nodo, que identifica un destino de red. Un puerto identifica un servicio en esa dirección. PostgreSQL escucha en 172.28.20.10:5432; el servicio público independiente usa 8001. App Client (172.28.10.20) necesita la base. Visitor (172.28.10.30) solo necesita el estado público.
Cambia a App Client. La herramienta preparada tcp-probe abre una conexión TCP real y espera como máximo tres segundos. Sus argumentos son dirección de destino y puerto:
tcp-probe 172.28.20.10 5432
Espera TCP OPEN. Demuestra accesibilidad, no permiso para leer registros. psql es el cliente de consultas de PostgreSQL. Este comando proporciona la contraseña de entrenamiento solo a esa ejecución. La cadena entre comillas agrupa servidor, puerto, usuario, base y tiempo de conexión de tres segundos. -c ejecuta el SQL entre comillas; SELECT lee las columnas indicadas de orders y ORDER BY las ordena. El punto y coma termina la sentencia.
PGPASSWORD=training-only psql "host=172.28.20.10 port=5432 user=shopapp dbname=shop connect_timeout=3" -c "SELECT id, item FROM orders ORDER BY id;"
Busca practice-1 y Green tea. La credencial deliberadamente conocida permanecerá igual para aislar el cambio de red.
Cambia a Visitor y repite ambos comandos:
tcp-probe 172.28.20.10 5432
PGPASSWORD=training-only psql "host=172.28.20.10 port=5432 user=shopapp dbname=shop connect_timeout=3" -c "SELECT id, item FROM orders ORDER BY id;"
Ambos funcionan: el cliente no previsto puede conectarse y leer pedidos sintéticos. Una contraseña incorrecta produciría un error de autenticación después de alcanzar PostgreSQL; el puerto seguiría expuesto.
Una ruta indica dónde enviar paquetes. Consulta la ruta preparada de Visitor a la base:
ip route get 172.28.20.10
Los campos importantes son via 172.28.10.254 (Gateway) y src 172.28.10.30 (Visitor). App Client usa la misma puerta de enlace con otro origen. La ruta de retorno de la base apunta a la otra interfaz de Gateway, 172.28.20.254. Ningún cliente tiene una interfaz directa a la red de la base. Las rutas son infraestructura preparada: no las cambies. El pedido real es el punto de control; no debes entregar un informe.
Permite solo la ruta de la aplicación a la base
En este paso filtrarás los paquetes que atraviesan Gateway. Cambia a Gateway. iptables modifica reglas del filtro de paquetes del núcleo. Una cadena es una lista ordenada: gana la primera decisión coincidente. FORWARD procesa tráfico que atraviesa el nodo; INPUT corresponde al dirigido al propio nodo. El entorno conecta FORWARD con la cadena del laboratorio LAB_FORWARD; su regla inicial permisiva permite la exposición.
Consulta las reglas. -n conserva direcciones numéricas, -v incluye contadores y -L lista la cadena:
iptables -nvL LAB_FORWARD
Modifica solo LAB_FORWARD en este terminal. Conserva reglas del host, rutas, credenciales y servicios. Las reglas se aplican inmediatamente y duran esta sesión. Sustituiremos la regla permisiva por cuatro decisiones. La cadena superior preparada deniega lo que quede sin coincidencia.
-F vacía esta cadena. Los servicios reenviados se bloquean brevemente mientras añades reglas; el terminal y la interfaz Order Page siguen accesibles. Si cometes un error, vuelve a este vaciado y escribe las cuatro reglas completas.
iptables -F LAB_FORWARD
Las respuestas también deben volver. Por ejemplo, la respuesta de la base viaja hacia App Client y su destino ya no es el puerto de la base. -A añade al final, -m conntrack usa seguimiento de conexiones y --ctstate ESTABLISHED,RELATED identifica respuestas o tráfico relacionado con conexiones ya permitidas. -j ACCEPT permite el paquete coincidente:
iptables -A LAB_FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
Permite ahora conexiones nuevas de la aplicación. -s indica origen, -d destino, -p tcp selecciona TCP y --dport el puerto de destino. Una dirección individual representa exactamente ese nodo:
iptables -A LAB_FORWARD -s 172.28.10.20 -d 172.28.20.10 -p tcp --dport 5432 -j ACCEPT
Sitúa el rechazo general de la base después de la excepción de la aplicación. Sin -s, cubre otros orígenes. REJECT --reject-with tcp-reset rechaza explícitamente TCP en vez de esperar un tiempo de espera:
iptables -A LAB_FORWARD -d 172.28.20.10 -p tcp --dport 5432 -j REJECT --reject-with tcp-reset
Por último, conserva el puerto público independiente para ambos clientes. Permitirlo no expone el puerto de la base:
iptables -A LAB_FORWARD -d 172.28.20.10 -p tcp --dport 8001 -j ACCEPT
Lista el resultado:
iptables -nvL LAB_FORWARD
Lee el orden: respuestas, acceso de la aplicación, rechazo general de la base y acceso al estado público. Un rechazo anterior a la excepción bloquearía también la tienda. Los contadores solo aumentan cuando tráfico coincidente cruza Gateway; la presencia de una regla no es prueba suficiente. Actualiza Order Page: App Client debe mostrar OPEN, Visitor BLOCKED, el estado PUBLIC STATUS OK y los pedidos deben seguir cargándose.
Vuelve a probar la seguridad y la tienda
En este paso confirmarás la matriz de conexiones y completarás otro pedido real. Cambia a App Client y abre una conexión nueva:
tcp-probe 172.28.20.10 5432
Espera TCP OPEN. Repite la lectura con la misma credencial:
PGPASSWORD=training-only psql "host=172.28.20.10 port=5432 user=shopapp dbname=shop connect_timeout=3" -c "SELECT id, item FROM orders ORDER BY id;"
Cambia a Visitor:
tcp-probe 172.28.20.10 5432
Espera TCP BLOCKED y una explicación de conexión rechazada. Este comando devuelve un fallo intencionadamente. Un descarte silencioso produce un tiempo de espera; ambos impiden una conexión nueva, pero un tiempo de espera por sí solo no identifica la causa. Si App Client también falla, revisa el orden y las respuestas en Gateway.
curl recupera un recurso web. --max-time 4 limita la solicitud completa a cuatro segundos; -f trata errores HTTP como fallos, -s oculta el progreso y -S conserva los errores. Desde Visitor, prueba el servicio público diferente:
curl --max-time 4 -fsS http://172.28.20.10:8001/status.txt
Espera PUBLIC STATUS OK. Bloquear todos los paquetes reenviados incumpliría este requisito aunque cerrara la ruta a la base.
Abre Order Page, crea practice-2 y confirma que aparecen ambos pedidos. Esto usa la conexión real de la aplicación después de la reparación. Actualiza otra vez: Visitor debe seguir bloqueado. Los contadores ayudan a diagnosticar diferencias, pero el pedido y las pruebas de permitir/bloquear son la evidencia real. No detengas PostgreSQL ni cambies su contraseña para hacer que una consulta fallida parezca una reparación de seguridad.
Resumen
Seguiste un pedido hasta PostgreSQL, comparaste dos clientes enrutados, aplicaste reglas de reenvío ordenadas y probaste seguridad y disponibilidad. Un error de contraseña es distinto de una conexión TCP bloqueada. Al cerrar una ruta expuesta, conserva la aplicación prevista y los demás servicios.
