MTProto на 443 порту з сайтом: VPS для проксі та вебу

Щоб запустити MTProto проксі та веб-сайт на одному VPS через 443 порт, коли інші порти блокуються, застосовується маршрутизація на основі Server Name Indication (SNI), що дозволяє фронтенд-серверу, наприклад Nginx Stream з модулем ssl_preread, аналізувати TLS-хендшейк та перенаправляти трафік або на веб-сервер, або на MTProto-бекенд, що працюють на локальних портах.

Навіщо MTProto проксі на 443 порту, коли там вже працює сайт?

В умовах повсюдних обмежень та блокувань мережевого трафіку, особливо в регіонах з активною цензурою, використання стандартних та загальнодоступних портів стає не просто зручністю, а критичною необхідністю. Порт 443, що традиційно використовується для HTTPS-трафіку, найменш схильний до фільтрації та блокувань, оскільки через нього проходить більша частина зашифрованого веб-трафіку. Якщо ваш Telegram MTProto proxy працює на нестандартному порту, наприклад, 8888 або 9999, існує висока ймовірність, що цей порт буде заблокований інтернет-провайдером або державним фаєрволом. Перенесення MTProto на 443 порт значно підвищує його доступність та стійкість до блокувань, оскільки він "маскується" під звичайний HTTPS-трафік.

Проблема блокувань та важливість стандартних портів

Багато провайдерів та державні системи фільтрації активно використовують глибокий аналіз пакетів (DPI) для виявлення та блокування трафіку, який не відповідає стандартним протоколам на стандартних портах. Наприклад, якщо на порту 443 виявляється трафік, який не є HTTPS, або на порту 80 трафік, який не є HTTP, це може стати сигналом для блокування. MTProto, хоч і зашифрований, має свої характерні патерни. Однак, якщо він працює на 443 порту, його трафік змішується з величезним обсягом легітимного HTTPS-трафіку, що ускладнює його ідентифікацію та блокування. Це особливо актуально для маскування проксі-трафіку.

Економія ресурсів та маскування: проксі й сайт на одному сервері

Запуск MTProto proxy та веб-сайту на одному VPS має подвійну вигоду. По-перше, це економія ресурсів. Замість того, щоб орендувати два окремі VPS (один для сайту, інший для проксі), ви можете використовувати один потужний сервер. Це скорочує витрати на оренду та спрощує керування інфраструктурою. По-друге, це підвищує маскування MTProto. Якщо на тій самій IP-адресі, що й проксі, працює повноцінний веб-сайт, трафік до якого йде через той самий 443 порт, це створює видимість звичайного, легітимного сервера. У разі перевірки або аналізу трафіку, наявність реального сайту-прикриття робить проксі менш помітним та підозрілим. Це особливо ефективно, коли сайт використовує SSL-сертифікат від відомого центру сертифікації, такого як Let's Encrypt, що надає трафіку ще більшої правдоподібності.

Принцип роботи SNI-маршрутизації: як один 443 порт обслуговує два сервіси

Суть проблеми полягає в тому, що порт 443 може бути зайнятий лише одним процесом в операційній системі. Якщо ви хочете, щоб і веб-сервер (Nginx, Apache), і MTProto proxy слухали цей порт, виникає конфлікт. Рішення криється в технології Server Name Indication (SNI) та використанні фронтенд-проксі, який може аналізувати початковий етап TLS-рукостискання, не розшифровуючи весь трафік.

Що таке SNI та як він допомагає в маршрутизації

SNI (Server Name Indication) — це розширення протоколу TLS, яке дозволяє клієнту (браузеру, Telegram-клієнту) вказувати ім'я хоста (доменне ім'я) сервера, до якого він намагається підключитися, ще до початку повноцінного TLS-рукостискання. Ця інформація передається в незашифрованому вигляді в заголовку ClientHello. Фронтенд-сервер, що слухає порт 443, може перехопити цей заголовок, проаналізувати SNI-ім'я та на його основі прийняти рішення, куди перенаправити подальший зашифрований трафік: на бекенд веб-сервера (наприклад, Nginx, Apache) або на бекенд MTProto proxy.

Таким чином, для клієнта все виглядає так, ніби він підключається до звичайного HTTPS-сервера за доменним ім'ям (для сайту) або до MTProto proxy за IP-адресою/доменним ім'ям (для проксі). Фронтенд-сервер діє як інтелектуальний диспетчер, направляючи трафік у потрібний сервіс, що працює на іншому, зазвичай локальному, порту. Це ключовий момент для реалізації схеми "MTProto на 443 порту" спільно з веб-сайтом.

