WireGuard es una VPN moderna, gratuita y de código abierto. Une dos equipos por un túnel cifrado con un archivo de menos de diez líneas. Esta guía explica qué es, cómo instalar WireGuard en cada sistema y cómo configurar WireGuard paso a paso. Además, aclara qué significa AllowedIPs, la opción que más errores causa, y compara WireGuard vs OpenVPN con medidas propias.
No lo copiamos del manual. Montamos un laboratorio con una sede, un cliente y una red de oficina, y ejecutamos cada orden. Así vimos lo que la documentación no subraya. Por ejemplo, con una clave equivocada el túnel arranca sin ningún error y, sencillamente, no pasa tráfico. Además, en nuestra prueba de velocidad el resultado salió al revés de lo que se suele leer.
Si todavía no tiene claro cómo se organiza una red de oficina, empiece por nuestra guía de la red de área local. Aquí se dan por sabidas las direcciones IP y las máscaras.
Qué es WireGuard y para qué sirve
WireGuard es un protocolo de VPN y, a la vez, el programa que lo implementa. Lo creó Jason A. Donenfeld en 2015. Desde marzo de 2020 forma parte del núcleo de Linux, a partir de la versión 5.6. Hoy tiene clientes oficiales para Windows, macOS, Android e iOS.
Sirve, sobre todo, para tres trabajos:
- Teletrabajo: que un portátil llegue a los archivos y programas de la oficina desde fuera.
- Unir sedes: que dos oficinas se vean como una sola red.
- Proteger la conexión en una red wifi ajena, enviando todo el tráfico por la oficina.
Su página oficial lo define como una VPN «extremadamente simple, rápida y moderna». La simpleza es su rasgo principal. No hay usuarios, contraseñas ni certificados. Solo hay claves, como en SSH.
¿WireGuard es gratis y es seguro?
Es gratis. La parte de Linux se publica con licencia GPL versión 2 y el resto de programas, con otras licencias libres. No hay ediciones de pago ni límite de equipos.
En cuanto a la seguridad, no deja elegir los algoritmos de cifrado. Usa un único conjunto, moderno y fijo: ChaCha20 para cifrar, Poly1305 para autenticar y Curve25519 para el intercambio de claves. Por tanto, no existe una configuración débil que alguien pueda activar por descuido.
Dicho eso, ninguna VPN es segura si se pierde una clave privada. Quien tenga el archivo de configuración de un portátil entra a la red como ese portátil.
Cómo funciona WireGuard, en un minuto
Cada equipo tiene un par de claves: una privada, que no sale de él, y una pública, que se entrega al otro lado. Además, cada equipo guarda una lista de pares. Cada par es la clave pública de otro equipo y las direcciones que se le permiten.
No hay «conexión» en el sentido habitual. El túnel no habla con nadie hasta que hay algo que enviar. Lo comprobamos con la configuración mínima: tras levantar los dos extremos, el contador de negociación seguía en cero. El primer ping tardó 22 milisegundos, con la negociación incluida. Los siguientes, menos de un milisegundo.
Dónde probamos WireGuard
El laboratorio fueron tres equipos Debian 13 en contenedores, con las herramientas de WireGuard 1.0.20210914 y el módulo del núcleo de Linux 6.6. Uno hacía de sede, otro de cliente remoto y el tercero de servidor de archivos de la oficina. Trabajaron en redes aisladas, sin salir a internet salvo en una prueba.
Es un laboratorio virtual en un solo equipo físico. Por eso los tiempos y las velocidades sirven para comparar entre sí, no como cifras de una red real.
Cómo leer los ejemplos
- La sede tiene la dirección pública
vpn.ejemplo.comy escucha en el puerto UDP 51820. - El túnel usa la red
10.8.0.0/24: la sede es10.8.0.1y el cliente,10.8.0.2. - La red de la oficina es
192.168.10.0/24y su servidor de archivos,192.168.10.20. - Las órdenes de Linux se escriben como administrador. Abra antes una sesión con
sudo -i. - Los textos en mayúsculas, como
CLAVE_PUBLICA_DE_LA_SEDE, se cambian por los valores reales.
Cómo instalar WireGuard
Instalar WireGuard en Linux
En Debian y en Ubuntu basta un paquete. El módulo ya viene en el núcleo:
apt update
apt install wireguardEn Fedora, el paquete se llama wireguard-tools y se instala con dnf. La página de instalación oficial da la orden de cada distribución.
Instalar WireGuard en Windows
El cliente oficial sirve para Windows 10 y 11 y para Windows Server desde 2016 hasta 2025. Se descarga de la página oficial como un instalador pequeño, que elige el paquete correcto para el equipo. Al cierre de esta guía, el paquete publicado era el 1.1.1.
Después, el uso es gráfico: se importa el archivo de configuración y se activa el túnel con un botón. Por debajo, cada túnel es un servicio de Windows. Lo vimos en nuestro propio equipo: tres servicios, uno del administrador del programa y uno por cada túnel.
Para una empresa hay dos datos útiles en la documentación del cliente. Primero, existen paquetes MSI para desplegarlo con directivas de grupo. Segundo, por defecto solo un administrador puede activar un túnel. Para que lo haga un usuario corriente, se le añade al grupo «Operadores de configuración de red» y se activa una clave del Registro, LimitedOperatorUI. Ese usuario podrá encender y apagar el túnel, pero no verá las claves.
Instalar WireGuard en macOS, Android y iPhone
En macOS y en iPhone se instala desde la App Store. Para Android está en Play Store. Además, en el móvil no hace falta escribir nada: el archivo de configuración se convierte en un código QR y se escanea. Más abajo está la orden.
WireGuard en MikroTik, pfSense, OPNsense y Docker
Muchos equipos de red lo traen integrado. MikroTik lo incluye en RouterOS 7, y también lo tienen pfSense y OPNsense. Si usa alguno, la configuración se hace desde su panel, con los mismos conceptos de esta guía. Los explicamos en las guías de MikroTik, pfSense y OPNsense.
Sobre Docker hay un detalle que medimos. Dentro de un contenedor sin privilegios, el túnel sencillo funcionó. En cambio, al enviar todo el tráfico por el túnel, la orden falló con «permission denied» al cambiar un ajuste del núcleo. Con el contenedor en modo privilegiado, funcionó.
Cómo configurar WireGuard paso a paso
La configuración mínima son cuatro pasos: crear las claves, escribir el archivo de la sede, escribir el del cliente y levantar el túnel.
Paso 1: crear las claves
En la sede:
umask 077
cd /etc/wireguard
wg genkey | tee sede.key | wg pubkey > sede.pub
cat sede.pubLa primera línea importa. Hace que los archivos nuevos solo los pueda leer el administrador. Sin ella, wg avisa: «Warning: writing to world accessible file». La última línea muestra la clave pública, que es la que se entrega al otro lado.
En el cliente se hace lo mismo, con otros nombres:
umask 077
cd /etc/wireguard
wg genkey | tee cliente.key | wg pubkey > cliente.pub
cat cliente.pubCada clave son 44 caracteres. Crearlas tardó 3 milisegundos. La clave privada no se envía nunca: ni por correo ni por chat.
Paso 2: el archivo de la sede
Cree /etc/wireguard/wg0.conf en la sede con este contenido:
[Interface]
Address = 10.8.0.1/24
ListenPort = 51820
PrivateKey = CLAVE_PRIVADA_DE_LA_SEDE
[Peer]
PublicKey = CLAVE_PUBLICA_DEL_CLIENTE
AllowedIPs = 10.8.0.2/32El bloque [Interface] describe al propio equipo: su dirección dentro del túnel, el puerto y su clave privada. El bloque [Peer] describe al otro: su clave pública y la dirección que se le permite usar. Habrá un bloque [Peer] por cada cliente.
Paso 3: el archivo del cliente
En el cliente, el archivo /etc/wireguard/wg0.conf es casi un espejo:
[Interface]
Address = 10.8.0.2/24
PrivateKey = CLAVE_PRIVADA_DEL_CLIENTE
[Peer]
PublicKey = CLAVE_PUBLICA_DE_LA_SEDE
Endpoint = vpn.ejemplo.com:51820
AllowedIPs = 10.8.0.0/24
PersistentKeepalive = 25Hay dos líneas nuevas. Endpoint dice dónde está la sede. PersistentKeepalive mantiene vivo el túnel cuando el cliente está detrás de un router doméstico. Lo explicamos más abajo.
En Windows, en macOS y en el móvil se usa este mismo archivo. Solo cambia la forma de cargarlo.
Paso 4: levantar el túnel y comprobarlo
En los dos equipos:
chmod 600 /etc/wireguard/wg0.conf
wg-quick up wg0La orden wg-quick lee el archivo, crea la interfaz, le pone la dirección y añade las rutas. En la prueba tardó 0,04 segundos. Después, desde el cliente:
ping -c 3 10.8.0.1
wg showSi el ping responde, el túnel funciona. La orden wg show lo confirma con dos líneas: latest handshake, que dice hace cuánto se negoció, y transfer, con los datos enviados y recibidos.
Que WireGuard arranque con el sistema
En un Linux con systemd, el paquete trae un servicio listo. Se activa con systemctl enable --now wg-quick@wg0. No pudimos ejecutarlo, porque nuestros contenedores no usan systemd. Sí comprobamos que el paquete instala ese servicio.
Además, la sede necesita el puerto UDP 51820 abierto en su firewall y, si está detrás de un router, redirigido hacia ella.
AllowedIPs: la opción que más confunde
AllowedIPs hace dos trabajos a la vez, y por eso cuesta entenderla.
- Al enviar, es una tabla de rutas: «lo que vaya a estas direcciones, mándalo a este par».
- Al recibir, es un filtro: «de este par solo acepto paquetes que vengan de estas direcciones».
El manual lo dice con una frase: son las direcciones desde las que se permite el tráfico entrante de ese par y hacia las que se dirige el saliente.
| Valor de AllowedIPs en el cliente | Qué viaja por el túnel |
|---|---|
10.8.0.0/24 | Solo el tráfico entre los equipos de la VPN |
10.8.0.0/24, 192.168.10.0/24 | Además, el que va a la red de la oficina |
0.0.0.0/0 | Todo, incluida la navegación por internet |
En la sede, en cambio, la regla es otra. Cada cliente lleva en AllowedIPs su propia dirección con /32, y nada más.
La trampa: dos pares con la misma red
Una red solo puede pertenecer a un par. Lo probamos: añadimos a la sede un segundo par con la misma red que ya tenía el primero. La orden no dio ningún error y devolvió 0. Sin embargo, al mirar con wg show, el primer par había perdido esa red. WireGuard se la quitó en silencio y se la dio al último.
Por eso, si dos clientes dejan de funcionar por turnos, revise que no compartan una dirección en AllowedIPs.
Cómo llegar a la red de la oficina con WireGuard
Hasta aquí, el cliente solo ve a la sede. Para que llegue al servidor de archivos de la oficina hacen falta tres cosas. Las tres fallan en silencio si faltan, así que las probamos una por una.
| Estado de la sede | Resultado del ping al servidor de la oficina |
|---|---|
| Sin reenvío | 100 % de pérdida |
| Con reenvío, sin ruta de vuelta | 100 % de pérdida |
| Con reenvío y ruta de vuelta | Responde |
| Con reenvío y NAT, sin ruta de vuelta | Responde |
Primero: AllowedIPs en el cliente
En el archivo del cliente, cambie la línea de AllowedIPs por esta y vuelva a levantar el túnel:
AllowedIPs = 10.8.0.0/24, 192.168.10.0/24Al levantarlo, wg-quick añade sola la ruta hacia la oficina. Lo vimos en su salida.
Segundo: el reenvío en la sede
Un Linux recién instalado no pasa paquetes de una red a otra. Hay que activarlo, y guardarlo para que sobreviva a un reinicio:
sysctl -w net.ipv4.ip_forward=1
echo 'net.ipv4.ip_forward = 1' > /etc/sysctl.d/99-wireguard.confTercero: el camino de vuelta
El servidor de la oficina recibe el paquete, pero no sabe por dónde contestar a 10.8.0.2. Hay dos soluciones. La limpia es una ruta en el router de la oficina que mande la red de la VPN hacia la sede. En un equipo Linux se escribe así:
ip route add 10.8.0.0/24 via 192.168.10.1La otra solución es que la sede traduzca las direcciones. Así, el servidor cree que le habla la propia sede. Aquí eth1 es la tarjeta de la sede que da a la oficina:
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth1 -j MASQUERADECon la ruta, los registros del servidor muestran qué cliente entró. Con el NAT, en cambio, todo parece venir de la sede. Por eso, en una empresa conviene la ruta.
Enviar todo el tráfico por la VPN
Para que el portátil navegue como si estuviera en la oficina, el cliente usa este valor:
AllowedIPs = 0.0.0.0/0Con él, wg-quick hace bastante más. En la prueba creó una tabla de rutas propia, la 51820, marcó los paquetes del túnel para que no entraran en bucle y añadió dos reglas de enrutamiento. Todo eso lo deshace al bajar el túnel.
Falta la otra mitad. La sede debe dar salida a internet a esos clientes. Sin ello, el ping a una dirección pública se perdió al 100 %. Con esta regla en la sede, respondió. Aquí eth0 es la tarjeta que sale a internet:
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADELas reglas de iptables escritas a mano se pierden al reiniciar. El archivo de WireGuard admite las líneas PostUp y PostDown para ponerlas y quitarlas con el túnel.
Añadir más equipos, móviles y una clave extra
Añadir un cliente sin cortar a los demás
Cada equipo nuevo crea sus claves y recibe una dirección libre. En la sede se añade en caliente, sin reiniciar el túnel:
wg set wg0 peer CLAVE_PUBLICA_DEL_PORTATIL allowed-ips 10.8.0.3/32
wg-quick save wg0La segunda orden guarda el cambio en el archivo. Sin ella, el cliente nuevo desaparece en el siguiente reinicio.
Configurar WireGuard en el móvil con un código QR
Escriba el archivo del móvil en la sede, igual que el de cualquier cliente. Después, conviértalo en un código:
apt install qrencode
qrencode -t ansiutf8 < /etc/wireguard/movil.confEl código aparece dibujado en la terminal. En la aplicación del móvil, elija crear un túnel desde un código QR y escanéelo. Recuerde que ese código contiene la clave privada: no lo fotografíe ni lo envíe.
La clave precompartida
Es una tercera clave, opcional, que comparten los dos extremos. Añade una capa de cifrado simétrico. La documentación la recomienda como defensa frente a futuros ordenadores cuánticos.
wg genpsk > /etc/wireguard/cliente.pskSu contenido se copia en los dos archivos, dentro del bloque [Peer], en una línea PresharedKey. Lo probamos con la clave puesta solo en la sede: el túnel dejó de negociar, otra vez sin ningún mensaje. Al ponerla también en el cliente, volvió a funcionar.
PersistentKeepalive y el cambio de red
Para qué sirve PersistentKeepalive
WireGuard es callado. Si no hay tráfico, no envía nada. Lo medimos: en 60 segundos de reposo salió un solo paquete.
Eso es bueno para la batería, pero choca con los routers domésticos. Un router olvida una conversación que lleva un rato en silencio. Cuando eso pasa, la sede ya no puede iniciar nada hacia el cliente.
La línea PersistentKeepalive = 25 lo evita. Con ella, el cliente envió un paquete vacío de 32 bytes cada 25 segundos. Póngala en el equipo que está detrás del router, no en la sede. Si nadie necesita llamar al cliente desde la oficina, puede omitirla.
Cambiar de wifi sin que se corte
Un portátil cambia de red varias veces al día. WireGuard lo resuelve sin volver a conectar. La sede anota la última dirección desde la que llegó un paquete válido de cada cliente y contesta ahí.
Lo probamos con un ping continuo. A mitad de la prueba cambiamos la red de salida del cliente. De 100 paquetes no se perdió ninguno. En la sede, la dirección del cliente pasó de una red a la otra sin tocar nada.
La renovación de claves
Mientras hay tráfico, los dos extremos renegocian las claves solos. En cinco minutos de ping continuo lo hicieron dos veces, con 120 segundos de diferencia, y no se perdió ninguno de los 300 paquetes.
WireGuard no conecta: cómo encontrar el fallo
El error más buscado es «Handshake did not complete after 5 seconds», que muestra el cliente de Windows. En Linux no aparece ni eso. WireGuard no responde a quien no se identifica bien, así que casi todos los fallos se ven igual: el túnel está arriba y no pasa nada.
Lo reprodujimos con una clave pública equivocada en el cliente. La orden wg-quick up terminó bien. El ping perdió 12 paquetes de 12. Mientras tanto, el cliente envió un intento de negociación de 148 bytes cada 5 segundos, y la sede no contestó a ninguno.
Tampoco se puede comprobar el puerto desde fuera. Un escaneo marcó el puerto 51820 como «open|filtered», es decir, sin respuesta. Es una ventaja de seguridad, pero complica el diagnóstico.
Las cuatro comprobaciones, en orden
wg show wg0 latest-handshakes
ping -c 3 10.8.0.1
ip route get 192.168.10.20
tcpdump -ni eth0 -c 5 udp port 51820| Qué ve | Causa probable |
|---|---|
| El contador de negociación está en 0 | Clave equivocada, puerto cerrado o Endpoint mal escrito |
Hay negociación, pero el ping a la sede falla | La dirección del cliente no está en el AllowedIPs de la sede |
El ping a la sede responde y el de la oficina no | Falta el reenvío o el camino de vuelta |
La ruta a la oficina no sale por wg0 | Falta esa red en el AllowedIPs del cliente |
tcpdump solo muestra paquetes de salida | La sede no contesta: clave o firewall |
La última orden escucha el tráfico del túnel en la tarjeta real. Si solo se ven paquetes que salen, el problema está antes de la sede o en sus claves.
El MTU: cuando conecta pero algunas páginas no cargan
WireGuard añade 80 bytes a cada paquete en el peor caso. Por eso wg-quick fija el tamaño máximo del túnel en 1.420 bytes cuando la red admite 1.500. Lo comprobamos: un paquete de 1.420 bytes pasó y uno de 1.421 no.
ping -c 3 -M do -s 1392 10.8.0.1Esa orden envía paquetes de 1.420 bytes exactos sin dejar que se partan. Si falla en su red, el camino admite menos. Ocurre en algunas conexiones de fibra y de datos móviles. En ese caso, añada una línea MTU = 1380 al bloque [Interface] y pruebe de nuevo.
Otros dos avisos que vimos
- Una línea
DNSen el archivo necesita el programaresolvconf. Sin él,wg-quickfalló con «resolvconf: command not found» y deshizo el túnel. - Levantar dos veces el mismo túnel no rompe nada. La segunda vez responde que la interfaz ya existe.
Para apagar el túnel:
wg-quick down wg0WireGuard vs OpenVPN: qué medimos
OpenVPN es la otra VPN de código abierto habitual. Montamos las dos entre los mismos equipos para compararlas. De OpenVPN usamos la versión 2.6.14, con certificados y su cifrado de fábrica, AES-256-GCM.
| Aspecto | WireGuard | OpenVPN 2.6 |
|---|---|---|
| Identidad | Par de claves, como SSH | Certificados o usuario y contraseña |
| Configuración mínima que usamos | 8 líneas por extremo | Un certificado por extremo y unas diez opciones |
| Transporte | Solo UDP | UDP o TCP |
| Cifrado | Fijo: ChaCha20-Poly1305 | A elegir; AES-256-GCM de fábrica |
| Dónde corre en Linux | En el núcleo | En un programa; en nuestra prueba, sin aceleración del núcleo |
Tiempo hasta el primer ping | 22 ms | Cerca de 1 s de negociación |
| Velocidad en nuestro laboratorio | 416 a 472 Mbit/s | 553 a 603 Mbit/s |
| Latencia media añadida | Menos de 1 ms | Menos de 1 ms |
| Cambio de red del cliente | Sin corte: 0 de 100 paquetes perdidos | No lo probamos |
La velocidad: nuestro resultado salió al revés
Casi todo lo publicado dice que WireGuard es más rápido. En nuestro laboratorio no lo fue. En tres pasadas de 10 segundos, OpenVPN movió entre 553 y 603 Mbit/s y WireGuard, entre 416 y 472. Repetimos la prueba de WireGuard en otra sesión y dio entre 305 y 382.
No sacamos de ahí una regla. El laboratorio eran dos contenedores dentro de una máquina virtual, en un solo procesador físico, y no una red con cables. Lo contamos porque es lo que medimos. La propia página de rendimiento de WireGuard avisa de que sus cifras comparativas son antiguas y están pendientes de rehacerse.
La conclusión práctica es otra: no elija entre los dos por una tabla de velocidad ajena. Si el rendimiento importa, mida en su equipo y en su enlace. Con una conexión de oficina de 300 Mbit/s, cualquiera de los dos iba sobrado en la prueba.
Cuándo conviene cada una
Elija WireGuard si quiere una configuración corta, clientes en el móvil y portátiles que cambian de red. Además, viene integrado en Linux y en muchos routers.
Elija OpenVPN si necesita funcionar por TCP, por ejemplo en redes que solo dejan salir por el puerto 443. También si su empresa ya trabaja con usuarios, contraseñas y certificados, y quiere seguir con ellos.
Lo que WireGuard no hace
La lista oficial de limitaciones es corta y conviene leerla antes de decidir:
- No funciona por TCP. El proyecto lo descarta a propósito, por el mal rendimiento de meter TCP dentro de TCP.
- No se disfraza. No intenta parecer otro tipo de tráfico, así que una red que bloquee las VPN puede bloquearlo.
- No tiene usuarios ni contraseñas. Dar de baja a una persona es borrar su clave pública de la sede.
- No reparte direcciones. Cada cliente lleva la suya escrita en su archivo.
- No es, por sí solo, resistente a los futuros ordenadores cuánticos. Para eso está la clave precompartida.
A eso añadimos una observación propia. Tampoco hay un panel que diga quién está conectado. Lo más parecido es wg show, con la hora de la última negociación de cada par.
Lo que no probamos
- No instalamos el cliente en Windows, macOS, Android ni iPhone durante la prueba. Lo que decimos de ellos sale de la documentación oficial y de un Windows que ya lo tenía instalado.
- No ejecutamos
systemctl enable, porque los contenedores no usan systemd. - No configuramos WireGuard en MikroTik, pfSense ni OPNsense para esta guía.
- No medimos la velocidad en una red física ni con IPv6.
- No probamos el cambio de red con OpenVPN.
Cuándo conviene dejar la VPN en manos de un equipo
Un túnel entre dos equipos se monta en diez minutos. Sin embargo, la VPN de una empresa es otra cosa. Hay que decidir quién entra y a qué redes llega. Además, alguien debe dar de baja la clave del portátil que se perdió y revisar que el acceso siga funcionando tras cada cambio de proveedor.
En KHARONTE, las VPN forman parte de la administración de redes y conectividad, junto con el firewall perimetral y las VLAN. Cada cambio queda registrado en una mesa de ayuda TI, con su solicitud y su responsable.
Si prefiere delegar toda la operación, eso es el outsourcing de infraestructura de TI. También puede contratarlo como parte de nuestros servicios administrados de TI. El alcance completo está en la página de servicios de TI para empresas.
Preguntas frecuentes sobre WireGuard
¿WireGuard es gratis?
Sí. Es software libre, sin ediciones de pago ni límite de equipos o de túneles.
¿Qué puerto usa WireGuard?
No tiene uno fijo. Por costumbre se usa el 51820, siempre por UDP. Si no se indica, el programa elige uno al azar en cada arranque.
¿WireGuard funciona con IP dinámica o sin IP pública?
Basta con que uno de los dos extremos sea alcanzable desde internet. El otro puede estar detrás de un router doméstico, con PersistentKeepalive. Si la sede tiene IP dinámica, use un nombre de dominio que se actualice solo.
¿Cuántos clientes admite WireGuard?
El protocolo no fija un máximo. Cada cliente es un bloque [Peer] en la sede, con su clave y su dirección.
¿Cómo doy de baja a un usuario de WireGuard?
Borre su bloque [Peer] del archivo de la sede o ejecute wg set wg0 peer CLAVE remove. Desde ese momento, sus paquetes se ignoran.
¿WireGuard esconde mi dirección IP?
Solo si envía todo el tráfico por el túnel, con AllowedIPs = 0.0.0.0/0. Entonces las páginas ven la dirección de la sede, no la suya.
¿Qué diferencia hay entre WireGuard y Tailscale?
Tailscale es un servicio comercial que usa WireGuard por debajo y añade la gestión de equipos y de claves. WireGuard a secas es solo el túnel, y todo lo demás lo administra usted.
¿Puedo configurar WireGuard en un router?
Sí, si el fabricante lo incluye. MikroTik, pfSense y OPNsense lo traen. Así, la VPN protege a toda la red y no a un solo equipo.
Hablemos de la TI de su empresa
Cuéntenos qué necesita su operación y le enviamos una propuesta por escrito. Cada línea del portafolio se contrata por separado.
