Machine parity — laptop trabajo ⇄ PC personal (WSL2 Sergio)

Contexto

Sergio quiere tener exactamente el mismo acceso operativo en su PC personal (WSL2, hostname Sergio) que en la laptop del trabajo: mismos repos clonados y actualizados, misma ~/.ssh/config con llaves correspondientes, y misma capacidad de llegar a todos los servidores (red corporativa 10.11.x, LAN 192.168.20.x del datacenter, y redes remotas de sitios 192.168.37.x / 192.168.44.x / etc.).

Además quiere una regla operativa permanente: cuando pida un cambio sobre un proyecto, antes de tocar nada se debe verificar que el clone local está en la versión más nueva (fetch + diff vs origin), para evitar reproducir bugs ya arreglados en la otra máquina.

Este proyecto es el complemento operativo de [[hub-portability]]: ese proyecto resolvió que ~/agy/ y la memoria de Antigravity CLI se sincronicen entre máquinas; este resuelve el resto del workspace (código + secretos + red).

Decisiones tomadas (sesión 2026-05-22)

Transferencia de secretos: tarball cifrado generado en laptop trabajo + scp manual (no pegar por chat). Mantiene los secretos fuera del transcript.
Alcance de repos: clonar todos los que aparecen en projects/*.md (no solo active). Paridad total. Disco no es restricción aquí.
Estrategia de red: WireGuard unificado. Hoy en la laptop trabajo hay dos canales separados (VPN para 10.11.x + WireGuard solo para sitios remotos); aquí se quiere un único peer WG que rutee 10.11.x + 192.168.20.x + redes de sitios. Requiere agregar/extender rutas en el server WG.

Tareas pendientes

En progreso

#157 + #158 cerrados (2026-05-29): PC personal migrada a WireGuard unificado. OpenVPN retirado.
#411 cerrado (2026-05-29): dual-push de electrosystems arreglado desde la laptop (ver bitácora).
Follow-ups de WG abiertos para la sem. del 1–7 jun: #408 (WG en celular), #409 (proceso repetible para más clientes WG), #410 (control de acceso fino por cliente WG en el router/equipos). #410 y #409 tocan la VM wireguard (infra ES).
Sigue abierto #155 (triage de repos viejos: deportescampeon, joyeriameza, greco-cell, sis_platform).

Notas técnicas

Inventario inicial (2026-05-22, PC personal `Sergio`)

Sistema: WSL2 Ubuntu 22.04.3 LTS, kernel 5.15.146.1-microsoft-standard.

Ya presente:

~/agy/ clonado y al día (commit f399730 tras la sesión de hoy).
~/.ssh/id_rsa_es (llave electrosystems) — única llave aquí.
~/.ssh/config con 9 hosts: jmeza, orion, ccyes, router-juarez, router-chihuahua, router-parral, grecocell, deportescampeon, monitoreo. Casi todos son hosts internet-directos o de LAN no-VPN.
~/code/: db_backups, deportescampeon, greco-cell, holbox (único al día), joyeriameza, sis_platform.
Tooling: git, node, ssh, virsh, qemu-system-x86_64. Docker disponible vía Docker Desktop Windows (/mnt/c/Program Files/Docker/Docker/resources/bin/docker).
gh -T git@github.com autentica como sevaor (la llave id_rsa_es ya tiene acceso a GitHub).

Falta:

En ~/code/: 8 repos (ver #154).
En ~/.ssh/: hosts SSH adicionales (gi-corp, gi-calzada, oasa-plutarco y otros PBXs, amadeus, laptop-ia, poseidon, apolo, es-nas, wireguard…) y posiblemente llaves adicionales.
~/agy/electrosystems/ completo.
Tooling: gh, php (+ extensiones Laravel), composer, mysql-client, wireguard-tools.
Cliente WireGuard configurado y peer registrado en el server.

Aclaración sobre la red (corrección de Sergio 2026-05-22)

En la laptop del trabajo el acceso a la red corporativa es dual:

VPN cliente (no WireGuard) para llegar a 10.11.x y 192.168.20.x.
WireGuard únicamente para sitios remotos (192.168.37.x, 192.168.44.x, etc.).

En PC personal Sergio quiere unificar todo bajo WireGuard: que un solo peer rutee las tres familias. Esto implica trabajar del lado server (servers/wireguard en electrosystems docs) — probablemente extender AllowedIPs y forwarding/NAT del subnet 10.11.x y 192.168.20.x para que el peer de la PC personal los reciba.

Comando canónico del tarball (#151) — derivado del inventario real de la laptop trabajo (2026-05-26)

Inventario detectado en LaptopWindows:

~/.ssh/: config (4919 bytes, 9+ hosts), id_rsa + id_rsa.pub (ene 2024, llave NO-es), id_rsa_es + pub (ya está en PC personal, se excluye), known_hosts (88 KB — excluyo por defecto, repopula solo).
~/code/: 14 dirs, 8 con .env: amadeus, aprende-ingles, deportescampeon, es-antenas-new, greco-cell, holbox, medicinas, monitoreo-collector. (Otros sin .env actualmente: db_backups, hub-web-viewer, jm-admin, jm-checador, jm-contabilidad, joyeriameza.)

Comando a correr en la laptop trabajo (genera ~/parity-secrets-YYYYMMDD.tar.gz.gpg, GPG pide passphrase 2x):

cd ~ && tar czf - \
  .ssh/config \
  .ssh/id_rsa .ssh/id_rsa.pub \
  code/amadeus/.env \
  code/aprende-ingles/.env \
  code/deportescampeon/.env \
  code/es-antenas-new/.env \
  code/greco-cell/.env \
  code/holbox/.env \
  code/medicinas/.env \
  code/monitoreo-collector/.env \
  | gpg -c --cipher-algo AES256 -o ~/parity-secrets-$(date +%Y%m%d).tar.gz.gpg \
  && ls -la ~/parity-secrets-$(date +%Y%m%d).tar.gz.gpg

Sergio puede recortar líneas de .env si decide que algún proyecto se reconfigura desde .env.example en PC personal (p.ej. deportescampeon / greco-cell si son ambientes locales triviales).

Transferencia (#152): scp ~/parity-secrets-YYYYMMDD.tar.gz.gpg sergio-pc:~/ (o USB / Drive). El cifrado simétrico hace seguro cualquier canal.

En PC personal (#153):

mkdir -p ~/parity-incoming && cd ~/parity-incoming \
  && gpg -d ~/parity-secrets-YYYYMMDD.tar.gz.gpg | tar xzf - \
  && ls -la .ssh/ code/*/.env 2>/dev/null