Схема взаємодії: фронтенд, бекенди та сертифікати

Типова схема виглядає наступним чином:

Клієнт (браузер або Telegram-клієнт) ініціює TLS-підключення до вашого VPS на порт 443.
Фронтенд-проксі (Nginx Stream або SNIProxy) перехоплює це підключення.
Фронтенд-проксі аналізує заголовок ClientHello, витягуючи SNI-ім'я.
- Якщо SNI-ім'я відповідає домену вашого сайту (наприклад, mysite.com), фронтенд перенаправляє трафік на локальний порт, де слухає ваш веб-сервер (Nginx/Apache), наприклад, на 127.0.0.1:8443.
- Якщо SNI-ім'я відсутнє (що характерно для MTProto, якщо клієнт підключається за IP) або відповідає спеціальному домену, який ви можете призначити для MTProto (наприклад, proxy.mysite.com), фронтенд перенаправляє трафік на локальний порт, де слухає MTProto proxy, наприклад, на 127.0.0.1:4433.
Бекенд-сервер (веб-сервер або MTProto proxy) приймає трафік, обробляє його та відповідає клієнту.

Важливо, що веб-сервер на 127.0.0.1:8443 повинен мати свій SSL-сертифікат для mysite.com, а MTProto proxy на 127.0.0.1:4433 не вимагає свого SSL-сертифіката, оскільки TLS-хендшейк обробляється на стороні фронтенду, а MTProto використовує свій власний протокол шифрування. Однак для більшої правдоподібності та стійкості до блокувань, MTProto може бути налаштований з фіктивним TLS-шаром, що використовує сертифікат від реального сайту. Це робить трафік MTProto невідмінним від звичайного HTTPS на рівні TLS-хендшейка.

Шукаєте надійний сервер для ваших проєктів?

VPS від $10/міс та виділені сервери від $9/міс з NVMe, DDoS-захистом та підтримкою 24/7.

Переглянути пропозиції →

Вибір фронтенду для SNI-маршрутизації: Nginx Stream проти SNIProxy

Для реалізації SNI-маршрутизації на 443 порту у вас є два основні варіанти: Nginx Stream з модулем ssl_preread або спеціалізований SNIProxy. Обидва рішення ефективні, але мають свої особливості та області застосування.

Nginx Stream з модулем ssl_preread: гнучкість та продуктивність

Nginx, відомий своєю продуктивністю та гнучкістю як веб-сервер та зворотний проксі, також може виступати в ролі TCP/UDP проксі через свій модуль Stream. З додаванням модуля ssl_preread, Nginx Stream стає потужним інструментом для SNI-маршрутизації. Цей модуль дозволяє Nginx аналізувати SNI-ім'я з TLS ClientHello без розшифровки всього TLS-трафіку. Це означає, що Nginx працює на рівні TCP, просто перенаправляючи зашифровані байти на потрібний бекенд на основі SNI.

Переваги Nginx Stream:

Універсальність: Якщо Nginx вже використовується на вашому VPS для веб-сервера, його Stream-модуль дозволяє централізувати керування проксіюванням.
Продуктивність: Nginx славиться своєю здатністю обробляти велику кількість одночасних з'єднань з мінімальними накладними витратами.
Гнучкість: Широкі можливості конфігурації, включаючи балансування навантаження, таймаути, ліміти з'єднань та інші просунуті налаштування.
SSL/TLS offloading: Хоча для SNI-маршрутизації сам Nginx не розшифровує трафік, він може бути налаштований на SSL offloading для веб-трафіку, якщо це необхідно.

Недоліки:

Вимагає компіляції Nginx з модулем --with-stream_ssl_preread_module, якщо він не включений за замовчуванням у вашій збірці (часто включений у сучасних дистрибутивах).
Конфігурація може бути складнішою для новачків порівняно з простими проксі.

SNIProxy: легковагове рішення для специфічних завдань

SNIProxy — це спеціалізований проксі-сервер, який розроблений саме для SNI-маршрутизації. Він набагато легший за Nginx і не має такого широкого функціоналу, але відмінно справляється зі своїм основним завданням: аналіз SNI та перенаправлення трафіку. Це ідеальне рішення, якщо вам потрібен лише SNI-маршрутизація і ви не хочете використовувати Nginx для інших цілей або віддаєте перевагу мінімалістичним рішенням.

Переваги SNIProxy:

Легковаговість: Споживає значно менше системних ресурсів порівняно з Nginx.
Простота: Конфігурація SNIProxy зазвичай простіша та прямолінійніша.
Спеціалізація: Оптимізований для свого завдання, що може бути перевагою в деяких сценаріях.

