# 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/`. - GL-MT3000 on firmware 4.11.0 needs a separate compatible profile. Added `awg1`, `444/udp`, subnet `10.70.70.0/24`, one peer `.2`, profile `amneziawg_149_33_55_139/amneziawg-serbia-router-20261001/configs/Serbia-JOB-AWG2.conf`, with matching QR. Server config is `/etc/amnezia/amneziawg/awg1.conf`, firewall hook `/usr/local/sbin/awg-serbia-router-firewall`. Backup: `/root/codex-backups/serbia-router-awg2-20261001-094848/`. Namespace tests passed, but the router's All policy still had no DNS/HTTPS traffic; do not label the router working based on a handshake alone. - At the user's explicit request, the server was checked and rebooted on 2026-10-01 at approximately 13:39 Moscow time. It booted kernel `5.15.0-194-generic`, module `3.1.20260812`; both VPN services and SSH are active/enabled, no failed services, server DNS/HTTPS works. Both VPN config hashes are unchanged. Pre-reboot backup: `/root/codex-backups/pre-reboot-20261001-103908/`. The post-reboot All test reproduced DNS and HTTPS timeouts. With All off, the Mac exits through existing VDSina `77.105.138.138`; this must not be confused with direct ISP connectivity. Router active-state debug export shows the awg1 route, NAT, forwarding and MTU 1280 present. The separate UDP echo test on port 38544 passed via VDSina only, not the direct Moscow ISP path. On 2026-10-01 the user also reported that the original ten profiles initially worked on the phone but now fail over mobile data; independent phone-path diagnosis is pending. 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`, текущими файлами и просьбой пользователя, текущая просьба пользователя главнее, но конфликт надо явно отметить в ответе.