Después merge manual (vimdiff sugerido para ~/.ssh/config, evitando perder los 9 hosts que ya tenía PC personal; mover llaves id_rsa* no-_es a ~/.ssh/ con chmod 600; copiar los .env a cada ~/code/<slug>/).

Para los .env: validar primero que el repo correspondiente esté clonado y en main al día antes de copiarlo (regla feedback_keep_repos_synced).

Script para #150 (tooling base) — listo, sin ejecutar

Diseñado sin PHP ni mysql-client en host — todo via Docker (Sail / wrappers). Vive efímero en /tmp/parity-tooling.sh durante la sesión; canon embebido aquí para reproducirlo si se pierde.

#!/usr/bin/env bash
# machine-parity #150 — instalar tooling faltante en PC personal (WSL2 Sergio)
# Sin PHP ni mysql-client: las apps Laravel y mysql corren via Docker.
# Idempotente.
set -euo pipefail

echo ">>> 1/4 apt base (sin PHP ni mysql-client — todo via Docker)"
apt-get update -qq
apt-get install -y -qq software-properties-common ca-certificates curl gnupg unzip git \
                       wireguard wireguard-tools resolvconf

echo ">>> 2/4 GitHub CLI (repo oficial)"
if ! command -v gh >/dev/null 2>&1; then
  mkdir -p -m 755 /etc/apt/keyrings
  curl -fsSL https://cli.github.com/packages/githubcli-archive-keyring.gpg \
    | tee /etc/apt/keyrings/githubcli-archive-keyring.gpg >/dev/null
  chmod go+r /etc/apt/keyrings/githubcli-archive-keyring.gpg
  echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/githubcli-archive-keyring.gpg] https://cli.github.com/packages stable main" \
    > /etc/apt/sources.list.d/github-cli.list
  apt-get update -qq
  apt-get install -y -qq gh
fi

echo ">>> 3/4 Wrappers docker: composer, mysql, mysqldump"
cat > /usr/local/bin/composer <<'WRAPPER'
#!/usr/bin/env bash
set -e
TTY_FLAG=""
[ -t 0 ] && [ -t 1 ] && TTY_FLAG="-it"
mkdir -p "$HOME/.composer-cache"
exec docker run --rm $TTY_FLAG \
  -v "$PWD":/app \
  -v "$HOME/.composer-cache":/tmp/composer-cache \
  -e COMPOSER_CACHE_DIR=/tmp/composer-cache \
  -u "$(id -u):$(id -g)" \
  -w /app \
  composer:latest "$@"
WRAPPER
chmod +x /usr/local/bin/composer

cat > /usr/local/bin/mysql <<'WRAPPER'
#!/usr/bin/env bash
set -e
TTY_FLAG=""
[ -t 0 ] && [ -t 1 ] && TTY_FLAG="-it"
exec docker run --rm $TTY_FLAG \
  --network host \
  -v "$PWD":/work \
  -w /work \
  mysql:8 mysql "$@"
WRAPPER
chmod +x /usr/local/bin/mysql

