WiFi profesional para restaurantes: guía técnica 2026

WiFi profesional es diseño, operación y prueba

Cuando un POS deja de responder durante servicio, la causa puede estar en el proveedor de internet, ONT, DNS, DHCP, firewall, switch, alimentación, radiofrecuencia, autenticación, aplicación local o nube. “El WiFi está lento” no identifica el dominio de fallo.

Una WLAN profesional para restaurantes empieza con dependencias y objetivos medibles. Después diseña radio, cableado, segmentación, energía, redundancia, observabilidad y procedimientos.

Tres capas distintas: SSID presenta acceso a una WLAN; VLAN separa dominios de capa 2; firewall o ACL decide qué tráfico puede cruzar. Ninguna por sí sola demuestra aislamiento ni cumplimiento.

Mapea el servicio completo

Haz un inventario de aplicaciones, dispositivos y dependencias:

POS local o en nube;
terminales y entorno de datos de tarjeta;
KDS e impresoras;
reservas y pedidos;
inventario y cava;
dispositivos administrados del personal;
teléfonos personales o BYOD;
cámaras, sensores, audio e IoT;
WiFi de huéspedes;
DNS, DHCP, NTP y autenticación;
enlace WAN, módem/ONT y proveedor;
firewall, switches, controladores y AP;
PoE y alimentación eléctrica.

Por cada función pregunta:

¿necesita internet o solo red local?
¿puede operar offline?
¿qué ocurre si cambia la IP?
¿requiere descubrimiento entre VLAN?
¿qué destinos y puertos necesita?
¿quién es responsable?
¿cuánto tiempo puede estar indisponible?

Una impresora puede seguir operando localmente durante una caída WAN, mientras un POS cloud no. Un failover celular no resuelve un switch sin energía.

Define objetivos medibles

No compres “WiFi 6 para 300 dispositivos” sin criterios. Define:

cobertura en áreas de trabajo;
capacidad durante hora pico;
latencia, pérdida y variación tolerables por aplicación;
tiempo de asociación y roaming;
disponibilidad por servicio;
tiempo de detección y recuperación;
autonomía de UPS;
funciones offline;
número de dispositivos concurrentes por tipo;
crecimiento y eventos especiales.

Los valores deben venir de requisitos de aplicaciones, pruebas y riesgo. Una cifra genérica de Mbps o clientes del fabricante no representa airtime, paredes, interferencia ni patrón de uso.

Levantamiento físico y RF

Antes de ubicar AP:

consigue un plano actualizado;
marca comedor, cocina, barra, patios, cámaras frías, almacenes y oficinas;
registra materiales: concreto, metal, vidrio, azulejo y agua;
ubica fuentes de interferencia y equipos que operan en bandas cercanas;
identifica puntos con Ethernet y energía PoE;
mide durante condiciones representativas;
realiza encuesta predictiva, pasiva y activa según alcance;
valida después de instalar.

La resiliencia se demuestra desconectando enlaces y energía de forma controlada, observando failover y retorno.

Una medición con el restaurante vacío no reproduce cuerpos, puertas, vapor, cocina, dispositivos ni airtime de servicio. Programa una validación en hora representativa sin interrumpir la operación.

Dimensiona por airtime y aplicación

En WiFi, todos los clientes de una radio comparten tiempo de aire. Un dispositivo con señal débil o reintentos puede consumir más airtime que uno que transfiere más datos a buena modulación.

Considera:

dispositivos concurrentes, no solo registrados;
tráfico de subida y bajada;
tamaño y frecuencia de paquetes;
voz, video, impresión y transacciones;
banda soportada por cada cliente;
canales disponibles y ocupación;
ancho de canal;
potencia y solapamiento;
roaming;
reintentos y ruido;
balance entre radios.

Cisco recomienda diseñar capacidad muy por debajo del máximo teórico de clientes por radio. No copies un número como umbral universal: depende del caso y del SLA.

Canales más anchos ofrecen mayor tasa potencial y consumen más espectro. En entornos densos, un ancho menor puede facilitar reutilización. La selección debe surgir del survey.

Bandas: evita reglas simplistas

No fuerces “operación en 5 GHz, clientes en 2.4 GHz” sin revisar compatibilidad y cobertura.

2.4 GHz tiene menos canales no solapados y mayor alcance relativo; muchos dispositivos heredados e IoT dependen de ella.
5 GHz ofrece más opciones de canal y suele ser preferible para capacidad, con diferente propagación.
6 GHz exige clientes compatibles y tiene reglas y alcance propios.