Недоліки:

Менше додаткових функцій порівняно з Nginx (немає балансування, просунутих логів тощо).
Менш поширений, що може ускладнити пошук готових рішень або підтримку спільноти.

Для більшості користувачів, особливо тих, хто вже використовує Nginx для веб-сервера, Nginx Stream є кращим вибором через його універсальність та продуктивність. Однак, якщо ви шукаєте максимально легковагове та просте рішення виключно для SNI-маршрутизації, SNIProxy також буде чудовим варіантом.

Швидкий вибір

Шукаєте сервер, який просто працює?

Valebyte VPS — NVMe, підтримка 24/7, запуск за 60 секунд.

Тарифи VPS

Покрокове налаштування Nginx Stream для MTProto та веб-сайту

Розглянемо детальне покрокове налаштування Nginx Stream для спільної роботи MTProto proxy та веб-сайту на одному VPS, використовуючи порт 443. Ця конфігурація дозволить вашому VPS ефективно обслуговувати обидва сервіси, підвищуючи їх стійкість до блокувань та економію ресурсів.

Підготовка VPS: встановлення Nginx та Let's Encrypt

Перш за все, переконайтеся, що ваш VPS від Valebyte.com готовий до роботи. Вам знадобиться чиста установка Ubuntu Server (наприклад, 22.04 LTS) або Debian. Для початку оновимо систему та встановимо необхідні пакети:

sudo apt update && sudo apt upgrade -y
sudo apt install -y nginx certbot python3-certbot-nginx

Переконайтеся, що Nginx встановлений з модулем stream_ssl_preread. У більшості сучасних дистрибутивів він включений за замовчуванням. Перевірити можна так:

nginx -V 2>&1 | grep --color stream_ssl_preread_module

Якщо вивід містить --with-stream_ssl_preread_module, то все гаразд. Якщо ні, вам доведеться скомпілювати Nginx з вихідних кодів або знайти пакет з цим модулем.

Для нашого веб-сайту нам знадобиться доменне ім'я (наприклад, mywebsite.com). Переконайтеся, що A-запис вашого домену вказує на IP-адресу вашого VPS.

Конфігурація Nginx Stream для SNI-маршрутизації

Тепер приступимо до налаштування Nginx. Відкрийте файл /etc/nginx/nginx.conf та додайте секцію stream поза секцією http. Якщо секція stream вже існує, використовуйте її.

# Добавьте это в начало файла, после директивы 'user nginx;' или 'user www-data;'

stream {
    map $ssl_preread_server_name $name {
        hostnames;

        # Домен вашего веб-сайта
        mywebsite.com           web;
        www.mywebsite.com       web;

        # Домен для MTProto (опционально, если не используете IP)
        proxy.mywebsite.com     mtproto;

        # Если SNI не предоставлен или не соответствует ни одному из доменов,
        # по умолчанию направляем на MTProto. Это важно, так как Telegram
        # часто не отправляет SNI при подключении по IP.
        default                 mtproto;
    }

    upstream web_backend {
        server 127.0.0.1:8443; # Локальный порт для HTTPS трафика сайта
    }

    upstream mtproto_backend {
        server 127.0.0.1:4433; # Локальный порт для MTProto proxy
    }

    server {
        listen 443 reuseport;
        listen [::]:443 reuseport; # Для IPv6

        ssl_preread on;
        proxy_pass $name_backend;
        proxy_timeout 30s;
        proxy_connect_timeout 5s;
    }
}

# ... остальная часть nginx.conf (секция http и т.д.)

Пояснення до конфігурації:

map $ssl_preread_server_name $name: Ця директива створює змінну $name, значення якої залежить від SNI-імені, отриманого з TLS-хендшейка.
hostnames;: Включає підтримку зіставлення за доменними іменами.
mywebsite.com web;: Якщо SNI-ім'я mywebsite.com, змінна $name приймає значення web.
default mtproto;: Якщо SNI-ім'я не знайдено або не відповідає жодному з перерахованих, трафік піде на mtproto. Це критично для MTProto, оскільки багато клієнтів підключаються за IP і не передають SNI, або ж MTProto за своєю природою може його не використовувати.
upstream web_backend: Визначає групу серверів для веб-трафіку. У нашому випадку це локальний порт 8443.
upstream mtproto_backend: Визначає групу серверів для MTProto. Це локальний порт 4433.
listen 443 reuseport;: Nginx слухає порт 443. Директива reuseport дозволяє кільком процесам слухати один і той самий порт, що може бути корисно для продуктивності, але в даному випадку ключовим є сам порт.
ssl_preread on;: Включає модуль ssl_preread, який дозволяє Nginx аналізувати SNI.
proxy_pass $name_backend;: Найважливіша директива. Вона перенаправляє трафік на відповідний upstream залежно від значення змінної $name.

