# 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.

Current FST KZ server, installed 2026-10-01:

- Server IP: `109.248.18.18`; FST Console service ID `3851`, VPS Premium 50C, 3 vCPU / 4 GB RAM / 50 GB disk. Verified provider page: `https://my.fst.kz/console/vps/3851`.
- SSH user: `root`; hostname: `vm9015.fst.kz`; Ubuntu 26.04 LTS (resolute), kernel `7.0.0-22-generic`.
- Dedicated private key: `.ssh/codex_fst_109_248_18_18`; public key: same path with `.pub`; pinned host file: `.ssh/known_hosts_fst_109_248_18_18`.
- Independent key-only login was verified. ED25519 host fingerprint: `SHA256:ocYsqr32wbMuisMVbDHWcceAabUDZv4wwx0dMcR73XI`, matched after authenticated login. Do not print or move the private key outside this project.
- SSH backup: `/root/codex-backups/ssh-bootstrap-20261001-112124/`.
- AmneziaWG tools/kernel module `3.1.20260812` installed from the official PPA; DKMS built for 7.0.0-15 and current 7.0.0-22. Services `awg-quick@awg0` and `awg-quick@awg1` are active/enabled.
- `awg0`: AmneziaWG 3.1, UDP 443, 10 peers `10.71.71.2` through `.11` plus ULA `fd71:71:71::2` through `::b`. IPv4 internet egress works; IPv6 is captured by the client tunnel but has no internet egress on the VPS.
- `awg1`: AmneziaWG 2.0 compatible with GL-MT3000 firmware 4.11.0, UDP 444, 10 independent peers `10.72.72.2` through `.11`, IPv4. Each device must use its own peer. Do not import the 3.1 profile into this older router client.
- Server configs: `/etc/amnezia/amneziawg/awg0.conf`, `/etc/amnezia/amneziawg/awg1.conf`; firewall/NAT/MSS hook: `/usr/local/sbin/awg-kazakhstan-firewall`; IPv4 forwarding: `/etc/sysctl.d/90-amneziawg-kazakhstan.conf`; external interface `ens3`.
- Remote exports: `/root/vpn-configs/amneziawg-kazakhstan-3.1-20261001/` and `/root/vpn-configs/amneziawg-kazakhstan-router-20261001/`. Local exports are in `amneziawg_109_248_18_18/`, with filenames `KZ-AWG31-01.conf` through `-10.conf` and `KZ-Router-01.conf` through `-10.conf`, and matching QR files.
- Preserve external filename aliases: local profile 02 is `KZ-AWG31-02Air.conf`, QR is `KZ-AWG31-02-Air.png`; bytes match server profile 02.
- Live user diagnosis pending: on 2026-10-01 the user reports 3.1 failing on phone/router and 2.0 unstable; Mac works. The observed 3.1 peer 01 arrives via VDSina 77.105.138.138, so this does not verify direct ISP connectivity. Router-compatible peers 01 and 10 have real handshakes and traffic, but this does not prove stability. Do not mark installation end-to-end healthy until the real clients are verified.
- All 20 passed key/hash, handshake, DNS and HTTPS egress tests in isolated namespaces on the VPS. This does not verify a direct mobile/home ISP path or real router traffic. Namespace/veth test resources were removed; test handshakes must not be mistaken for real user connections.
- Backups: install `/root/codex-backups/amneziawg-install-20261001-112653/`, configure `/root/codex-backups/fst-amneziawg-configure-20261001-112901/`. No full OS upgrade or reboot was performed.
- The user explicitly retired old KZ SSH access and configurations on 2026-10-01. This supersedes prior permanent-access instructions for `109.248.247.53` only. Old KZ files are preserved in `VPNlist/Backup/retired-kazakhstan-20261001-142842/old-kazakhstan-configs-and-ssh.tar.gz`; they are no longer authoritative. Do not restore them automatically or connect to the old IP with its changed host key.

Preferred SSH command from this project directory:

```sh
ssh -i .ssh/codex_fst_109_248_18_18 \
  -o UserKnownHostsFile=.ssh/known_hosts_fst_109_248_18_18 \
  -o StrictHostKeyChecking=yes \
  -o IdentitiesOnly=yes \
  root@109.248.18.18
```

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.
- VLESS for Mac verified 2026-10-02: Xray 26.3.27, service `xray` active/enabled, added separate inbound `vless-mac-20261002` on `18443/tcp`, VLESS Reality Vision with `www.cloudflare.com` target and Chrome fingerprint. Existing 8443/9443 inbounds and all Synology forwarding/firewall rules preserved. Backup `/root/codex-backups/vdsina-mac-vless-20261002-111330/`. Remote client export `/root/vpn-configs/vless-vdsina-mac-20261002/`; local `vless_77_105_138_138/mac-clash-verge-20261002/`. Mac Clash Verge Rev 2.5.6 uses profile `VDSina — VLESS`, Rule mode, System Proxy ON, TUN OFF, Sidecar. Five active-core HTTPS checks passed; logs prove VLESS proxy selection. Current router route can already return 77.105.138.138 without local VLESS, so IP alone is insufficient proof. Long-term/mobile/router VLESS stability is untested.
- 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.18.18` 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 `109.248.18.18`: two AmneziaWG interfaces as detailed above, 10 profiles each. Local source: `amneziawg_109_248_18_18/amneziawg-kazakhstan-3.1-20261001/` and `amneziawg_109_248_18_18/amneziawg-kazakhstan-router-20261001/`.
- KZ delivery ZIPs: `amneziawg_109_248_18_18/AmneziaWG-Kazakhstan-3.1-10-configs-20261001.zip` and `amneziawg_109_248_18_18/AmneziaWG-Kazakhstan-Router-10-configs-20261001.zip`. See `delivery-verification.json` for exact saved artifact verification.
- The former FST KZ WireGuard/AmneziaWG/VLESS exports and `2026/2026 KZ/` were retired at the user's explicit request; preserve historical evidence in the dated closed backup only. No VLESS or Jitsi was requested on the new VPS.
- `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.
- `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,<domain>,PROXY`;
  - emit IPv4 CIDRs as `IP-CIDR,<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_BEGIN -->
## 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`, текущими файлами и просьбой пользователя, текущая просьба пользователя главнее, но конфликт надо явно отметить в ответе.
<!-- TWO_CODEX_COORDINATION_END -->