cat > /usr/local/bin/mysqldump <<'WRAPPER'
#!/usr/bin/env bash
set -e
TTY_FLAG=""
[ -t 0 ] && [ -t 1 ] && TTY_FLAG="-it"
exec docker run --rm $TTY_FLAG \
  --network host \
  -v "$PWD":/work \
  -w /work \
  mysql:8 mysqldump "$@"
WRAPPER
chmod +x /usr/local/bin/mysqldump

echo ">>> 4/4 Verificación"
gh --version | head -1
wg --version | head -1
echo "wrappers docker:"
ls -la /usr/local/bin/composer /usr/local/bin/mysql /usr/local/bin/mysqldump
if command -v docker >/dev/null 2>&1; then
  echo -n "docker: "; docker version --format '{{.Client.Version}}' 2>/dev/null || echo "instalado pero daemon no responde"
else
  echo ""
  echo "⚠️  docker NO está en PATH de esta distro WSL."
  echo "    Activa en Docker Desktop:  Settings → Resources → WSL Integration → toggle 'Sergio' → Apply & Restart"
fi
echo ">>> Listo."

Pre-requisito antes de ejecutar: Sergio activa la integración WSL en Docker Desktop (Settings → Resources → WSL Integration → Sergio → Apply & Restart). Verificado en esta sesión que docker no está en PATH de esta distro hasta que se haga eso.

Ejecutar (siguiente sesión): !sudo bash /tmp/parity-tooling.sh (un solo prompt de password).