Налаштування MTProto-сервера (mtg)

Для MTProto ми будемо використовувати mtg (Telegram MTProto Proxy). Встановіть його, якщо ще не зробили:

sudo apt install -y snapd
sudo snap install mtg-proxy

Тепер запустіть mtg на локальному порту 4433. Важливо, щоб MTProto слухав тільки на локальному інтерфейсі (127.0.0.1), оскільки Nginx Stream буде проксіювати до нього трафік. Створіть секрет та запустіть:

SECRET=$(head /dev/urandom | tr -dc A-Za-z0-9 | head -c 32)
sudo mtg-proxy.mtg run -p 127.0.0.1:4433 -s $SECRET --tag your_ad_tag

Замініть your_ad_tag на свій рекламний тег, якщо він у вас є. Запишіть згенерований SECRET, він знадобиться для підключення клієнтів. Щоб mtg запускався автоматично при перезавантаженні, краще створити systemd-сервіс. Створіть файл /etc/systemd/system/mtg-proxy.service:

[Unit]
Description=MTProto Proxy
After=network.target

[Service]
Type=simple
User=root
WorkingDirectory=/root
ExecStart=/snap/bin/mtg-proxy.mtg run -p 127.0.0.1:4433 -s YOUR_SECRET_HERE --tag YOUR_AD_TAG_HERE
Restart=on-failure

[Install]
WantedBy=multi-user.target

Не забудьте замінити YOUR_SECRET_HERE та YOUR_AD_TAG_HERE на ваші значення. Потім:

sudo systemctl daemon-reload
sudo systemctl enable mtg-proxy.service
sudo systemctl start mtg-proxy.service
sudo systemctl status mtg-proxy.service

Переконайтеся, що MTProto запущений і слухає на 127.0.0.1:4433.

Налаштування веб-сервера (Nginx HTTP)

Тепер налаштуємо Nginx як веб-сервер, який буде слухати на локальному порту 8443.

Створіть новий файл конфігурації для вашого сайту, наприклад, /etc/nginx/sites-available/mywebsite.com:

server {
    listen 127.0.0.1:8443 ssl http2;
    listen [::1]:8443 ssl http2; # Для IPv6

    server_name mywebsite.com www.mywebsite.com;

    ssl_certificate /etc/letsencrypt/live/mywebsite.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/mywebsite.com/privkey.pem;
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 10m;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384";
    ssl_prefer_server_ciphers on;

    root /var/www/mywebsite.com;
    index index.html index.htm;

    location / {
        try_files $uri $uri/ =404;
    }

    # Дополнительные настройки логирования, кэширования и т.д.
}

Створіть директорію для вашого сайту та тестовий файл:

sudo mkdir -p /var/www/mywebsite.com
echo "Hello from mywebsite.com!" | sudo tee /var/www/mywebsite.com/index.html

Увімкніть сайт та перевірте конфігурацію Nginx:

sudo ln -s /etc/nginx/sites-available/mywebsite.com /etc/nginx/sites-enabled/
sudo nginx -t

Якщо помилок немає, перезавантажте Nginx:

sudo systemctl restart nginx

Отримання та керування SSL-сертифікатами Let's Encrypt

Для вашого сайту mywebsite.com необхідний діючий SSL-сертифікат. Ми будемо використовувати Certbot з Let's Encrypt. Оскільки Nginx Stream вже зайняв 443 порт, Certbot не зможе використовувати свій стандартний метод --nginx або --standalone на 443 порту. Замість цього ми можемо тимчасово відключити Nginx Stream або використовувати метод --webroot, якщо у вас вже є працюючий веб-сервер на 80 порту (який Certbot може використовувати для валідації). Або, найпростіший спосіб: тимчасово модифікувати Nginx Stream, щоб він проксіював запити Certbot на порт 80.

Спосіб 1: Використання --webroot

Якщо у вас на 80 порту вже працює Nginx HTTP (що зазвичай для Certbot) для перенаправлення HTTP на HTTPS, ви можете використовувати --webroot. Для цього переконайтеся, що ваш Nginx HTTP слухає 80 порт і має директиву location /.well-known/acme-challenge/. Якщо ні, тимчасово додайте це в Nginx HTTP на 80 порту:

server {
    listen 80;
    listen [::]:80;
    server_name mywebsite.com www.mywebsite.com;

    location /.well-known/acme-challenge/ {
        root /var/www/mywebsite.com; # Или любой другой доступный путь
    }

    location / {
        return 301 https://$host$request_uri;
    }
}

