Proyecto ax³ (3/3) — Monopuesto, VPN y corte final
Serie completa:
Índice ·
Parte 1 ·
Parte 2 ·
Parte 3
Introducción
En la Parte 1 definimos el objetivo, la comparativa y la arquitectura.
En la Parte 2 dejamos el hAP ax³ completamente preparado en la red
aislada 192.168.50.0/24, con RouterOS y firmware actualizados, DHCP
funcionando, Wi-Fi 6 configurado, firewall básico y backups en orden.
En esta tercera y última parte se hace el corte real: configurar el PPPoE de o2,
poner el MitraStar en monopuesto, integrar WireGuard con ProtonVPN, montar el policy
routing, cerrar el DNS con Pi-Hole y Unbound, migrar a 192.168.88.0/24
y apagar el hAP ac².
Esta es la parte con riesgo real. Hasta aquí todo eran pruebas
aisladas. A partir de este punto, un error puede dejar la red sin Internet. Antes de
empezar, ten a mano el bloque de reversión que está al final de este
artículo y asegúrate de haberlo leído entero.
Fase 5 — Internet o2 y monopuesto
El objetivo de esta fase es que el hAP ax³ reciba directamente la IP pública
por PPPoE, eliminando el doble NAT que hoy existe entre el MitraStar y el router.
Para ello, el MitraStar pasa a modo monopuesto.
Arquitectura final
o2 / Internet
│
Fibra óptica
│
┌──────────────────────────────────┐
│ MitraStar GPT-2541GNAC │
│ MONOPUESTO │
│ SIN NAT │
│ Teléfono ─── VoIP │
└────────────┬─────────────────────┘
│ Ethernet / PPPoE
▼
┌──────────────────────────────────┐
│ hAP ax³ │
│ PPPoE + NAT + Firewall │
│ WireGuard + ProtonVPN │
│ Policy routing │
└────────────┬─────────────────────┘
│
192.168.88.0/24
│
├── tormenta 192.168.88.160 FreeBSD 14.5 (Unbound, NFSv4, Kerberos, ZFS, Samba)
├── solaris 192.168.88.51 FreeBSD 14.5
├── raspberry 192.168.88.244 Raspberry Pi 3B + Pi-Hole
└── demás dispositivos
Datos PPPoE de o2
Usuario: adslppp@telefonicanetpa
Contraseña: adslppp
Notas sobre el MitraStar GPT-2541GNAC
Este HGU tiene un comportamiento específico que conviene documentar antes de tocarlo.
En monopuesto, delega la conexión de Internet al router neutro mediante PPPoE, pero
sigue gestionando la VoIP del teléfono fijo. Es exactamente lo que queremos.
| Modelo / Board ID | GPT-2541GNAC |
| Firmware | ES_g7.12_100VNJ0b73 |
| Build | 230705_2059 → 5 de julio de 2023 |
| Bootloader | 1.0.41-117.134 |
| Wireless driver | 6.37.14.4803.cpe4.14L04Apatch1.0 |
Recomendaciones críticas para el monopuesto:
- Usar la opción «Monopuesto» de la interfaz básica del MitraStar.
- No intentar construir el bridge manualmente desde la interfaz avanzada.
- Hay reportes de bugs si se manipulan VLAN desde el menú avanzado.
- En monopuesto, el HGU entrega el PPPoE sin etiquetar.
- Por tanto, no configurar VLAN 6 en el MikroTik.
Atención con la VoIP: existen casos documentados con este firmware en
los que el teléfono deja de funcionar a los pocos minutos de activar monopuesto. Si
ocurre, la solución reportada es acceder a la configuración avanzada del HGU, editar
la interfaz WAN de VoIP y habilitar las opciones Enable IGMP Multicast Proxy
y Enable IGMP Multicast Source. No dar el cambio por bueno hasta que
hayan pasado al menos 48 horas sin incidencias.
Configurar el cliente PPPoE en el ax³
- Conectar el cable del MitraStar al puerto
ether1 del ax³.
- WinBox →
PPP → Interface → + → PPPoE Client.
- Configurar:
- Name:
pppoe-o2
- Interface:
ether1
- User:
adslppp@telefonicanetpa
- Password:
adslppp
- Add Default Route: sí
- Use Peer DNS: no
- Apply → OK.
Comprobar que la sesión levanta:
/interface pppoe-client monitor [find] once
/log print where topics~"pppoe"
Activar el monopuesto en el MitraStar
- Acceder al MitraStar por su interfaz web.
- Ir a la sección básica de configuración WAN.
- Activar la opción «Monopuesto».
- Guardar y esperar el reinicio del HGU.
- Comprobar en el ax³ que la sesión PPPoE obtiene una IP pública.
- Verificar que el teléfono fijo sigue registrando correctamente.
Decisión clave sobre el DHCP client de ether1: el ax³ mantiene un
DHCP client activo en ether1 para obtener una IP en la LAN del HGU
(192.168.1.0/24), lo que permite acceder a la interfaz web del MitraStar
si hace falta. Pero ese cliente debe tener add-default-route=no. Si lo
activamos, RouterOS añade una ruta 0.0.0.0/0 via 192.168.1.1 que
reintroduce el doble NAT que acabamos de eliminar.
/ip dhcp-client set [find interface=ether1] add-default-route=no
/interface pppoe-client set [find name=pppoe-o2] add-default-route=yes
Verificar que la única ruta por defecto es la del PPPoE:
/ip route print where dst-address=0.0.0.0/0
Debe aparecer una sola ruta por defecto en la tabla main:
DAv 0.0.0.0/0 gateway=pppoe-o2 distance=1
Fase 6 — VPN, DNS y policy routing
Con Internet funcionando en el ax³, ya se puede montar el resto de la infraestructura:
WireGuard, ProtonVPN, policy routing, kill switch y DNS definitivo. Esta fase es la
más delicada del proyecto, porque cualquier error aquí no rompe la red entera, pero
sí deja dispositivos sin Internet de forma difícil de diagnosticar.
WireGuard y ProtonVPN
ProtonVPN ofrece configuración WireGuard lista para importar. Desde el panel de
ProtonVPN se genera un archivo con clave privada, clave pública del servidor, endpoint
y AllowedIPs. Se importa directamente en RouterOS:
WireGuard → Interface → + → Import from file
Comprobar que el túnel levanta:
/interface wireguard print
/interface wireguard peers print
/ping 10.2.0.1 count=3 interface=proton-vpn
Detalle importante: verificar que el campo AllowedIPs
del peer incluye 0.0.0.0/0. Si solo incluye rangos parciales, algunos
destinos no pasarán por la VPN aunque los marques con routing-mark.
Policy routing: el patrón correcto
El objetivo es que cada dispositivo pueda salir por WAN normal o por ProtonVPN según
una política definida. En RouterOS esto se hace combinando tres piezas:
- Marcar la conexión al primer paquete (chain
prerouting).
- Marcar el routing de todos los paquetes de esa conexión.
- Una tabla de rutas alternativa que envía lo marcado por el túnel.
Error común: marcar directamente routing-mark en
prerouting sin marcar antes la conexión. Funciona en el 90% de los casos,
pero falla con NAT, con retorno asimétrico y cuando una conexión se reutiliza. El
patrón robusto es siempre primero marcar conexión, después marcar routing.
Estructura final de las reglas de mangle
0 No marcar tráfico LAN dst-address-list=lan-directa
1-2 Dummy (dinámicas)
3 change-mss 1452 out-interface=pppoe-o2
4 Marcar conexión de xiaomi src-address=192.168.88.252
5 Marcar conexión de solaris src-address=192.168.88.51
6 Enrutar xiaomi por VPN connection-mark=xiaomi-vpn
7 Enrutar solaris por VPN connection-mark=solaris-vpn
8 change-mss 1380 out-interface=proton-vpn
Paso 1 — Address-list con las redes que NO se marcan
Antes de cualquier regla de marcado, hay que excluir el tráfico destinado a la propia
LAN. Si no, el tráfico hacia Pi-Hole, Unbound o cualquier host local se marca con
via-vpn, y como la tabla via-vpn no tiene ruta a
192.168.88.0/24, esas consultas se van por el túnel en lugar de entregarse
localmente. El síntoma es desconcertante: parece que "no hay Internet", pero el ping
por IP funciona.
/ip firewall address-list
add list=lan-directa address=192.168.88.0/24 comment="LAN principal"
add list=lan-directa address=192.168.1.0/24 comment="LAN del HGU o2"
add list=lan-directa address=10.2.0.0/24 comment="Red interna ProtonVPN"
Y la regla de exclusión, al principio de prerouting:
/ip firewall mangle
add chain=prerouting dst-address-list=lan-directa action=return \
comment="No marcar tráfico LAN"
Si place-before=0 falla (RouterOS no acepta referencias
a reglas dinámicas), añade la regla al final y muévela después con
move [find comment~"No marcar"] destination=[find comment~"Marcar conexin de xiaomi"].
Lo importante es que esté antes de cualquier mark-connection
o mark-routing.
Paso 2 — Marcar conexión por dispositivo
/ip firewall mangle
add chain=prerouting src-address=192.168.88.252 in-interface=bridge \
action=mark-connection new-connection-mark=xiaomi-vpn passthrough=yes \
comment="Marcar conexión de xiaomi"
add chain=prerouting src-address=192.168.88.51 in-interface=bridge \
action=mark-connection new-connection-mark=solaris-vpn passthrough=yes \
comment="Marcar conexión de solaris"
El passthrough=yes es importante: después de marcar la conexión, el paquete
sigue evaluándose contra las reglas siguientes, que serán las que lean esa marca.
Paso 3 — Enrutar por VPN según la marca de conexión
/ip firewall mangle
add chain=prerouting connection-mark=xiaomi-vpn \
action=mark-routing new-routing-mark=via-vpn passthrough=no \
comment="Enrutar xiaomi por VPN"
add chain=prerouting connection-mark=solaris-vpn \
action=mark-routing new-routing-mark=via-vpn passthrough=no \
comment="Enrutar solaris por VPN"
El passthrough=no ahorra ciclos de CPU: una vez marcado el routing, no hace
falta seguir evaluando más reglas de mangle.
Paso 4 — Tabla de rutas con kill switch por blackhole
La tabla via-vpn debe tener dos rutas: una activa por el túnel y otra
blackhole de respaldo. Si el túnel cae, la activa desaparece y entra la
blackhole, que descarta el tráfico marcado. Es un kill switch a nivel de routing, sin
necesidad de reglas de firewall adicionales.
/ip route
add dst-address=0.0.0.0/0 gateway=proton-vpn routing-table=via-vpn distance=1 \
comment="Salida por ProtonVPN"
add dst-address=0.0.0.0/0 type=blackhole routing-table=via-vpn distance=2 \
comment="Kill switch: descartar si el túnel cae"
Por qué funciona: si el túnel está arriba, la ruta 1 está activa y la 2
nunca se usa. Si el túnel cae, la ruta 1 se vuelve inactiva y la 2 entra en juego,
descartando el tráfico marcado. No hay fuga posible hacia la WAN normal.
Paso 5 — MSS por interfaz
El MSS (Maximum Segment Size) es el tamaño máximo de payload TCP. Si se configura mal,
se produce fragmentación o drops silenciosos: algunas webs cargan, otras se quedan
colgadas, y parece que "no hay Internet" cuando en realidad es un problema de MTU.
/ip firewall mangle
add chain=forward protocol=tcp tcp-flags=syn out-interface=pppoe-o2 \
action=change-mss new-mss=1452 passthrough=yes \
comment="MSS para PPPoE (MTU 1492)"
add chain=forward protocol=tcp tcp-flags=syn out-interface=proton-vpn \
action=change-mss new-mss=1380 passthrough=yes \
comment="MSS para túnel WireGuard (MTU 1420)"
| Interfaz |
MTU |
MSS |
Fórmula |
pppoe-o2 |
1492 |
1452 |
1492 − 40 (IP+TCP) |
proton-vpn |
1420 |
1380 |
1420 − 40 (IP+TCP) |
bridge (LAN) |
1500 |
1460 |
1500 − 40 (IP+TCP) |
Error frecuente: usar un único MSS de 1452 para todo el tráfico.
Para el tráfico que sale por PPPoE es correcto, pero para el que sale por el túnel
es demasiado alto. Los paquetes grandes se fragmentan o se descartan silenciosamente,
y el síntoma es exactamente el de "webs a medio cargar".
Paso 6 — Regla de forward para el tráfico del túnel
El firewall del ax³ tiene una regla que acepta el tráfico de LAN hacia WAN, pero el
túnel proton-vpn normalmente no está en la lista WAN.
Sin una regla específica, el tráfico que sale por el túnel cae en el
Drop todo lo demás y se descarta.
/ip firewall filter
add chain=forward in-interface-list=LAN out-interface=proton-vpn \
action=accept comment="Permitir LAN a VPN" \
place-before=[find comment="Drop todo lo dems"]
Paso 7 — DNS con Pi-Hole y Unbound
Clientes de la LAN
│
▼
Pi-Hole (raspberry.casa.lan / 192.168.88.244)
│
▼
Unbound (tormenta.casa.lan / 192.168.88.160)
│
▼
Resolución recursiva directa (sin DNS externos)
En el ax³, dos ajustes complementarios:
# 1. El DHCP entrega solo Pi-Hole como DNS
/ip dhcp-server network
set [find] dns-server=192.168.88.244
# 2. El router no actúa como resolver DNS
/ip dns
set allow-remote-requests=no
Allow Remote Requests debe estar desactivado. Si se activa, el router
abre un resolver en 192.168.88.1:53 que se salta Pi-Hole y Unbound. Eso
rompe el filtrado y puede filtrar metadatos al ISP si el router reenvía al DNS del
operador.
Verificación final del policy routing
/ip firewall mangle print stats
| Regla |
Debe tener paquetes |
Comentario |
| No marcar tráfico LAN |
✅ |
Ping a Pi-Hole, Unbound, etc. |
| Marcar conexión de xiaomi |
✅ |
Primer paquete de cada conexión |
| Marcar conexión de solaris |
✅ |
Primer paquete de cada conexión |
| Enrutar xiaomi por VPN |
✅ |
Todos los paquetes de la conexión |
| Enrutar solaris por VPN |
✅ |
Todos los paquetes de la conexión |
| MSS túnel WireGuard |
✅ |
Solo paquetes SYN que salen por el túnel |
Diferencia esperada entre marca y enrutamiento: la regla "Marcar
conexión" solo actúa sobre el primer paquete de cada conexión, la "Enrutar por VPN"
sobre todos. Por eso la segunda siempre tiene más paquetes. Si ves lo contrario, algo
va mal.
Prueba real desde un cliente VPN
# Desde solaris
ping -c 3 192.168.88.244 # Pi-Hole (debe funcionar)
ping -c 3 1.1.1.1 # Internet por IP (por el túnel)
ping -c 3 google.com # DNS (por Pi-Hole)
curl -s ifconfig.me # IP pública (debe ser de ProtonVPN)
Resultado esperado: curl ifconfig.me devuelve una IP
distinta a la de o2 (que es la que devolverá desde cualquier dispositivo que NO esté
en la lista de clientes VPN).
Kill switch: prueba real
- Deshabilitar la interfaz WireGuard:
/interface wireguard disable proton-vpn
- Desde solaris, comprobar que no tiene Internet:
ping -c 3 1.1.1.1
- Comprobar que sigue teniendo acceso a la LAN:
ping -c 3 192.168.88.244
- Volver a habilitar la interfaz:
/interface wireguard enable proton-vpn
- Comprobar que recupera Internet por el túnel:
curl -s ifconfig.me
Fase 7 — Corte final
Llegados a este punto, el ax³ funciona en 192.168.50.0/24 con Internet,
PPPoE, VPN, policy routing y DNS completo. Solo falta el cambio final: apagar el ac²
y migrar el ax³ a 192.168.88.0/24.
o2 monopuesto
│
▼
hAP ax³
│
192.168.88.0/24
│
tormenta + solaris + raspberry + resto de LAN
Preparativos antes del corte
- Backup completo del hAP ac² exportado y descargado.
- Backup completo del hAP ax³ exportado y descargado.
- Capturas de la configuración actual del MitraStar.
- Confirmar que el hAP ac² está apagado pero accesible físicamente.
- Ventana de mantenimiento acordada con quien use la red.
Pasos del corte
- Apagar el hAP ac² y desconectarlo de la red.
- En el ax³, cambiar la IP LAN de
192.168.50.1/24 a 192.168.88.1/24.
- Actualizar el DHCP Network a
192.168.88.0/24.
- Actualizar el pool DHCP a
192.168.88.10-192.168.88.254.
- Conectar el ax³ al switch de la LAN.
- Comprobar desde un cliente:
- IP recibida por DHCP.
- Puerta de enlace
192.168.88.1.
- Acceso a Internet.
- Resolución DNS vía Pi-Hole.
Comprobaciones post-corte
# Desde un cliente de la LAN
curl -s ifconfig.me # Debe devolver la IP pública de o2
# Desde el ax³
/ip route print where dst-address=0.0.0.0/0
/interface pppoe-client monitor [find] once
/ip firewall mangle print stats
- Internet normal funcionando.
- Internet por ProtonVPN funcionando en los clientes marcados.
- Policy routing por dispositivo correcto.
- Kill switch bloqueando fugas.
- DNS sin fugas: clientes → Pi-Hole → Unbound.
- NFSv4, Kerberos, ZFS y Samba accesibles desde clientes.
- VoIP del MitraStar operativa.
- Rendimiento Wi-Fi 6 correcto.
Estado final alcanzado: el hAP ax³ es el router de producción, sale
directamente por la IP pública de o2 vía PPPoE (sin doble NAT), el MitraStar está en
monopuesto gestionando la VoIP, y el hAP ac² queda apagado con su configuración
intacta, listo para volver a entrar en servicio si algo falla.
Plan de reversión
Regla de oro: nunca se desmonta nada antes de tener confirmado que
el nuevo estado funciona. El hAP ac² no se apaga, no se resetea y no se reconfigura
hasta que el ax³ lleve al menos 48 horas funcionando en producción
sin incidencias.
Puntos de retorno
| Punto de no retorno |
Síntoma |
Acción de reversión |
| Antes de monopuesto |
Todo funciona con doble NAT |
Nada que revertir. Seguir probando. |
| Tras activar monopuesto |
VoIP deja de funcionar |
Volver a modo router en el MitraStar |
| Tras activar monopuesto |
El ax³ no levanta PPPoE |
Volver a modo router en el MitraStar |
| Tras el corte final |
Fallo grave en el ax³ |
Reenchufar el ac² tal cual estaba |
| Tras el corte final |
Fugas DNS o kill switch roto |
Volver al ac² y revisar reglas |
Caso 1 — La VoIP deja de funcionar tras monopuesto
Síntoma: el teléfono fijo registra correctamente al principio y
deja de funcionar a los pocos minutos. Es un bug conocido de determinadas versiones
de firmware MitraStar, entre ellas la ES_g7.12_100VNJ0b73.
- Acceder al MitraStar por su interfaz web.
- Ir a la opción de Monopuesto en la interfaz básica.
- Desactivarla y volver a modo router.
- Confirmar que el teléfono vuelve a registrar.
- El hAP ax³ seguirá funcionando detrás del MitraStar, pero volveremos a tener doble NAT.
Alternativa si se quiere insistir en monopuesto:
- Acceder a la configuración avanzada del HGU.
- Editar la interfaz WAN de VoIP.
- Habilitar
Enable IGMP Multicast Proxy y Enable IGMP Multicast Source.
- Guardar y comprobar que el teléfono vuelve a registrar.
Caso 2 — El ax³ no levanta PPPoE
Diagnóstico rápido:
/interface pppoe-client monitor [find] once
/log print where topics~"pppoe"
Comprobaciones:
- Usuario y contraseña exactos:
Usuario: adslppp@telefonicanetpa
Contraseña: adslppp
- Que el MitraStar esté realmente en monopuesto.
- Que el cable salga del puerto correcto del MitraStar hacia
ether1.
- Que no haya VLAN configurada en
ether1.
- Que
ether1 no esté dentro del bridge.
Caso 3 — Corte final: hay que volver al hAP ac²
Requisito previo: el hAP ac² debe estar apagado pero
físicamente accesible y con su configuración intacta.
- Apagar el hAP ax³.
- Desconectar el cable que va del MitraStar al
ether1 del ax³.
- Reconectar el hAP ac² exactamente como estaba.
- Encender el hAP ac².
- Esperar 60–90 segundos.
- Comprobar desde un cliente: IP, puerta de enlace, Internet, DNS.
- Si el MitraStar sigue en monopuesto, volverlo a modo router.
Caso 4 — Fugas DNS o kill switch roto
# Fuga DNS
nslookup whoami.akamai.net
nslookup dnsleaktest.com
# Kill switch (con el túnel caído)
ping 1.1.1.1
curl ifconfig.me
Reversión inmediata:
- Desactivar temporalmente el policy routing en el ax³.
- Dejar todo el tráfico saliendo por la WAN normal.
- Confirmar que Internet vuelve a funcionar.
- Revisar reglas de firewall, marcas de routing y DNS antes de reactivar.
Caso 5 — El ax³ se queda inaccesible
Reglas preventivas:
- WinBox por MAC siempre disponible.
- Safe Mode activado antes de tocar firewall o interfaces:
/system safe-mode
Si aun así queda inaccesible:
- Conectar el portátil a un puerto LAN del ax³.
- WinBox → Neighbors → entrar por MAC.
- Si tampoco aparece, resetear el ax³ y restaurar el último backup.
Checklist de reversión
- ☐ Capturas de la configuración del MitraStar guardadas.
- ☐ Backup del hAP ac² exportado y descargado.
- ☐ Backup del hAP ax³ exportado y descargado.
- ☐ Cable del MitraStar etiquetado (WAN, LAN).
- ☐ Procedimiento de reversión impreso o accesible desde el móvil.
- ☐ hAP ac² accesible físicamente, apagado pero listo para reconectar.
- ☐ Ventana de mantenimiento acordada.
- ☐ Ensayo previo del corte y de la reversión hecho antes del día real.
Filosofía del plan: el objetivo no es que no falle nada, sino que
si falla algo, en menos de 10 minutos todo el mundo esté navegando como
antes. La migración se hace cuando se puede permitir el lujo de fallar; no cuando no
hay margen.
Pendientes por aclarar
- Confirmar que la VoIP del MitraStar se mantiene operativa durante 48 horas.
- Definir política final de DNS: Pi-Hole como único DNS para clientes,
Unbound como resolver recursivo aguas arriba.
- Definir reservas DHCP fijas en
192.168.88.0/24 para
tormenta, solaris y raspberry.
- Documentar qué dispositivos van por ProtonVPN y cuáles por WAN normal.
- Valorar migrar de reglas por IP a
address-list=vpn-clients
cuando la lista de dispositivos VPN crezca.
Checklist final del proyecto
- ☐ hAP ac² sigue funcionando hasta el corte final.
- ☐ hAP ax³ actualizado: RouterOS y firmware al mismo nivel.
- ☐ Backup inicial del ax³.
- ☐ IP LAN temporal:
192.168.50.1/24.
- ☐ DHCP Network temporal:
192.168.50.0/24.
- ☐ Pool temporal:
192.168.50.10-192.168.50.254.
- ☐ Portátil en
192.168.50.254.
- ☐ WinBox por MAC funcionando.
- ☐ Configuración base: bridge, DHCP, Wi-Fi 6, firewall, NAT.
- ☐ PPPoE o2:
adslppp@telefonicanetpa / adslppp.
- ☐ MitraStar en monopuesto.
- ☐ VoIP operativa tras monopuesto.
- ☐ WireGuard + ProtonVPN funcionando.
- ☐ Policy routing por dispositivo con
mark-connection + mark-routing.
- ☐ Exclusión LAN (
lan-directa) al principio del mangle.
- ☐ MSS por interfaz: 1452 para PPPoE, 1380 para túnel.
- ☐ Regla de forward LAN → VPN.
- ☐ Kill switch por blackhole probado con túnel caído.
- ☐ DNS sin fugas: clientes → Pi-Hole → Unbound.
- ☐
allow-remote-requests=no en /ip dns.
- ☐ DHCP entrega solo
192.168.88.244 como DNS.
- ☐ NFSv4, Kerberos, ZFS y Samba accesibles.
- ☐ Corte final a
192.168.88.0/24.
- ☐ IP pública confirmada desde cliente (
curl ifconfig.me).
- ☐ 48 horas de observación antes de retirar el ac² definitivamente.
Cierre de la serie: migrar un router no es solo cambiar hardware.
Es reorganizar servicios, eliminar deuda técnica (doble NAT, DNS delegado al ISP)
y dejar un plan de reversión que permita dormir tranquilo. El hAP ax³ no es el
final del proyecto: es la base sobre la que se construye todo lo demás.
Serie: este artículo cierra Proyecto ax³. Viene de la
Parte 1 — Qué cambia y por qué
y de la
Parte 2 — Preparar el ax³ sin tocar la red.
Volver al índice de la serie
FreeBSD es genial!.