Regla “verificar última versión” (a aplicar en #159)

Borrador para ANTIGRAVITY.md del hub, sección Reglas:

Antes de tocar código en cualquier proyecto bajo ~/code/ o ~/agy/electrosystems/servers/: correr git -C <ruta> fetch && git -C <ruta> status -uno y reportar resultado (al día / atrás N commits / cambios locales sin push). Si hay desfase, preguntar a Sergio si pull antes de continuar — puede ser que la máquina contraria tenga trabajo aún no integrado. Aplica a cualquier sesión, no solo PC personal: aplica también a laptop trabajo a partir de ahora.

Plan de diagnóstico WG VM (#157 “diagnosticar primero” — listo para correr cuando haya VPN)

Objetivo: documentar la VM wireguard (alias SSH wireguard → 192.168.20.5, user electrosystems) para decidir migración OpenVPN→WG y, de paso, crear su perfil de host (#079/#078b de [[wireguard-jrz-elp]]). Todo read-only. La mayoría de wg/iptables necesitan root; si electrosystems no tiene NOPASSWD, paso a Sergio el ssh -t wireguard "sudo …" para pegar con !.

# 1. interfaz, IPs, rutas (sin sudo)
ssh wireguard 'hostname; ip -br addr; ip route; sysctl net.ipv4.ip_forward'
# 2. estado WireGuard (probable que pida root)
ssh wireguard 'sudo wg show all 2>/dev/null || wg show all'
ssh wireguard 'sudo cat /etc/wireguard/wg0.conf 2>/dev/null'   # peers + AllowedIPs + endpoint
# 3. NAT / forwarding (root)
ssh wireguard 'sudo iptables -t nat -S; sudo iptables -S FORWARD'

Qué busco / preguntas a responder:

Topología: ¿road-warrior (clientes remotos) o site-to-site? ¿Cuántos peers, cuáles son?
Subnet del túnel WG (ej. 10.x del lado servidor) y qué AllowedIPs anuncia hoy cada peer (ya sabemos que rutea 192.168.167.0/24).
NAT/forwarding: ¿hace MASQUERADE hacia 192.168.20.x / 10.11.x? Esto define cuánto trabajo es extender el peer del PC personal para alcanzar esas familias.
Con eso: plan concreto de migración (qué agregar en server + qué .conf baja al cliente WG de Windows) o recomendación de quedarse en OpenVPN.

Bitácora

2026-05-29 (laptop trabajo) — #411 dual-push de electrosystems arreglado

Pidió Sergio: arrancar #411. Modelo elegido: dual-push combinado por origin (un solo git push toca GitHub + NAS).
Diagnóstico: en la laptop, ~/agy/electrosystems tenía main rastreando nas/main, así que el git push pelón (incluido el auto-push del hub) iba solo al NAS → GitHub se rezagaba. El remote origin ya estaba bien: dos push-urls (GitHub docs.git + NAS asterisk.git); nadie le pusheaba. No había divergencia real: GitHub (a743fd8) ya incluía todo lo del NAS (alguien reconcilió desde el PC personal — commit “Merge nas/main: sync GitHub with NAS canonical”); local/NAS (141d60a) era ancestro → todo fast-forward, sin riesgo.
Hice: (1) git branch --set-upstream-to=origin/main main; (2) git merge --ff-only origin/main (local 141d60a→a743fd8, trae servers/wireguard/README.md + INVENTORY); (3) git push origin main → “Everything up-to-date” 2× (una por cada push-url). Verificación con ls-remote directo: local = GitHub = NAS = a743fd8.
Resultado: de aquí en adelante un git push desde la laptop actualiza GitHub + NAS a la vez. Falta: repetir el --set-upstream-to=origin/main la próxima vez que se trabaje electrosystems en el PC personal (mismo riesgo allá).

2026-05-29 (PC personal)

Pidió Sergio: avanzar con #157 (migrar OpenVPN → WireGuard).
Diagnóstico de red (read-only):
- WSL solo tiene eth0 172.24.19.38/20, default vía 172.24.16.1 (host Windows NAT) — todo el VPN se hereda del host, como ya se sabía.
- Barrido TCP a las 4 familias: TODO interno FALLA hoy (10.11.x arias-juarez/gi-corp/indelek, 192.168.20.x orion/nagios/wireguard, 192.168.3.x ares/vpn-push). Solo internet OK (github:443). → El OpenVPN del host está caído ahora mismo.
- Host Windows (ipconfig/tasklist): adaptadores “OpenVPN Wintun” + “OpenVPN Data Channel Offload” presentes pero sin IP (túnel abajo); openvpnserv.exe/openvpnserv2.exe corriendo (servicio sí, túnel no). NO hay adaptador WireGuard → WG instalado pero sin túnel activo. Confirma la bitácora del 27.
- Nota: el smoke test del 27 nunca probó 10.11.x; queda sin verificar si el OpenVPN del host alcanza esa familia (sí alcanzaba 192.168.20.x / 192.168.3.x / 192.168.37.x).
#156 cerrado de paso (prerequisito para diagnosticar el server WG): cloné ~/agy/electrosystems/. Hallazgo clave: no existe perfil servers/wireguard/. El server WG es una VM wireguard (2c/4G) en poseidon que da “Sergio’s WG VPN” y ya rutea 192.168.167.0/24 (sitio remoto) — es el WG road-warrior. Sin doc de sus peers / AllowedIPs / NAT (eso sería #078b del proyecto wireguard-jrz-elp).
Cuestionamiento de la premisa (challenge-assumptions): el OpenVPN del host, cuando conecta, ya cubre 192.168.20.x + 192.168.3.x + sitios remotos 192.168.37.x en un solo túnel — o sea más que el WG de la laptop trabajo (que solo cubre sitios). “Paridad de red” no requiere WireGuard; la da el OpenVPN actual. Migrar a WG unificado solo aporta “dejar de depender de OpenVPN / un solo túnel”, a costa de trabajo en prod sobre la VM wireguard (agregar peer del PC personal + extender AllowedIPs a 10.11.x/192.168.20.x + NAT/forwarding de regreso) — mutación que necesita auth explícita y que hoy ni siquiera puedo diagnosticar (sin conectividad).
Decisión pendiente de Sergio (planteada): mantener OpenVPN vs migrar a WG unificado. Sin eso, #157 no avanza más. Bloqueador físico además: reconectar el VPN del host para recuperar acceso a la infra.
Sergio eligió “diagnosticar primero” y reconectó el OpenVPN. Diagnóstico read-only ejecutado:
- Reverificación de conectividad (OpenVPN arriba): 192.168.20.x (wireguard-vm, monitoreo, orion) ✓, 192.168.3.x (ares) ✓. 10.11.x sigue FALLANDO (arias-juarez .0.66, gi-corp .0.158, indelek .1.210). → El único gap de paridad real es 10.11.0.0/16 (todo lo demás ya lo alcanza el OpenVPN del PC personal).
- OpenVPN del PC personal = perfil celsergio (/mnt/c/Users/sevao/OpenVPN/config/celsergio/celsergio.ovpn): client / proto udp / remote vpnus.electrosystemsnet.com 1194 / dev tun. Sin directivas route propias → todas las rutas vienen por push del server. Hoy el server empuja 192.168.20.x + 192.168.3.x + sitios pero no 10.11.x. (El alias vpn-push → 192.168.3.50 es el sospechoso del lado server OpenVPN.)
- VM wireguard (192.168.20.5, ens3; gw 192.168.20.254; ip_forward=1): wg0 = túnel 10.255.255.0/24 (server .1). wg0 rutea sitios: 192.168.14/27/36/37/38/44/45/47/50/51(/28)/72/150/151/152/154/163/167/173 + 10.20.0/22, 10.20.4/22, 10.20.30/24, 10.37.1.0/28, 10.37.1.16/28, 10.143.39/24, 10.163.0/24. NO rutea 10.11.0.0/16 por el túnel, PERO la VM sí alcanza 10.11.x vía gw 192.168.20.254 (ping 10.11.0.66 y 10.11.1.210 OK, ~46ms). → Dar 10.11.x por WG es factible (agregar AllowedIPs + MASQUERADE en el server).
- wg show / iptables necesitan root y electrosystems no tiene NOPASSWD (sudo pide password). Peers / AllowedIPs / listen-port / NAT del server quedan pendientes de un ssh -t wireguard "sudo …" que pegue Sergio (o de la decisión A/B).
Conclusión del diagnóstico → fork con costos reales:
- Path A (quedarse en OpenVPN, fix quirúrgico): que el server OpenVPN (vpnus… / probablemente vpn-push 192.168.3.50) empuje 10.11.0.0/16 al cliente celsergio (o ccd/iroute). 1 cambio chico en prod, conserva el setup que ya funciona. Cierra el gap.
- Path B (migrar a WG unificado, #157 como se escribió): nuevo peer en la VM wireguard con AllowedIPs = sitios + 192.168.20/3.x + 10.11.0.0/16; server debe forward+MASQUERADE hacia esas familias para el peer; reconfigurar cliente WG de Windows; eventualmente apagar OpenVPN. Más trabajo en prod, reconstruye conectividad que ya funciona, gana “un solo túnel / soltar OpenVPN”.
- Recomendación: Path A es el mínimo que da paridad (solo falta 10.11.x). Path B solo si Sergio quiere consolidar en WireGuard a propósito. Ambos tocan prod → necesitan auth. (Sergio eligió B; ejecutado y cerrado el mismo día — ver “Cierre #157+#158” abajo.)
Sergio eligió Path B (migrar a WireGuard unificado). Su selección = visto bueno per-sesión para tocar la VM wireguard en prod. Ejecución por pasos, reversible, mostrando cada cambio. Como electrosystems no tiene NOPASSWD, las mutaciones (wg set/iptables) las pega Sergio con !ssh -t wireguard "sudo …".
- WireGuard de Windows: instalado (wg.exe/wireguard.exe) pero sin túneles (carpeta Configurations vacía/protegida, proceso no corriendo) → cliente WG desde cero.
- Plan de ejecución Path B: (1) gather sudo del server (listen-port, peers, AllowedIPs, NAT — sin volcar llaves privadas). (2) Conseguir el endpoint público WG (host:puerto) — fuente: el config WG de la laptop trabajo. (3) Crear túnel en el WireGuard de Windows (genera su par de llaves, expone la pública). (4) sudo wg set wg0 peer <PUB_CLIENTE> allowed-ips 10.255.255.X/32 + persistir + MASQUERADE/forward si falta para 192.168.20/3.x + 10.11.0.0/16. (5) Armar el [Interface]/[Peer] del cliente (AllowedIPs = sitios + 192.168.20/3 + 10.11.0.0/16 + 10.255.255.0/24). (6) Conectar, validar paridad (incl. 10.11.x), apagar OpenVPN.

Gather del server `wireguard` (2026-05-29, ejecutado por Sergio con sudo)

Interface wg0: pubkey server 7FojUmorOzhOH0lgWDmYJd58xkrixCFtTuI16IEGER8=, ListenPort 51820, Address 10.255.255.1/24.
NAT/forward (clave): PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -t nat -A POSTROUTING -o ens3 -j MASQUERADE (+ PostDown inverso). Reglas vivas confirmadas: -A POSTROUTING -o ens3 -j MASQUERADE y -A FORWARD -i wg0 -j ACCEPT. → MASQUERADE general en ens3 + forward total desde wg0 ⇒ el server NO necesita reglas nuevas: cualquier destino que sepa rutear (192.168.20.x local, 10.11.x / 192.168.3.x vía gw .254) ya sale NAT’eado para cualquier peer. El único cambio server-side es agregar el peer.
Peers (13, road-warrior + sitios): .2 Chihuahua (10.20.x/10.37.x/192.168.27/37/38/50/51/72), .3 Parral (10.143.39/192.168.44/45/47), .4 Caborca (192.168.151/152), .5 Nogales (192.168.150), .6 Villa Ahumada (192.168.167), .7 Torreon (192.168.14), .8 PruebaPush (solo /32), .9 LaptopGus (solo /32, road-warrior), .10 Tepehuanes (192.168.154), .11 Barretal (192.168.163/10.163.0), .12 Nexpa (192.168.173), .13 Colonia del Valle (192.168.36). IPs .1–.13 ocupadas → al PC personal le toca 10.255.255.14 (server-side allowed-ips = solo 10.255.255.14/32, patrón road-warrior tipo LaptopGus).
Pre-flight overlap: LAN física del host = WiFi 192.168.35.0/24 (gw .35.1); WSL = 172.24.x. Ninguna subred del túnel choca → seguro enumerar subredes (NO 192.168.0.0/16).

Cierre #157 + #158 (2026-05-29) — migración ejecutada y validada

Endpoint público real: 201.174.219.154:51820 (Sergio corrigió; mi estimación inicial 201.218.172.1 estaba mal). El firewall hace DNAT del UDP 51820 → VM 192.168.20.5.
Corrección de modelo: la laptop trabajo NO tiene WireGuard — está en la red y ve todo por su default gw. O sea el “dual VPN” que asumí no aplica; para una máquina remota (PC personal) la paridad se logra metiendo las redes por WG. Queda corregido.
Cliente Windows: túnel es-wg, par de llaves generado por el WireGuard de Windows (pubkey xs+BVhrfvvvuwLKwIGIUgoUGL8cLmbXwmcBVKEYl7Xs=), Address 10.255.255.14/32, Endpoint 201.174.219.154:51820, split-tunnel (sin DNS, internet directo). AllowedIPs = 10.255.255.0/24, 10.11.0.0/16, 10.20.0.0/16, 10.37.0.0/16, 10.143.39.0/24, 10.163.0.0/24, 192.168.3/10/14/20/27/36/37/38/44/45/47/50/51/72/150/151/152/154/163/167/173.0/24 + 172.16.0.0/16 (oficina .0/24, radios .1/24, cámaras .2/24 — lo agregó Sergio).
Server: peer agregado con wg set (runtime) + append a /etc/wireguard/wg0.conf (persistente). Sin cambios de iptables — el PostUp ya hace MASQUERADE general en ens3.
Validación desde WSL (WG arriba, OpenVPN retirado): 10.11.x — gi-corp .0.158:58695 ✓, indelek-jrz .1.210:22 ✓, arias-juarez .0.66 ping 56ms + :22 ✓ (no tiene 58695, era cosa del puerto). 192.168.20.x — orion/monitoreo/wg-vm ✓. 192.168.3.x — ares ✓. 172.16.0.1 ping 12ms ✓. sitio 192.168.37.1 ping 18ms ✓. internet (github:443) ✓ directo. WSL hereda el túnel WG por NAT igual que con OpenVPN.
Resultado: #157 y #158 cerrados. Paridad de red total (y superior: ahora también oficina 172.16.x) por un único túnel WireGuard split-tunnel. OpenVPN ya no se necesita.
Cleanup sugerido (no bloqueante): poner el cliente OpenVPN en no-autoconectar y es-wg en activar al inicio / on-demand, para que tras reboot no compitan rutas. Pendiente menor; no se abrió #.
Doc derivada: se creó el perfil de host ~/agy/electrosystems/servers/wireguard/ (cumple la regla de documentar servers nuevos; cubre #078b/#079 de [[wireguard-jrz-elp]]). Push a GitHub autorizado por Sergio (repo privado) — commit local hecho, push pendiente de reconciliar (ver abajo).
Surgió en la misma sesión:
- Router de oficina (MikroTik 172.16.0.1): Sergio quería administrarlo por WG pero su firewall solo acepta administración desde 172.16.0.0/24, y el tráfico WG llega como 192.168.20.5 (MASQUERADE). No hay jump host Linux en esa /24 (todo dropbear: APs/radios/switch Netonix). Fix aplicado por Sergio: agregó 192.168.20.5 al allow del MikroTik. Verificado desde WSL: HTTP :80 → 200, Winbox :8291 y API :8728 abiertos (SSH :58695 sigue filtrado — falta actualizar el service ssh/firewall si lo quiere). Quedó como deuda el control fino → #410.
- Pendientes nuevos para la sem. del 1–7 jun: #408 (WG en celular), #409 (proceso repetible para más clientes WG), #410 (acceso fino por cliente WG). _next-id 408→411.
- electrosystems remote nas + divergencia: se agregó el remote nas (svalencia@192.168.20.26:/volume1/NetworkBackups/asterisk.git) + su host key. Hallazgo: GitHub origin está 12 commits atrás del NAS (perfiles de asterisk-adfsa/cpe/l2l-telcel/laptop-ia/monitoreo/nagios/sw-villa-ahumada + regla ANTIGRAVITY.md, ~1800 líneas que nunca llegaron a GitHub; el NAS es la copia canónica). Mi push del perfil WG a GitHub divergió. Propuesta (pendiente de OK de Sergio): git merge nas/main (único conflicto INVENTORY.md, combinar) → git push nas main (ff) → git push origin main (ff) para dejar local/NAS/GitHub idénticos. Sin force-push. El dual-push de la laptop conviene arreglarlo allá para que GitHub no se vuelva a rezagar.
Pidió Sergio: avanzar con #152.
Confirmado: estoy en PC personal (Sergio); el tarball no está aquí — sigue en laptop trabajo (~/parity-secrets-20260526.tar.gz.gpg, 6469 bytes, AES256). Sin ruta SSH work→home hoy (WG unificado es #157/#158).
Decisión de canal: email a sí mismo (sevaor@gmail.com). 6.5 KB cabe sobrado y el .gpg ya está cifrado simétrico, así que el canal no necesita ser seguro.
Sergio envió y bajó el adjunto: tarball en ~/parity-incoming/parity-secrets-20260526.tar.gz.gpg, 6469 bytes — tamaño idéntico al de origen → integridad implícita. #152 cerrado.
#153 ejecutado end-to-end:
- Decrypt: Sergio corrió gpg -d | tar xzf - en ~/parity-incoming/; extrajo .ssh/config (4919b), id_rsa + .pub (sergio@SergioLaptop 3072b RSA, fingerprint SHA256:BUYgCXl2T...), 8 .env.
- Merge .ssh/config: 13 hosts existentes vs 65 del tarball. Hosts solapados (monitoreo, holbox, grecocell, val-soft, jmeza, orion) — tarball igual o mejor en todos (jmeza con hostname > IP; orion con HostkeyAlgorithms para CentOS viejos). Único exclusivo de PC personal: Host github.com, bug detectado (apuntaba a ssh.github.com sin Port 443 — solo funcionaba gh via HTTPS, no SSH). Decisión: reemplazar config con el del tarball, preservar github.com arreglado con Port 443 + User git. Backup en ~/.ssh/config.bak.20260527.
- Llaves: id_rsa/id_rsa.pub copiadas, chmod 600/644. id_rsa_es intacta. SSH test git@github.com → “Hi sevaor! You’ve successfully authenticated”.
- Repos atrasados: git pull --ff-only en amadeus (2 behind), es-antenas-new (6 behind), greco-cell (2 behind). Aplicada regla feedback_keep_repos_synced.
- .env distribuidos: 4 sin .env existente (amadeus, es-antenas-new, medicinas, monitoreo-collector) — copia directa. 3 con .env existente (aprende-ingles, greco-cell, holbox) — backup .env.bak.20260527 + reemplazo con autorización per-slug (aprende-ingles tarball trae OPENAI_API_KEY real; greco-cell tarball más moderno; holbox tarball con config Sail). deportescampeon defer a #155 (39 behind + 5 dirty + .env distinto).
- Smoke SSH: github + holbox + grecocell + jmeza + deportescampeon + apolo + val-soft + monitoreo + poseidon — todos OK.
Conectividad a redes internas (corregido por Sergio 2026-05-27): desde PC personal hay conectividad transparente a 192.168.20.x (val-soft 13ms, monitoreo 11ms, poseidon SSH OK), 192.168.3.x (ares/laptop-ia) y 192.168.37.x (sitios remotos, 22ms). Lo asumí WG-en-host pero es OpenVPN en Windows que WSL hereda por NAT. WireGuard sí está instalado en Windows pero no conectado. known_hosts poblado para ssh.github.com:443 + github.com:22.
#157/#158 reformulados: el objetivo no era “setup inicial” sino migrar de OpenVPN → WireGuard usando el server WG de trabajo, para tener paridad exacta de red con laptop trabajo. Queda como pendiente para próxima sesión. El peer WG vive en Windows host, no en WSL.

2026-05-26 (tarde, desde laptop trabajo)

Pidió Sergio: retomar #151 ahora que está en la laptop del trabajo.
Hice: inventario real de ~/.ssh/ y ~/code/ en LaptopWindows (laptop trabajo, no PC personal). Detecté llaves SSH adicionales (id_rsa + .pub ene-2024 — NO _es) y 8 .env en ~/code/ (amadeus, aprende-ingles, deportescampeon, es-antenas-new, greco-cell, holbox, medicinas, monitoreo-collector). Re-escribí “Idea del tarball” como comando canónico con whitelist explícita derivada del inventario (sin globs ls $(...) para que sea revisable a simple vista antes de correr).
Hallazgo importante para #156: ~/agy/electrosystems/ ya tiene remote origin = git@github.com:electrosystems-mx/docs.git (14 MB). No necesita tarball ni snapshot — en PC personal basta git clone con la llave id_rsa_es ya presente. Actualicé el #156 con esa confirmación; aliviana el alcance del tarball.
Sergio corrió el comando: primer intento falló con gpg: problem with the agent: Inappropriate ioctl for device (sin TTY para pinentry); se resolvió agregando --pinentry-mode loopback. Tarball generado: ~/parity-secrets-20260526.tar.gz.gpg (6469 bytes, AES256+SHA512). #151 cerrado.
Próximo paso: Sergio decide cómo transferir el tarball a PC personal. Sin ruta SSH work→home directa (WG unificado es #157/#158); opciones viables — USB, Google Drive / Dropbox / cualquier nube personal (el archivo ya está cifrado, no requiere canal seguro adicional), o email a sí mismo dado que pesa 6.5 KB. Allá se procesa #153 (merge .ssh/config, mover llaves, copiar .env).

2026-05-26

Pidió Sergio: retomar el proyecto en el orden propuesto — primero Docker + script de tooling, después clonar los 6 repos faltantes.
Hice: verificación de estado real vs el plan del 22 — Docker Desktop ya con WSL Integration activa (server 29.4.3); 6 clones en paralelo desde electrosystems-mx (amadeus, monitoreo-collector) y sevaor (jm-admin, jm-checador, jm-contabilidad, medicinas). Tras el primer intento de Sergio donde sudo apt /tmp/parity-tooling.sh falló con “Unsupported file” (typo apt por bash), re-corrió sudo bash /tmp/parity-tooling.sh y todo OK: wireguard-tools 1.0.20210914 instalado, wrappers Docker composer 2.9.8 (Composer baja PHP 8.5.6 dentro del image) y mysql 8.4.9 validados desde el host.
Cerré: #150 (tooling base completo), #154 (los 6 repos faltantes clonados), #159 (regla “verificar última versión” ya está como memoria feedback_keep_repos_synced, no necesita formalización en ANTIGRAVITY.md a menos que Sergio prefiera).
Hallazgo lateral: apareció ~/code/hub-web-viewer/ que no estaba en el plan original — es el viewer del hub (proyecto propio) que se clonó entre el 22 y hoy. No requiere acción.
Próximo paso: generar comando del tarball cifrado (#151) para que Sergio lo corra en laptop trabajo y traiga los secretos.

2026-05-22

Pidió Sergio: que la PC personal tenga paridad completa con la laptop del trabajo (repos, SSH, acceso a servidores) y una regla para verificar última versión antes de cambios.
Hice: inventario inicial de la PC personal (ver “Notas técnicas”), identifiqué el gap (8 repos, SSH config muy incompleta, falta electrosystems/, falta tooling Laravel/WG). Pregunté tres decisiones; Sergio respondió: tarball cifrado manual, alcance = todos los proyectos, y aclaró que WireGuard hoy solo cubre sitios remotos pero quiere unificar 10.11.x + 192.168.20.x + sitios bajo WG. Creé este proyecto con plan de 10 tareas (#150-#159).
Diseñé el script de #150 (tooling base) — primera versión con PHP 8.2 + extensiones + composer apt; Sergio pidió todo via Docker, lo rehice: sin PHP ni mysql-client, solo gh + wireguard-tools apt + wrappers docker en /usr/local/bin/ para composer, mysql, mysqldump. Script canon embebido arriba en “Notas técnicas”.
Estado al cerrar sesión: script listo pero no ejecutado. Sergio dijo “dejalo pendiente y cerramos sesión”. Antes de ejecutarlo se necesita: (1) activar WSL Integration en Docker Desktop para la distro Sergio, (2) correr !sudo bash /tmp/parity-tooling.sh (o copiar del .md si /tmp ya se borró).
Falta: las 10 tareas (#150-#159) siguen abiertas. Próximo paso al retomar: ejecutar el script de #150 y validar docker version + composer --version + mysql --version antes de seguir con #151 (generar comando del tarball).

machine-parity

Pendientes abiertos (4)

🎯 Top de ataque (4)

Actividad en bitácora 3 días

Machine parity — laptop trabajo ⇄ PC personal (WSL2 Sergio)

Contexto

Decisiones tomadas (sesión 2026-05-22)

Tareas pendientes

En progreso

Notas técnicas

Inventario inicial (2026-05-22, PC personal `Sergio`)

Aclaración sobre la red (corrección de Sergio 2026-05-22)

Comando canónico del tarball (#151) — derivado del inventario real de la laptop trabajo (2026-05-26)

Script para #150 (tooling base) — listo, sin ejecutar

Regla “verificar última versión” (a aplicar en #159)

Plan de diagnóstico WG VM (#157 “diagnosticar primero” — listo para correr cuando haya VPN)

Bitácora

2026-05-29 (laptop trabajo) — #411 dual-push de electrosystems arreglado

2026-05-29 (PC personal)

Gather del server `wireguard` (2026-05-29, ejecutado por Sergio con sudo)

Cierre #157 + #158 (2026-05-29) — migración ejecutada y validada

2026-05-26 (tarde, desde laptop trabajo)

2026-05-26

2026-05-22

Pendientes abiertos (4)

🎯 Top de ataque (4)

Actividad en bitácora 3 días

Machine parity — laptop trabajo ⇄ PC personal (WSL2 Sergio)

Contexto

Decisiones tomadas (sesión 2026-05-22)

Tareas pendientes

En progreso

Notas técnicas

Inventario inicial (2026-05-22, PC personal Sergio)

Aclaración sobre la red (corrección de Sergio 2026-05-22)

Comando canónico del tarball (#151) — derivado del inventario real de la laptop trabajo (2026-05-26)

Script para #150 (tooling base) — listo, sin ejecutar

Regla “verificar última versión” (a aplicar en #159)

Plan de diagnóstico WG VM (#157 “diagnosticar primero” — listo para correr cuando haya VPN)

Bitácora

2026-05-29 (laptop trabajo) — #411 dual-push de electrosystems arreglado

2026-05-29 (PC personal)

Gather del server wireguard (2026-05-29, ejecutado por Sergio con sudo)

Cierre #157 + #158 (2026-05-29) — migración ejecutada y validada

2026-05-26 (tarde, desde laptop trabajo)

2026-05-26

2026-05-22

Inventario inicial (2026-05-22, PC personal `Sergio`)

Gather del server `wireguard` (2026-05-29, ejecutado por Sergio con sudo)