Перезавантажте Nginx, потім:

sudo certbot certonly --webroot -w /var/www/mywebsite.com -d mywebsite.com -d www.mywebsite.com

Після отримання сертифікатів, Certbot автоматично налаштує їх для вашого Nginx HTTP. Якщо ви використовуєте конфігурацію Nginx Stream, як описано вище, то Certbot не зможе автоматично оновити сертифікати для веб-сервера, оскільки він слухає на 8443 порту. Вам потрібно буде вручну вказати шляхи до сертифікатів у конфігурації mywebsite.com, як показано вище.

Спосіб 2: Тимчасово відключити Nginx Stream та використовувати --nginx (менш зручно)

Закоментуйте або видаліть секцію stream з nginx.conf.
Перезавантажте Nginx: sudo systemctl restart nginx.

Отримайте сертифікат для mywebsite.com, налаштувавши Nginx для HTTP на 80 порту (тимчасова конфігурація):

server {
            listen 80;
            server_name mywebsite.com www.mywebsite.com;
            location / {
                return 301 https://$host$request_uri;
            }
        }

Перезавантажте Nginx.

Запустіть Certbot: sudo certbot --nginx -d mywebsite.com -d www.mywebsite.com.
Після успішного отримання сертифікатів, відновіть конфігурацію Nginx Stream в nginx.conf та конфігурацію веб-сервера на 8443 порту.
Перезавантажте Nginx.

Автоматичне оновлення сертифікатів:

Certbot автоматично створює завдання cron для оновлення сертифікатів. Переконайтеся, що воно працює:

sudo systemctl status certbot.timer

Якщо сертифікати оновлюються, Nginx повинен їх підхопити. Якщо ви використовуєте Nginx HTTP на 8443 порту, після оновлення сертифікатів Certbot'ом, вам потрібно буде перезавантажити Nginx, щоб він завантажив нові сертифікати:

sudo systemctl reload nginx

Додайте цю команду до скрипта оновлення Certbot, якщо він не робить це автоматично.

Налаштування SNIProxy для MTProto та веб-сайту (альтернативний варіант)

Якщо ви віддаєте перевагу SNIProxy замість Nginx Stream, ось як його налаштувати. SNIProxy є більш легковаговим та спеціалізованим рішенням.

Встановлення та базова конфігурація SNIProxy

Встановіть SNIProxy з репозиторіїв:

sudo apt update
sudo apt install -y sniproxy

Основний файл конфігурації SNIProxy знаходиться за адресою /etc/sniproxy.conf. Відкрийте його та налаштуйте наступним чином:

# /etc/sniproxy.conf

user sniproxy
pidfile /var/run/sniproxy.pid

# Логирование (опционально)
accesslog {
    filename /var/log/sniproxy/access.log
    # format "%t %h %p %s %T" # Пример формата
}
errorlog {
    filename /var/log/sniproxy/error.log
    # level error # Уровень логирования
}

# Слушаем входящие соединения на порту 443
listener 443 {
    proto tls
    table {
        # Маршрутизация для вашего веб-сайта
        mywebsite.com 127.0.0.1:8443
        www.mywebsite.com 127.0.0.1:8443

        # Маршрутизация для MTProto (если используется домен)
        proxy.mywebsite.com 127.0.0.1:4433

        # Правило по умолчанию для MTProto, если SNI отсутствует или не соответствует
        .* 127.0.0.1:4433
    }
}

Пояснення до конфігурації:

user sniproxy: Від імені якого користувача буде працювати SNIProxy.
listener 443 { proto tls ... }: SNIProxy буде слухати TCP-порт 443, очікуючи TLS-трафік.
table { ... }: Визначає правила маршрутизації на основі SNI.
mywebsite.com 127.0.0.1:8443: Якщо SNI-ім'я mywebsite.com, трафік перенаправляється на локальний порт 8443 (де слухає ваш Nginx HTTP).
.* 127.0.0.1:4433: Це правило за замовчуванням. Якщо SNI-ім'я не відповідає жодному з перерахованих (або відсутнє), трафік перенаправляється на локальний порт 4433 (де слухає MTProto).

Після налаштування файлу конфігурації, перезапустіть SNIProxy:

sudo systemctl restart sniproxy
sudo systemctl enable sniproxy
sudo systemctl status sniproxy

Переконайтеся, що SNIProxy запущений і працює без помилок. Після цього, ваші Nginx HTTP (на 127.0.0.1:8443) та MTProto (на 127.0.0.1:4433) будуть отримувати трафік через SNIProxy на порту 443.

