Глава 3. Серверная часть: VDS и Полный Контроль
2026-02-23
Аннотация В данной главе описывается серверная часть комплекса GuardianT. Мы рассматриваем архитектуру, построенную на принципе минимизации знаний (Zero-Knowledge). Сервер выступает в роли временного буфера, не имея возможности расшифровать проходящий трафик. Особое внимание уделено реализации на Python (FastAPI), работе с оперативной памятью (Redis) и инструкции по развертыванию для пользователей без технического бэкграунда.
3.1. Введение: Почему сервер должен быть «глупым»?
В классических мессенджерах сервер — это "Большой Брат". Он хранит историю, контакты, логи входов. В архитектуре GuardianT сервер выполняет функцию «Слепого курьера».
Его задачи сведены к минимуму:
- Принять зашифрованный пакет от Алисы.
- Подержать его в оперативной памяти (RAM) несколько секунд.
- Отдать пакет Бобу.
- Мгновенно забыть о существовании пакета.
Мы используем связку FastAPI (для высокой скорости обработки запросов) и Redis (база данных, живущая только в оперативной памяти). Если выдернуть шнур питания сервера из розетки, все данные исчезнут безвозвратно. Это не баг, это главная фича безопасности.
3.2. Разбор исходного кода (main.py)
Сервер написан на языке Python. Давайте разберем ключевые блоки файла main.py, чтобы понимать, как именно обеспечивается приватность.
3.2.1. Инициализация и Модели данных
Мы используем библиотеку Pydantic для строгого описания того, как выглядит сообщение. Сервер примет только тот пакет, который соответствует этой структуре.
from fastapi import FastAPI, HTTPException
from pydantic import BaseModel
import redis
# Подключение к Redis (наше временное хранилище в RAM)
r = redis.Redis(host='localhost', port=6379, db=0)
app = FastAPI()
# Модель зашифрованного пакета
class EncryptedPacket(BaseModel):
recipient_id: str # ID получателя (например, "DEVICE_001")
encrypted_blob: str # Сам шифротекст (Base64)
ttl: int = 60 # Время жизни сообщения в секундах
3.2.2. Метод отправки: "Drop" (Бросить)
Когда устройство отправляет сообщение, оно вызывает метод /drop. Обратите внимание на использование команды setex (Set with Expiration).
@app.post("/drop")
async def drop_message(packet: EncryptedPacket):
# Генерируем уникальный ключ для хранения
storage_key = f"msg:{packet.recipient_id}"
# Сохраняем в RAM.
# setex гарантирует, что Redis САМ удалит это сообщение
# через packet.ttl секунд (по умолчанию 60), если его не заберут.
r.setex(
name=storage_key,
time=packet.ttl,
value=packet.encrypted_blob
)
return {"status": "accepted", "info": "Message will self-destruct in 60s"}
3.2. Nginx как обратный прокси
Мы никогда не выставляем Python-сервер (Uvicorn) напрямую в интернет. Перед ним всегда должен стоять Nginx. Он берет на себя:
- SSL/TLS шифрование (HTTPS).
- Защиту от простых DDoS атак (Rate Limiting).
- Проксирование WebSockets (для мгновенной доставки сообщений).
Пример конфигурации /etc/nginx/sites-available/guardiant:
server {
server_name chat.your-domain.com;
# Перенаправление HTTP -> HTTPS
listen 80;
return 301 https://$host$request_uri;
}
server {
listen 443 ssl http2;
server_name chat.your-domain.com;
# Сертификаты (получаем бесплатно через Certbot)
ssl_certificate /etc/letsencrypt/live/chat.../fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/chat.../privkey.pem;
location / {
# Проксируем запросы внутрь Docker-контейнера
proxy_pass http://127.0.0.1:8000;
# Важно для работы WebSockets
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
# Передаем реальный IP клиента (для логов безопасности)
proxy_set_header X-Real-IP $remote_addr;
}
}
3.3. Развертывание в одну команду
Для оркестрации мы используем docker-compose. Это позволяет поднять всю инфраструктуру (Сервер + Redis для временного хранения сообщений) одной командой.
version: '3.8'
services:
server:
build: .
ports:
- "8000:8000"
depends_on:
- redis
redis:
image: redis:alpine
# Redis хранит данные только в RAM. При перезагрузке всё стирается.
# Это фича, а не баг.
Запуск: docker-compose up -d. И ваш личный цифровой остров готов к работе.