Usa band steering y políticas solo después de probar los clientes. Un POS que pierde asociación al forzarlo a una banda no es una mejora.

Diseña zonas de confianza

Una arquitectura típica separa:

POS y pagos: sistemas del entorno de tarjetas o conectados a él.
Administración gestionada: dispositivos corporativos autorizados.
Operación no-pago: inventario, KDS u otros, según riesgo.
IoT, cámaras e impresoras: dispositivos de capacidad y parcheo limitados.
BYOD del personal: equipos personales sin confianza.
Huéspedes: internet con aislamiento de clientes.

No agrupes cámaras y POS solo porque ambos son “operativos”. Una cámara comprometida no debería tener ruta al entorno de pagos.

No todas las zonas requieren un SSID visible distinto. Puede usarse asignación dinámica de VLAN o roles. Cisco advierte que cada SSID añade beacons y probe responses, consumiendo airtime; mantén los mínimos compatibles con operación.

SSID, VLAN y firewall

SSID

Es el nombre o identificador de la WLAN. Ocultarlo no es una medida de seguridad: clientes y tráfico de gestión pueden revelar su existencia, y añade complejidad.

VLAN

Separa dominios de capa 2 y ayuda a segmentar. No bloquea tráfico por sí sola si el routing y firewall lo permiten.

Firewall o ACL

Define flujos permitidos. Empieza con denegación y añade lo necesario:

POS hacia procesador y servicios autorizados;
impresora desde servidor o terminales específicos;
IoT hacia su nube, sin acceso lateral;
huéspedes solo hacia internet;
administración desde estaciones y VPN autorizadas.

Prueba desde cada zona que los flujos prohibidos realmente fallen. Una etiqueta de VLAN en el diagrama no prueba la configuración desplegada.

Autenticación y acceso

WPA3-Enterprise con 802.1X y credenciales por usuario o dispositivo ofrece revocación y trazabilidad cuando los clientes lo soportan. Equipos heredados pueden exigir alternativas:

claves por dispositivo o PPSK;
VLAN restringida;
acceso solo a destinos mínimos;
aislamiento y monitoreo;
plan de reemplazo.

Una PSK compartida se filtra y dificulta revocar a una persona. Cambiarla cada trimestre no resuelve la identidad. Una allowlist MAC tampoco auténtica fuertemente: las direcciones pueden observarse o falsificarse.

Para huéspedes, habilita aislamiento de clientes y límites de abuso. El portal cautivo no cifra por sí mismo el tráfico ni convierte una red abierta en segura.

Cablea lo que puedas

Ethernet reduce dependencia del medio compartido para equipos fijos:

terminal POS fija;
firewall y switches;
AP;
impresoras y KDS;
cámaras;
controladores y servidores locales.

Usa cableado y terminación certificados, etiquetado en ambos extremos, patch panel y pruebas. Evita switches no gestionados escondidos sin inventario.

PoE centraliza energía y permite respaldar AP mediante UPS del switch. Calcula presupuesto PoE total y por puerto, incluyendo arranque y crecimiento.

WAN, DNS y operación offline

Un enlace rápido no garantiza continuidad. Diseña:

proveedor primario;
segundo enlace con diversidad real cuando el riesgo lo justifique;
respaldo celular con cobertura y plan de datos;
DNS redundante y monitoreado;
rutas y servicios que pueden usar el backup;
límites para cámaras, actualizaciones y huéspedes durante failover;
funciones offline del POS;
procedimientos manuales seguros.

Dos ISP pueden compartir la misma fibra o ducto. Pregunta por diversidad física y prueba.

El failover cambia la IP pública y puede cortar sesiones. Algunos pagos o túneles requieren reconexión. Cisco Meraki documenta que la detección depende de pruebas y umbrales y que fallas suaves pueden tardar. Mide tu configuración.

Energía y UPS

Respalda el camino completo:

ONT o módem;
firewall;
switch PoE;
AP críticos;
controlador o servidor local;
POS fijo cuando aplique.

Una UPS solo en el firewall no sirve si el ONT y switch se apagan. Calcula carga, autonomía, baterías y apagado ordenado.

Prueba:

corte de WAN primario;
transición a secundario;
transacción y servicios permitidos;
retorno al primario;
corte eléctrico controlado;
autonomía y alertas;
recuperación después de agotar batería.