Додаткові параметри та нюанси

SNIProxy, на відміну від Nginx Stream, не надає стільки тонких налаштувань, але для базової SNI-маршрутизації цього зазвичай достатньо. Переконайтеся, що ваші бекенди (Nginx HTTP та MTProto) налаштовані на прослуховування тільки локальних інтерфейсів (127.0.0.1 або [::1]) на своїх виділених портах (8443 та 4433 відповідно), щоб уникнути конфліктів та підвищити безпеку.

Також, при використанні SNIProxy, Certbot буде працювати без проблем, оскільки SNIProxy не втручається в процес отримання сертифікатів (Certbot зазвичай використовує 80 порт для валідації, а SNIProxy слухає 443).

Діагностика та усунення типових проблем

Налаштування SNI-маршрутизації може бути непростим, і помилки трапляються. Важливо вміти діагностувати проблеми, щоб швидко їх усунути.

Перевірка роботи SNI-маршрутизації

Щоб переконатися, що SNI-маршрутизація працює коректно, виконайте наступні перевірки:

Перевірка доступності веб-сайту: Відкрийте ваш домен https://mywebsite.com у браузері. Якщо сайт завантажується та відображає HTTPS-замок, значить, трафік успішно маршрутизується на ваш веб-сервер. Ви також можете використовувати curl:
```
curl -v https://mywebsite.com
        
```
Шукайте у виводі інформацію про TLS-хендшейк та вміст сторінки.
Перевірка доступності MTProto: Спробуйте підключитися до вашого MTProto proxy за допомогою Telegram-клієнта. Якщо підключення встановлюється і ви можете відправляти/отримувати повідомлення, значить, MTProto працює.
Для більш технічної перевірки можна використовувати openssl s_client. Якщо ви налаштували MTProto з фіктивним TLS-шаром, що імітує ваш сайт, ви можете спробувати підключитися до нього із зазначенням SNI вашого сайту:
```
openssl s_client -connect ВАШ_IP:443 -servername mywebsite.com
        
```
Якщо SNI-маршрутизація працює, ви повинні отримати відповідь від вашого веб-сервера. Якщо ви не вказуєте -servername або вказуєте щось інше, ви повинні отримати "сміття" або таймаут, що означатиме, що трафік пішов у MTProto. MTProto не говорить на TLS, тому openssl не зможе встановити з ним з'єднання.
Перевірка прослуховуваних портів: Переконайтеся, що Nginx (або SNIProxy) слухає порт 443, а ваш веб-сервер і MTProto слухають тільки локальні порти (наприклад, 8443 та 4433) на 127.0.0.1.
```
sudo ss -tulpn | grep 443
        sudo ss -tulpn | grep 8443
        sudo ss -tulpn | grep 4433
        
```
Вивід повинен показати, що Nginx (або sniproxy) слухає на *:443, а nginx (для сайту) і mtg-proxy слухають на 127.0.0.1:8443 та 127.0.0.1:4433 відповідно.
Перевірка логів: Вивчіть логи Nginx (/var/log/nginx/access.log, error.log) та MTProto (якщо ви налаштували логування або використовуєте systemctl status mtg-proxy.service). Помилки в логах можуть вказати на джерело проблеми.

Поширені помилки конфігурації та їх вирішення

Nginx Stream не запускається або видає помилки:
- Проблема: nginx -t видає синтаксичні помилки, або Nginx не запускається.
- Рішення: Уважно перевірте синтаксис nginx.conf, особливо секцію stream. Переконайтеся, що всі дужки закриті, директиви написані правильно і немає одруківок. Перевірте, що Nginx скомпільований з модулем stream_ssl_preread.
Веб-сайт недоступний по HTTPS:
- Проблема: Браузер видає помилку "ERR_CONNECTION_REFUSED" або "ERR_SSL_PROTOCOL_ERROR".
- Рішення:
  - Переконайтеся, що Nginx HTTP слухає на правильному локальному порту (наприклад, 127.0.0.1:8443) та має коректні SSL-сертифікати.
  - Перевірте, що Nginx Stream правильно маршрутизує трафік для вашого домену на web_backend (mywebsite.com web; в map).
  - Переконайтеся, що Certbot успішно отримав та оновив сертифікати для mywebsite.com, і Nginx HTTP використовує актуальні шляхи до них.
