# Текст обращения в Yandex Cloud support

**Цель:** снять прозрачный фильтр на SSH-трафик между нашим dev-IP `89.144.17.119` и VM `liderra-test` (`111.88.246.137`). После снятия — прямой SSH с dev-машины снова заработает; пока ходим через GitHub Actions runner как обход.

**Куда отправлять:** консоль Yandex Cloud → раздел «Поддержка» → новое обращение → категория «Сеть» или «Compute Cloud / VM».

**Аккаунт-отправитель:** `Sasha261185@yandex.ru` (владелец cloud `cloud-sasha261185`, id `b1gkjq80utmr51cr929n`).

**Приоритет:** Standard (не P1 — у нас есть рабочий обход через GitHub Actions, не блокирует работу полностью).

---

## Заголовок обращения

```
SSH-трафик с конкретного внешнего IP не доходит до VM — TCP-handshake проходит, но SSH banner не передаётся
```

## Тело обращения

```
Здравствуйте.

Прошу разобраться с блокировкой SSH-трафика на инфраструктурном уровне.
Проблема воспроизводится стабильно с 28.05.2026.

Параметры:
• Облако: cloud-sasha261185 (id b1gkjq80utmr51cr929n)
• Каталог: default (id b1gkcguod0994m1dhoam)
• VM: liderra-test (id fhmu5kbgbui60r773qic), зона ru-central1-a
• Внешний IP VM: 111.88.246.137
• Source IP (откуда идёт SSH-клиент): 89.144.17.119
• Назначение: tcp/22 (SSH)

Что наблюдаем:
1. TCP-handshake с 89.144.17.119 на 111.88.246.137:22 завершается успешно
   (Test-NetConnection и netcat возвращают TcpTestSucceeded=True).
2. После handshake SSH-клиент отправляет свой banner
   (`SSH-2.0-OpenSSH_10.3`).
3. Ответный banner от сервера никогда не приходит — клиент видит
   "Connection timed out during banner exchange" (verbose-лог приложен).
4. На самой VM в журнале sshd (`journalctl -u ssh.service`) за время
   попытки подключения с 89.144.17.119 нет ни единой записи —
   при этом другие SSH-попытки с других внешних IP (включая ботов-сканеров)
   sshd видит и логирует. То есть наши пакеты до sshd-процесса
   физически не доходят.

Что проверили на VM (всё чисто):
• fail2ban: IP 89.144.17.119 НЕ в banlist; явно добавлен в whitelist
  (`/etc/fail2ban/jail.d/whitelist-dev.conf`).
• iptables INPUT policy ACCEPT, никаких DROP/REJECT правил с этим IP.
• nftables `addr-set-sshd` содержит 8 IP — нашего нет.
• ufw неактивен.
• /etc/hosts.deny и /etc/hosts.allow пусты (кроме комментариев).
• sshd_config / sshd_config.d не содержат AllowUsers/DenyUsers/Match
  с этим IP.
• Последние успешные SSH-логины (`last`) — с YC-внутренних IP
  (51.250.124.38, 84.201.183.79) и Azure-IP (172.214.46.100,
  172.215.223.215) — это GitHub Actions runner'ы.
  С 89.144.17.119 успешного входа не было с 28.05.2026.

Гипотеза: на пути между нашим IP 89.144.17.119 и виртуальной машиной
работает анти-DDoS / DPI-фильтр уровня инфраструктуры YC, который
классифицировал наш IP как подозрительный SSH-источник и режет
SSH-banner-обмен (на TCP уровень не влияет — handshake средствами
посредника отрабатывает).

Просьба:
1. Подтвердить наличие фильтра и его источник.
2. Снять блокировку SSH-трафика с 89.144.17.119 на VM 111.88.246.137.
3. Если есть способ заблаговременно добавить наш IP в whitelist
   на уровне облака/VPC/VM — расскажите как.

Спасибо!
```

## Если попросят дополнительные данные

Эти команды/выводы можно показать в support:

- **Verbose SSH-лог** (получен 29.05.2026 04:48 UTC):

  ```
  debug1: Connecting to 111.88.246.137 port 22.
  debug1: Connection established.
  debug1: Local version string SSH-2.0-OpenSSH_10.3
  Connection timed out during banner exchange
  ```

- **Подтверждение что TCP открыт:** `Test-NetConnection -ComputerName 111.88.246.137 -Port 22 -InformationLevel Detailed` → `TcpTestSucceeded: True`.

- **Подтверждение чистоты сервера:** workflow-прогон `ssh-diagnose.yml` в GitHub repo CoralMinister/lidpotok run id 26613087121 — 17 диагностических запросов с подтверждением что на сервере наш IP не заблокирован.

- **Подтверждение что GitHub Actions runners (другие внешние IP) могут зайти:** успешные login'ы с 172.214.46.100 и 172.215.223.215 в `journalctl -u ssh.service` от 29.05.2026 01:45 и 01:47 UTC.

## После ответа YC

Когда YC снимут фильтр — проверить:

1. `ssh -i ~/.ssh/liderra_deploy ubuntu@111.88.246.137 'echo OK'` → должно вернуть `OK` без таймаута.
2. Memory `feedback_github_actions_deploy.md` обновить: «фильтр снят DD.MM.2026, прямой SSH работает; GH Actions остаётся как fallback».
3. `ПИЛОТ.md` §1 обновить (доступ).

Если фильтр снят но через неделю вернётся — добавить в `feedback_environment.md` квирк «YC backbone-фильтр повторно активируется при N+ неудачных SSH/час» с конкретным порогом из ответа YC.