Documenta qué sesiones se perdieron. “El indicador cambió a verde” no demuestra continuidad del POS.

Observabilidad útil

Supervisa por servicio y capa:

RF

utilización de canal;
ruido, RSSI y SNR según diseño;
reintentos;
tasa de datos y modulación;
clientes por radio;
roaming y desconexiones;
interferencia.

Red local

errores y descartes por puerto;
consumo PoE;
DHCP y agotamiento de pool;
resolución DNS;
latencia entre VLAN permitidas;
estado de AP y switch.

WAN y aplicación

pérdida y latencia a destinos relevantes;
estado de enlaces;
uso y antigüedad del failover;
prueba sintética de la ruta al POS;
colas offline de aplicaciones;
tiempo de respuesta del proveedor cloud.

No dependas solo de ping al gateway. Puede responder aunque DNS, autenticación o la aplicación estén caídos.

Runbook e incidentes

El procedimiento debe decir:

quién recibe la alerta;
cómo distinguir RF, LAN, WAN y aplicación;
qué métricas y logs conservar;
cómo activar contingencia;
cómo escalar a ISP, integrador o proveedor POS;
qué cambios están prohibidos durante servicio;
cómo comunicar al equipo;
cómo restaurar y validar;
cómo documentar causa y acción.

Incluye contactos, números de circuito, inventario, diagrama, respaldos y ubicación segura de credenciales. Prueba el runbook con ejercicios.

Cambios de firmware y configuración

“Actualizar automáticamente” puede reiniciar AP en servicio. Define:

ventana de mantenimiento;
revisión de notas y vulnerabilidades;
laboratorio o grupo piloto;
respaldo de configuración;
compatibilidad de clientes;
criterio de éxito;
rollback;
monitoreo posterior.

No congeles firmware indefinidamente. Gestiona riesgo, no improvises.

PCI DSS: segmentación y alcance

PCI DSS v4.0.1 es la versión publicada por PCI SSC. El alcance depende de dónde se almacenan, procesan o transmiten datos de tarjetas y qué sistemas pueden afectar su seguridad.

La FAQ 1115 de PCI SSC explica que, sin segmentación adecuada, toda la red puede quedar dentro de alcance. Cuando se usa segmentación para reducirlo, debe verificarse que sea efectiva y que no exista ruta desde redes fuera de alcance hacia el entorno de datos de tarjetas.

Por tanto:

“tenemos una VLAN POS” no equivale a cumplimiento;
una red de huéspedes separada por SSID no demuestra aislamiento;
firewall, rutas, servicios compartidos y administración importan;
la segmentación necesita pruebas;
confirma alcance con adquirente, QSA/ISA u otro asesor competente.

Esta guía no determina la elegibilidad de un SAQ ni sustituye una evaluación PCI.

Portal cautivo y privacidad

Un portal puede mostrar términos o pedir datos, pero debe mantenerse separado de la operación. Si recopila email, teléfono, identificadores del dispositivo o analítica:

define responsable y finalidad;
presenta aviso de privacidad;
obtiene el consentimiento aplicable;
limita campos y retención;
protege y restringe exportaciones;
respeta bajas y derechos;
evita usar acceso esencial como consentimiento engañoso.

No prometas que WiFi gratis aumenta estancia o consumo sin datos propios. Mide uso, conversión y quejas bajo un diseño respetuoso.

Compra por requisitos, no por marca

Solicita al integrador:

survey y plano de diseño;
cobertura y capacidad objetivo;
bandas, canales y potencia documentados;
switches gestionados y presupuesto PoE;
firewall, VLAN y reglas;
autenticación por zona;
UPS y autonomía;
segundo WAN y pruebas;
monitoreo y retención de logs;
licencias y soporte;
respaldo, exportación y salida;
pruebas de aceptación;
capacitación y runbook.

Los modelos, licencias y precios cambian. Cotiza localmente con fecha y compara costo total: hardware, cableado, montaje, licencias, soporte, repuestos y operación.

Pruebas de aceptación

Límites de Kavasoft

Al usar Kavasoft para restaurantes, confirma requisitos de navegador, dispositivos, conectividad y operación offline del plan contratado. Kavasoft puede depender de la red para ciertas funciones; no diseña la WLAN, no controla al ISP, no valida segmentación PCI y no garantiza continuidad cuando falla infraestructura externa.