MTProto не підключається:
- Проблема: Telegram-клієнт не може підключитися до проксі.
- Рішення:
  - Перевірте, що mtg-proxy запущений і слухає на 127.0.0.1:4433.
  - Переконайтеся, що секрет проксі в Telegram-клієнті відповідає секрету, з яким запущений mtg-proxy.
  - Перевірте, що Nginx Stream правильно маршрутизує трафік за замовчуванням (або за SNI-ім'ям для проксі) на mtproto_backend (default mtproto;).
  - Переконайтеся, що немає фаєрволів (наприклад, UFW), що блокують вхідні з'єднання на 443 порт або вихідні на локальні порти.
Помилки "bind: Address already in use":
- Проблема: При запуску Nginx або SNIProxy, ви бачите помилку, що порт 443 вже зайнятий.
- Рішення: Тільки один процес може слухати на зовнішньому інтерфейсі на порту 443. Переконайтеся, що у вас працює тільки Nginx Stream АБО SNIProxy. Якщо ви перемикаєтеся між ними, зупиніть попередній сервіс перед запуском нового. Також переконайтеся, що ваш веб-сервер (Nginx HTTP) слухає тільки на локальному інтерфейсі (127.0.0.1:8443), а не на 0.0.0.0:443.

Швидкий вибір

Шукаєте сервер, який просто працює?

Valebyte VPS — NVMe, підтримка 24/7, запуск за 60 секунд.

Тарифи VPS

Оптимізація та безпека: як вибрати VPS для проксі та веб-сайту

Вибір правильного VPS для одночасного хостингу MTProto proxy та веб-сайту критично важливий для продуктивності та надійності. Valebyte.com пропонує різні тарифи, які можуть підійти для цього завдання.

Вимоги до ресурсів для комбінованого навантаження

Навантаження на VPS залежатиме від кількості одночасних користувачів MTProto proxy та трафіку вашого веб-сайту. Нижче наведено орієнтовну таблицю вимог до ресурсів:

Для 50 одночасних підключень MTProto та помірного веб-трафіку достатньо 4 vCPU, 8 GB RAM та NVMe-диска на 80 GB.

Одночасних користувачів MTProto	vCPU	RAM (ГБ)	Диск (ГБ, тип)	Мережевий порт	Орієнтовна ціна Valebyte.com ($/міс, 2024)
До 10	1-2	2-4	40-60 NVMe/SSD	1 Gbps	Від 5.99$
10-50	2-4	4-8	60-80 NVMe/SSD	1 Gbps	Від 9.99$
50-150	4-6	8-16	80-160 NVMe	1-10 Gbps	Від 19.99$
150-300+	6-8+	16-32+	160-320+ NVMe	10 Gbps	Від 39.99$

Важливі зауваження:

CPU: MTProto proxy та Nginx (особливо з SSL) можуть бути CPU-інтенсивними. Вибирайте VPS з достатньою кількістю ядер.
RAM: Nginx, веб-сервери (PHP-FPM, Python-додатки) та сам MTProto споживають RAM. 4 GB — хороший старт, але для більшого навантаження знадобиться більше.
Диск: NVMe-диски значно швидші за SSD, що критично для швидкості завантаження сайту та загальної чутливості системи. Для MTProto сам по собі диск не такий важливий, але для веб-сервера — дуже.
Мережа: Високошвидкісний мережевий порт (1 Gbps або 10 Gbps) з необмеженим трафіком або великим лімітом необхідний для проксі, оскільки користувачі будуть активно його використовувати.

Підвищення безпеки вашої конфігурації

Безпека об'єднаного VPS-сервера вимагає особливої уваги:

Фаєрвол (UFW/iptables): Налаштуйте UFW або iptables для дозволу тільки необхідних портів. Дозвольте вхідні з'єднання тільки на 443 (для Nginx/SNIProxy) та 22 (для SSH, але краще з обмеженням за IP).
```
sudo ufw default deny incoming
        sudo ufw default allow outgoing
        sudo ufw allow 22/tcp # Только для вашего IP, если возможно
        sudo ufw allow 443/tcp
        sudo ufw enable
        
```
Використання локальних портів: Переконайтеся, що MTProto та веб-сервер слухають тільки на 127.0.0.1. Це запобігає прямому доступу до них ззовні, зобов'язуючи весь трафік проходити через фронтенд-проксі.
Оновлення ПЗ: Регулярно оновлюйте операційну систему та все встановлене ПЗ (Nginx, Certbot, mtg-proxy), щоб отримувати останні виправлення безпеки.
Надійні паролі та SSH-ключі: Використовуйте складні паролі та, за можливості, тільки SSH-ключі для доступу до сервера. Відключіть вхід за паролем для root.
Fail2ban: Встановіть та налаштуйте Fail2ban для захисту SSH від брутфорс-атак.
SSL/TLS: Підтримуйте актуальні SSL-сертифікати для вашого сайту та використовуйте сучасні протоколи TLS (TLSv1.2, TLSv1.3) з сильними шифрами.

Часто задавані питання

Тут ви знайдете відповіді на найпоширеніші питання, що стосуються спільної роботи MTProto та веб-сайту на одному VPS через 443 порт.

Чи можна використовувати Nginx Stream для інших протоколів, крім MTProto?

Так, Nginx Stream дуже гнучкий. Він може маршрутизувати будь-який TCP/UDP трафік на основі різних критеріїв, включаючи SNI для TLS, або просто за IP-адресою/портом. Наприклад, ви можете налаштувати його для маршрутизації трафіку до інших VPN-сервісів (наприклад, OpenVPN, WireGuard), ігрових серверів або баз даних, якщо вони використовують TLS і передають SNI. Головне, щоб Nginx Stream міг визначити, куди перенаправляти трафік, без його повного розшифрування.

Як оновити SSL-сертифікати Let's Encrypt, якщо 443 порт зайнятий Nginx Stream?

Якщо 443 порт постійно зайнятий Nginx Stream, Certbot не зможе використовувати метод --nginx або --standalone для валідації. Найкращий спосіб – використовувати метод --webroot. Для цього переконайтеся, що ваш веб-сервер Nginx (який слухає на 80 порту для перенаправлення HTTP на HTTPS) має доступ до директорії, яку Certbot використовує для тимчасових файлів (наприклад, /var/www/mywebsite.com для .well-known/acme-challenge/). Запустіть Certbot з командою: sudo certbot certonly --webroot -w /var/www/mywebsite.com -d mywebsite.com -d www.mywebsite.com. Після оновлення Certbot автоматично перезавантажить Nginx, щоб застосувати нові сертифікати.

Чи вплине робота MTProto на продуктивність мого веб-сайту?

Так, будь-яке додаткове навантаження на VPS впливатиме на продуктивність. MTProto proxy, особливо за великої кількості активних користувачів (понад 50-100), може споживати значні ресурси CPU та мережевого каналу. Ваш веб-сайт також споживатиме CPU та RAM. Важливо правильно вибрати тариф VPS з достатньою кількістю vCPU (від 4 ядер), RAM (від 8 GB) та високошвидкісним NVMe-диском. Регулярно моніторте використання ресурсів (CPU, RAM, мережа) за допомогою таких інструментів, як htop, iftop або Grafana/Prometheus, щоб вчасно масштабувати VPS за потреби.

Чи потрібен SSL-сертифікат для MTProto proxy?

Сам MTProto proxy не вимагає SSL-сертифіката в традиційному розумінні TLS, оскільки використовує власний протокол шифрування. Проте для підвищення маскування та обходу блокувань деякі реалізації MTProto (наприклад, mtg) підтримують так званий "fake TLS" або "TLS-wrap", який дозволяє MTProto імітувати TLS-хендшейк реального сайту, використовуючи його сертифікат. Це робить трафік MTProto ще більш невідмінним від звичайного HTTPS на рівні початкового рукостискання. У нашій схемі Nginx Stream обробляє перший TLS-хендшейк і маршрутизує трафік, тому MTProto-бекенд може працювати без власного SSL-сертифіката.

Які переваги Valebyte.com для розміщення такої конфігурації?

Valebyte.com пропонує потужні VPS зі швидкими NVMe-дисками та високошвидкісними мережевими каналами (до 10 Gbps), що ідеально підходить для ресурсоємних застосунків, таких як MTProto proxy та веб-сервер. Наші тарифи починаються від 5.99$ на місяць за конфігурацію, достатню для невеликого проєкту, і легко масштабуються до більш потужних рішень з 8+ vCPU та 32+ GB RAM для великих навантажень. Ми надаємо надійну інфраструктуру, яка дозволяє ефективно керувати трафіком та забезпечувати стабільну роботу ваших сервісів 24/7.

Висновки

Використання SNI-маршрутизації на 443 порту для спільного розміщення MTProto proxy та веб-сайту на одному VPS – це ефективне та економічне рішення для обходу блокувань та оптимізації інфраструктури. Nginx Stream з модулем ssl_preread або SNIProxy дозволяють елегантно розділити трафік, направляючи його на відповідні локальні бекенди. Ця конфігурація не тільки знижує витрати, але й підвищує маскування MTProto, роблячи його трафік невідмінним від звичайного HTTPS.

SSD NVMe

Готові запустити свій VPS?

NVMe VPS з активацією за 60 секунд: повний root-доступ, 20+ локацій, оплата карткою або криптою.

Вибрати тариф