# Project Memory: VPN and Synology This file is the durable project memory for `/Users/sergeiberezin/Documents/VPN`. Use it before changing VPN configs, Synology access rules, or tunneling lists. ## Safety Rules - Treat this directory as sensitive infrastructure. VPN configs may contain private keys, PSK values, endpoints, peer names, and internal addresses. - Do not paste private keys, preshared keys, passwords, or full client configs into chat or new documentation unless the user explicitly asks for that exact secret material. - Before changing any live or current list/config, make a backup copy or preserve the previous version in `VPNlist/Backup/` or an adjacent dated file. - Prefer report/diff first for bulk edits. For generated tunneling lists, show what changed before replacing the authoritative file. - Do not delete old configs unless explicitly asked. `Old/` is historical evidence for how access was organized. - `.DS_Store` files are irrelevant and should not be treated as config. ## Synology Access: Known Organization Current known Synology forwarding is documented in: - current VDSina gateway live config on `77.105.138.138`: `/root/berezaport.sh` and `/etc/systemd/system/bereza-synology-forward.service` - `Old/WireGuard/Script/sberdisk.sh` - `Old/WireGuard/Script/rules1.sh` - `Old/WireGuard/Script/rules.sh` - legacy L2TP notes in `Old/L2TP/Script/bereza.sh`, `Old/L2TP/Script/sberdisk.sh`, and `Old/L2TP/Script/bereza_portforward.sh` ## SSH Access and Management New is*hosting Serbia VPN server, SSH verified 2026-10-01: - Server IP: `149.33.55.139`; is*hosting service ID `465933`, Lite Linux NVMe, Serbia, 1 vCPU / 1 GB RAM / 20 GB NVMe. - SSH user: `root`; hostname observed: `a989457113.local`; Ubuntu 22.04.5 LTS, kernel `5.15.0-179-generic` at initial setup. - Dedicated private key: `.ssh/codex_ishosting_149_33_55_139`; public key: same path with `.pub`; pinned host file: `.ssh/known_hosts_ishosting_149_33_55_139`. - Independent key-only SSH login was verified. The key is permanent project access requested by the user; preserve it and never print or move the private key. - SSH host ED25519 fingerprint: `SHA256:P44aG2u4K5tUgE8FvbHA5wPXahnJ+bwYLK6XwfxmASY`, matched again after authenticated login. - Use `ssh -i .ssh/codex_ishosting_149_33_55_139 -o UserKnownHostsFile=.ssh/known_hosts_ishosting_149_33_55_139 -o StrictHostKeyChecking=yes -o IdentitiesOnly=yes root@149.33.55.139`. - Initial SSH backup: `/root/codex-backups/ssh-bootstrap-20261001-085401/`. - Current role: AmneziaWG 3.1 VPN, kernel module `3.1.20260812`, interface `awg0`, `443/udp`, service `awg-quick@awg0` active and enabled. Server config: `/etc/amnezia/amneziawg/awg0.conf`; firewall hook: `/usr/local/sbin/awg-serbia-firewall`; IPv4 forwarding: `/etc/sysctl.d/90-amneziawg-serbia.conf`. - Ten peers use IPv4 `10.69.69.2` through `.11` and IPv6 ULA `fd69:69:69::2` through `::b`. IPv4 internet egress is enabled; IPv6 is routed into the client tunnel but has no internet egress on the VPS. Each device must use its own peer. - Server export: `/root/vpn-configs/amneziawg-serbia-20261001/`. Local export: `amneziawg_149_33_55_139/amneziawg-serbia-20261001/`; delivery archive: `amneziawg_149_33_55_139/AmneziaWG-Serbia-10-configs-20261001.zip`. The first local config was renamed externally to `Serbia-01-JOB.conf`; its key/content matches the server's `Serbia-01.conf` and QR `Serbia-01.png`. Preserve this name. - All ten peers passed handshake, DNS and HTTPS egress tests from an isolated namespace on the VPS; all ten local QR codes decoded to the exact configs and the ZIP was reopened and verified. Direct Moscow-oblast ISP paths and VPN throughput were not tested. See `verification.json` and `delivery-verification.json` in the export. - One GiB swap was added at `/swapfile-codex-awg`, persisted in `/etc/fstab`. System backup: `/root/codex-backups/amneziawg-install-20261001-085653/`; pre-VPN backup: `/root/codex-backups/amneziawg-configure-20261001-090129/`. Known project-local SSH material: - Private key: `.ssh/codex_fst_109_248_247_53` - Public key: `.ssh/codex_fst_109_248_247_53.pub` - Known hosts file: `.ssh/known_hosts_fst` - Known host: `109.248.247.53` - Confirmed SSH user: `root` - Server hostname: `vm7822.fst.kz` - Provider/console context: FST.KZ VMmanager VPS, service previously seen as `VPS Standart 25C`, VM name `vm7822` - OS observed on 2026-04-29: `Ubuntu 24.04.3 LTS` - The public-key comment is `codex@fst-109.248.247.53`; this is only a key comment, not the login user. Preferred SSH command template from this project directory: ```sh ssh -i .ssh/codex_fst_109_248_247_53 \ -o UserKnownHostsFile=.ssh/known_hosts_fst \ -o IdentitiesOnly=yes \ root@109.248.247.53 ``` New VDSina Jitsi test/target server, created 2026-05-29: - Private key: `.ssh/codex_vdsina_89_110_94_203` - Public key: `.ssh/codex_vdsina_89_110_94_203.pub` - Known hosts file: `.ssh/known_hosts_vdsina_89_110_94_203` - Known host: `89.110.94.203` - Confirmed SSH user: `root` - Server hostname after setup: `nest.berezagroup.ru` - Provider/console context: VDSina VDS, initial hostname `v3139659.hosted-by-vdsina.ru` - OS observed on 2026-05-29: `Ubuntu 24.04.4 LTS` - Intended service domain: `nest.berezagroup.ru` Preferred SSH command template from this project directory: ```sh ssh -i .ssh/codex_vdsina_89_110_94_203 \ -o UserKnownHostsFile=.ssh/known_hosts_vdsina_89_110_94_203 \ -o IdentitiesOnly=yes \ root@89.110.94.203 ``` VDSina Synology forwarding gateway / VLESS Reality target server, key prepared 2026-06-16: - Private key: `.ssh/codex_vdsina_77_105_138_138` - Public key: `.ssh/codex_vdsina_77_105_138_138.pub` - Known hosts file: `.ssh/known_hosts_vdsina_77_105_138_138` - Known host: `77.105.138.138` - Expected SSH user: `root` - Confirmed SSH user: `root` - Server hostname observed on 2026-06-16: `v2326274.hosted-by-vdsina.ru` - OS/kernel observed on 2026-06-16: Ubuntu host with Linux `5.15.0-179-generic` - Current role: VDSina L2TP/Synology forwarding gateway; preserves public `80/tcp`, `34567/tcp`, and `6690/tcp` forwarding to Synology. - Intended new role: VLESS Reality server target, preferably on currently unused `443/tcp`, after explicit user confirmation and backups. - Port note from 2026-06-16 read-only check: `443/tcp` is not listening, but `443/udp` is already in use by existing VPN-related sockets; do not disturb UDP `443`. - Status: key pair exists locally and the public key is installed on `77.105.138.138`; key-based SSH as `root` is confirmed working. - User instruction from 2026-06-16: keep this root access permanently; do not disable, remove, rotate, or overwrite this key unless the user explicitly asks. - The public-key comment is `codex@vdsina-77.105.138.138`; this is only a key comment, not the login user. Preferred SSH command template from this project directory after the public key is installed: ```sh ssh -i .ssh/codex_vdsina_77_105_138_138 \ -o UserKnownHostsFile=.ssh/known_hosts_vdsina_77_105_138_138 \ -o IdentitiesOnly=yes \ root@77.105.138.138 ``` Operational rules for SSH: - Do not print the private key. Do not copy it outside this project unless the user explicitly asks. - Treat `root@109.248.247.53` as a sensitive persistent server access path. Do not expose private keys, passwords, API tokens, full VPN configs, or QR payload contents in chat. - Synology root-equivalent access, confirmed 2026-06-16: SSH to `sber@sber.familyds.com:8686` with `/Users/sergeiberezin/.ssh/id_exe`, then use `sudo -n` for privileged checks/actions. The temporary sudoers file observed was `/etc/sudoers.d/codex-temp-sber`; do not store or ask for the password in chat. Always verify `hostname`, `whoami`, and `sudo -n whoami` before treating this as active root access. - Before running remote management commands, first identify the remote role: gateway/VPN server vs direct Synology shell. - Prefer read-only checks first: `hostname`, `whoami`, `ip addr`, `ip route`, `sudo -n true`, `iptables-save`, service status. - Do not change iptables, restart networking, reboot, modify Synology services, or rotate keys without explicit user confirmation. - If managing Synology through the current VDSina forwarding gateway, remember that external `34567/tcp` forwards to Synology DSM HTTPS `192.168.42.10:5001`, while external `6690/tcp` forwards to Synology Drive sync. Older historical gateways may still mention external `5001/tcp`. - If direct SSH into Synology is needed, verify the Synology SSH address/user first; current durable evidence mainly documents the gateway/forwarding path and the project-local SSH key for `109.248.247.53`. Known WireGuard/Tailscale-era path: - Public gateway IP: `109.107.173.238` - External interface: `ens3` - Internal overlay interface: `tailscale0` - Gateway overlay/SNAT IP: `100.110.104.6` - Synology overlay/LAN target: `100.110.104.159` - Forwarded ports: - `5001/tcp` to `100.110.104.159:5001` for Synology DSM HTTPS - `6690/tcp` to `100.110.104.159:6690` for Synology Drive sync - Forwarding pattern: - DNAT public gateway port to Synology target - ACCEPT forwarding from `ens3` to `tailscale0` - SNAT return traffic to `100.110.104.6` Generic WireGuard/Tailscale helper in `Old/WireGuard/Script/rules.sh`: - `EXT_IP=109.107.173.238` - `INT_IP=100.110.104.6` - `EXT_IF=ens3` - `INT_IF=tailscale0` - Arguments are `FAKE_PORT LAN_IP SRV_PORT` - It adds PREROUTING DNAT, POSTROUTING SNAT, OUTPUT DNAT, and FORWARD ACCEPT rules. Current VDSina L2TP/Synology gateway path, updated 2026-05-29: - Public gateway IP: `77.105.138.138` - External interface: `ens3` - Internal VPN interface: `ppp0` - Internal gateway/SNAT IP: `192.168.42.1` - Synology LAN target: `192.168.42.10` - Current live forwarding is kernel NAT from `/root/berezaport.sh`, enabled by `bereza-synology-forward.service`. - No home-router inbound port-forward is required for this path: Synology initiates the outbound L2TP/IPsec session to the VDS, then the VDS forwards public traffic back through `ppp0` to `192.168.42.10`. - Forwarded ports as of 2026-05-29: - `34567/tcp` to `192.168.42.10:5001` for Synology DSM HTTPS - `6690/tcp` to `192.168.42.10:6690` - `80/tcp` to `192.168.42.10:80` - External `5001/tcp` on `77.105.138.138` is intentionally closed to reduce DSM brute-force exposure. - The old Docker container `portforward` from `ghcr.io/david-lor/portforward` is stopped and has restart disabled, but is preserved as evidence. Backup/snapshots on the VDS are under `/root/codex-backups/portforward-20260529-115213/`. - `berezagroup.ru` resolves directly to `77.105.138.138`; `berezagroup.com` was observed behind Cloudflare proxy on 2026-05-29, so `:34567` will not work through Cloudflare unless the DNS record is switched to DNS-only or a Cloudflare-supported port/product is used. - Synology currently serves the `sber.familyds.com` certificate on this DSM path; `berezagroup.ru` and `berezagroup.com` need a matching Synology certificate/SAN assignment before browsers will trust those hostnames on `:34567`. - There are old experiments with `ghcr.io/david-lor/portforward`; treat them as historical unless the user says to revive Docker-based forwarding. ## VPN Config Inventory Current and recent config families: - Current FST KZ server `109.248.247.53` is primarily a VPN server. On 2026-04-29 it had active `awg0` and `wg0` interfaces, AmneziaWG config at `/etc/amnezia/amneziawg/awg0.conf`, WireGuard config at `/etc/wireguard/wg0.conf`, and UDP listeners on `443` and `51820`. - Current AmneziaWG client export from `109.248.247.53` is local in `amneziawg_109_248_247_53/amneziawg-client-export/`, with 10 configs under `configs/client01.conf` through `client10.conf` and matching QR PNGs under `qr/client01.png` through `client10.png`. - The server source for those 10 AmneziaWG client configs was `/root/vpn-configs/amneziawg/client01.conf` through `client10.conf`; a temporary export archive may exist on the server at `/root/amneziawg-client-export.tar.gz`. - Current WireGuard client export from `109.248.247.53` is local in `wireguard_109_248_247_53/wireguard-client-export-20260430-124106/`, with 10 configs under `configs/client01.conf` through `client10.conf` and matching QR PNGs under `qr/client01.png` through `client10.png`. - The server source for those 10 WireGuard client configs was `/root/vpn-configs/wireguard/client01.conf` through `client10.conf`; a temporary export archive may exist on the server at `/root/wireguard-client-export-20260430-124106.tar.gz`. - VLESS Reality on FST KZ `109.248.247.53` was added on 2026-06-17 using Xray `v26.3.27` on nonstandard `8443/tcp`. It is separate from existing Jitsi/nginx/coturn, WireGuard, and AmneziaWG services: `443/tcp` remains nginx/Jitsi, `443/udp` remains AmneziaWG, and `51820/udp` remains WireGuard. Server config is `/usr/local/etc/xray/config.json` and contains Reality private material; do not print it. Remote generated client material is under `/root/vpn-configs/vless-fst-8443/`. Local Mac client exports are in `vless_109_248_247_53/mac-clash-verge-20260617/`, with archive `vless_109_248_247_53/vless-fst-109-248-247-53-20260617-150119.tar.gz`. Local phone export with QR PNGs is in `vless_109_248_247_53/phone-20260617/`, with archive `vless_109_248_247_53/vless-fst-phone-109-248-247-53-20260617-152521.tar.gz`. - FST KZ `109.248.247.53` also has a dedicated Xray client/routing rule added on 2026-06-17 so the Mac can connect to FST but exit through VDSina `77.105.138.138`. This is for cases where direct Mac -> VDSina Reality is unstable but VDSina egress is required. Local Clash export: `vless_109_248_247_53/mac-clash-verge-20260617/fst-to-vdsina-chain-mac-work.yaml`. FST backup before this route was `/root/codex-backups/fst-route-mac-to-vdsina-20260617-170322/`. - FST outbound order must keep `direct` first/default; `vdsina-out` is only for the dedicated user rule for `mac-work-vdsina-chain-20260617`. Backup before the outbound-order correction was `/root/codex-backups/fst-fix-default-outbound-20260617-171624/`. - `2026/2026 KZ/configs/` contains 2026 KZ client configs. - `2026/2026 USA/vpn-configs-45.61.48.198-20260422/` contains USA WireGuard and AmneziaWG exports. - `2026/2026 VDsina/amneziawg-77.105.138.138-2026-04-22/` contains VDsina AmneziaWG exports. - `2025/` contains named Sber/Job client configs from 2025. - `amneziawg_109_248_247_53/` contains a 2026-04-29 AmneziaWG export archive and extracted export. - `.ssh/codex_fst_109_248_247_53` and `.ssh/known_hosts_fst` are project-local SSH access files for the `109.248.247.53` host. Do not expose key contents. - `Old/` contains historical WireGuard, L2TP, KZ, Germany, and Amnezia references. Use it for archaeology, not as the default current source. ## Tunneling Lists: Known Files Authoritative/current working lists appear to be in `VPNlist/`: - `VPNlist/Main.txt`: main domain/IP list for split tunneling. - `VPNlist/all.txt`: merged list. Recent timestamp matches `Main.txt` and `openai.txt`. - `VPNlist/openai.txt`: OpenAI/ChatGPT-related domains. - `VPNlist/wechat.txt`: WeChat/Tencent-related domains. - `VPNlist/MSFS.txt`: Microsoft Flight Simulator related list. - `VPNlist/WGv20260423.txt`: Shadowrocket config generated from `all.txt` version 20260423, with legacy-only rules preserved from `Wireguard_v260211.conf`. - `VPNlist/Backup/`: previous list snapshots and detailed service inventory. Historical/detail files: - `VPNlist/Backup/VPN_services_detailed.txt` records a 2026-02-11 service classification. It lists source files as `Main.txt`, `Microsoft.txt`, and `MSFS.txt`, and summarizes domains/CIDRs by service. - `2026/Temp/list.txt`, `2026/Temp/list_domains_ips.txt`, and `2026/Temp/split_tunnel_updated_with_telegram_calls.txt` are older generated/intermediate split-tunnel lists. - `2026/Temp/Sber/Wireguard_v260211.conf` and `VPNlist/Backup/Wireguard_v260211 - копия.conf` are legacy Shadowrocket-style configs with preserved rules. ## Tunneling List Update Rules - Keep list files plain and deterministic: one domain, IP, or CIDR per line unless the target file format is explicitly Shadowrocket config. - Normalize domains to lowercase, remove schemes (`http://`, `https://`), paths, query strings, and trailing dots. - Deduplicate after merging. Preserve meaningful ordering if the existing file is curated; otherwise sort stable alphabetically for plain domain lists. - Do not remove legacy-only rules from generated Shadowrocket configs unless the user explicitly asks. `WGv20260423.txt` says it preserved legacy-only rules from `Wireguard_v260211.conf`; maintain that behavior. - When regenerating Shadowrocket rules: - keep `[General]` settings intact unless the user asks to change client behavior; - keep private/local ranges in `skip-proxy` and `tun-excluded-routes`; - emit domains as `DOMAIN-SUFFIX,,PROXY`; - emit IPv4 CIDRs as `IP-CIDR,,PROXY,no-resolve`; - keep IPv6 disabled unless the user asks otherwise. - Telegram calls are important. Keep Telegram voice/call domains such as `calls.telegram.org`, `voip.telegram.org`, `stun.telegram.org`, `turn.telegram.org`, and related Telegram domains in the tunneled set. - OpenAI/ChatGPT should include web, API, auth, static asset, LiveKit, WorkOS, Statsig, Sentry, Intercom, and `oaiusercontent` style domains when updating `openai.txt`. - WeChat/Tencent should stay isolated in `wechat.txt` where possible, then be merged into `all.txt` when the user asks for the unified tunnel list. - After updating a source list, update/sync the derived merged list (`all.txt`) and any client-specific generated config that depends on it. - After generation, verify counts and diff against the previous version. Watch for accidental deletion of whole service groups. ## Preferred Workflow 1. Inspect current files with `rg`, `sed`, `wc`, and `diff`. 2. Identify source list(s) to edit: usually `VPNlist/Main.txt`, `VPNlist/openai.txt`, `VPNlist/wechat.txt`, or `VPNlist/MSFS.txt`. 3. Backup the pre-change file(s) when making material updates. 4. Apply a deterministic merge/update. 5. Regenerate `VPNlist/all.txt` and `VPNlist/WGv20260423.txt` or a newly dated replacement if needed. 6. Verify line counts, duplicate counts, and key service presence. 7. Report exactly which files changed and which derived files were synced. ## User Preferences Captured - Remember permanently how Synology access is organized. - Remember that tunneling lists need update and synchronization as a connected workflow, not isolated one-file edits. - Keep project rules in `AGENTS.md` so future work in this folder starts from these assumptions. ## Two-Codex Coordination / Координация двух Codex В этом проекте могут работать два Codex в разное время. Считать неизвестные изменения работой пользователя или второго Codex, не откатывать их без явной просьбы. - Перед началом работы читать этот `AGENTS.md` и `HANDOFF.md` в корне проекта, если он есть. - Перед правками проверять текущее состояние файлов; если проект под git, начинать с `git status` и при необходимости `git diff`. - Не полагаться на доступ к чатам другого Codex: прямой видимости чужих чатов нет. Обмен информацией идет через проектные файлы. - Незавершенную работу, важные решения, заблокированные места и проверочные команды записывать в `HANDOFF.md`. - Подписи в `HANDOFF.md`: текущий агент в этом чате — `Codex A`; второй Codex — `Codex B`. - Рабочее имя `Codex A`: `Aster` (`Codex Aster`). Для совместимости в технических записях сохранять идентификатор `Codex A`. - Рабочее имя `Codex B`: `Lumen` (`Codex Lumen`). Для совместимости в технических записях сохранять идентификатор `Codex B`. - Принятое соответствие: `Codex Aster` = `Codex A`; `Codex Lumen` = `Codex B`. - Если в нужном файле есть свежие чужие изменения, встроиться в них и сохранить их смысл; не переписывать файл целиком без необходимости. - Если обнаружен конфликт между `HANDOFF.md`, текущими файлами и просьбой пользователя, текущая просьба пользователя главнее, но конфликт надо явно отметить в ответе.