MTProxy auf Port 443 mit Nginx: Versteckte Einrichtung für Telegram

Unauffällige MTProxy-Einrichtung auf Nginx Port 443 für Telegram

Dieser Artikel befasst sich mit einer kritischen Herausforderung für Systemadministratoren und Entwickler: die Bereitstellung von Telegram MTProxy auf dem Standard-HTTPS-Port 443, ohne bestehende Nginx-verwaltete Webdienste zu stören. Diese Konfiguration erhöht die Widerstandsfähigkeit des Proxys gegen Erkennung und Blockierung erheblich, indem sein Datenverkehr als regulärer Webverkehr getarnt wird. Die Hauptkomplexität liegt in der Fähigkeit von Nginx, Anfragen korrekt zu routen und dabei zwischen Ziel-HTTP/HTTPS-Sites und MTProxy zu unterscheiden, während derselbe Port genutzt wird. Dieser Leitfaden beschreibt den Betriebsmechanismus des Nginx stream-Moduls und dessen Integration mit mtprotoproxy, um eine robuste und diskrete Lösung zu schaffen.

Wie Nginx Stream für Multiplexing funktioniert

Damit MTProxy und Nginx erfolgreich auf Port 443 koexistieren können, ist ein intelligenter Routing-Mechanismus unerlässlich. Das Nginx stream-Modul, das auf der TCP/UDP-Schicht arbeitet, ermöglicht die Analyse initialer Verbindungsdaten, bevor die vollständige Verarbeitung auf der Anwendungsschicht erfolgt. Ein entscheidender Aspekt ist, dass das Server Name Indication (SNI)-Feld in einer TLS ClientHello-Nachricht im Klartext übertragen wird, selbst bei verschlüsselten Verbindungen. Dies ermöglicht es Nginx, den angeforderten Hostnamen zu lesen, ohne den gesamten SSL-Stream entschlüsseln zu müssen.

Die vorgeschlagene Lösung verwendet die folgende Logik:

Port-Neuzuordnung für HTTPS-Hosts: Alle bestehenden Nginx HTTPS Virtual Hosts, die zuvor auf Port 443 lauschten, werden auf einen internen Port, z.B. 4443, verschoben. Dies gibt Port 443 für einen zentralen Handler frei.
Nginx Stream als zentraler Router: Ein Nginx stream-Server wird auf dem nun verfügbaren Port 443 konfiguriert. Dieser Server verwendet die Direktive ssl_preread on, um das SNI aus eingehenden SSL-Verbindungen zu extrahieren.
Dynamisches Routing: Basierend auf dem extrahierten SNI trifft Nginx stream eine Entscheidung:

* Wenn das SNI mit dem gewählten Domainnamen für MTProxy übereinstimmt (z.B. myprovider.ru), wird die Verbindung an MTProxy weitergeleitet (das auf einem lokalen Port, z.B. 7788, lauschen wird).

* Wenn das SNI mit einem anderen Domainnamen übereinstimmt, wird die Verbindung zurück an Nginx umgeleitet, jedoch an den internen Port 4443, wo sie von den Standard-HTTPS-Virtual-Hosts verarbeitet wird.

Beibehaltung der echten IP: Für eine genaue Protokollierung, Verkehrsanalyse und das ordnungsgemäße Funktionieren von Anwendungen hinter Nginx wird proxy_protocol verwendet. Dies ermöglicht die Weitergabe der echten Client-IP-Adresse entlang der Proxy-Kette.

Dieser Ansatz ermöglicht es MTProxy, sich als regulärer HTTPS-Verkehr zu tarnen, indem derselbe Port wie der Webserver verwendet wird. Dies erhöht seine Widerstandsfähigkeit gegen Erkennung und Blockierung erheblich und macht seinen Datenverkehr von Standard-Webverbindungen nicht unterscheidbar.

Nginx für Koexistenz konfigurieren

Der erste Schritt besteht darin, die Konfiguration aller bestehenden Nginx HTTPS Virtual Hosts zu ändern. Sie müssen den Port, auf dem sie lauschen, von 443 auf einen internen Port ändern, zum Beispiel 127.0.0.1:4443. Dies stellt sicher, dass Nginx diese Anfragen verarbeitet, nachdem das stream-Modul sie umgeleitet hat.

Beispiel für die Modifikation eines server-Blocks:

server {
  server_name mywebsite.ru;
  listen 127.0.0.1:4443 ssl http2 proxy_protocol;
  set_real_ip_from 127.0.0.1;    # Trust localhost as the PROXY Protocol source
  real_ip_header proxy_protocol; # Extract IP from PROXY Protocol header
  real_ip_recursive on;          # Apply recursively for correct IP determination
  # ... other directives for your server block ...
  ssl_certificate /etc/letsencrypt/live/mywebsite.ru/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/mywebsite.ru/privkey.pem;
  # ... other SSL/TLS settings ...
}

Die proxy_protocol-Direktive in listen weist Nginx an, einen PROXY Protocol-Header zu erwarten. set_real_ip_from und real_ip_header sind entscheidend, damit Nginx die echte IP-Adresse des Clients korrekt identifiziert und weitergibt, anstatt der IP des lokalen Hosts (127.0.0.1), die vom Nginx Stream verwendet wird. Ohne diese Einstellungen würden alle Anfragen an Ihre Websites von 127.0.0.1 zu stammen scheinen, was die Anwendungsfunktionalität, Protokollierung und Sicherheitssysteme potenziell stören könnte.

Der nächste Schritt ist die Erstellung einer neuen Konfigurationsdatei für das Nginx stream-Modul. Es wird empfohlen, diese in /etc/nginx/conf.d/stream.conf oder einem anderen geeigneten Speicherort abzulegen, der sicherstellt, dass Nginx sie lädt.

stream {
    log_format stream '$remote_addr [$time_local] host=$ssl_preread_server_name '
                      'prot=$protocol status=$status out=$bytes_sent in=$bytes_received';

    # Optional: enable logging for debugging
    #access_log /var/log/nginx/stream_access.log stream;
    #error_log /var/log/nginx/stream_error.log;

    map $ssl_preread_server_name $backend_name {
        myprovider.ru      tg_proxy;    # Traffic for the selected MTProxy domain
        default            nginx_https; # All other HTTPS traffic
    }

    upstream nginx_https {
        server 127.0.0.1:4443; # Redirect to Nginx's internal port
    }

    upstream tg_proxy {
        server 127.0.0.1:7788; # Redirect to MTProxy's local port
    }

    server {
        listen 443 reuseport; # Listen on the main 443 port
        proxy_pass $backend_name;
        ssl_preread on;       # Enable SNI reading to determine hostname
        proxy_protocol on;    # Enable PROXY Protocol to pass the real IP
    }
}

In diesem Block wird map verwendet, um das SNI ($ssl_preread_server_name) einem Backend-Namen zuzuordnen. $backend_name wird je nach angeforderter Domain entweder tg_proxy oder nginx_https sein. Die upstream-Direktive definiert, wohin der Datenverkehr für jedes Backend weitergeleitet wird. listen 443 reuseport ermöglicht es mehreren Nginx-Prozessen, auf demselben Port zu lauschen, was die Leistung und Fehlertoleranz verbessert. ssl_preread on ist eine entscheidende Direktive, die Nginx ermöglicht, das SNI zu erhalten, ohne den gesamten SSL-Verkehr zu entschlüsseln.

Wenn Ihre aktuelle Nginx-Installation das stream-Modul nicht unterstützt (z.B. eine Minimalinstallation), müssen Sie es installieren. Unter Debian/Ubuntu geschieht dies mit dem Befehl:

sudo apt install nginx-full

Nachdem Sie alle Änderungen vorgenommen haben, müssen Sie die Nginx-Konfiguration überprüfen und neu starten:

nginx -t && sudo systemctl restart nginx

Die Verwendung von systemctl restart anstelle von service nginx restart ist der modernere und bevorzugte Ansatz auf systemd-basierten Systemen.

MTProxy-Installation und -Konfiguration

Für die Implementierung von MTProxy in diesem Setup verwenden wir die hocheffiziente Python-Implementierung mtprotoproxy von alexbers, die sich gut mit Nginx proxy_protocol integriert und den erforderlichen TLS-Masquerading-Modus unterstützt.

Der Installationsprozess umfasst das Klonen des Repositories und das Wechseln zum entsprechenden Branch:

(cd /opt || sudo mkdir /opt && sudo chown $(whoami):$(whoami) /opt) && cd /opt
git clone https://github.com/alexbers/mtprotoproxy.git
cd mtprotoproxy
# Important: At the time of writing, stable operation with this configuration is achieved on the master branch
git checkout master

Als Nächstes generieren Sie ein Secret für MTProxy. Dieses Secret wird von Telegram-Clients zur Authentifizierung verwendet und muss einzigartig sein:

head -c 16 /dev/urandom | xxd -ps

Der resultierende 32-stellige Hexadezimalwert sollte gespeichert werden. Nun müssen Sie die Datei config.py im Verzeichnis mtprotoproxy erstellen oder bearbeiten:

# /opt/mtprotoproxy/config.py
PORT = 7788 # Local port to which Nginx Stream will redirect traffic
LISTEN_ADDR_IPV4 = "127.0.0.1" # Bind to localhost for security
LISTEN_ADDR_IPV6 = None # Disable IPv6 if not needed or configured

# Dictionary of users and their secrets. Multiple can be created for different groups.
USERS = {
    "tg_user_1":  "YOUR_GENERATED_SECRET_HERE",
    # "tg_user_2": "0123456789abcdef0123456789abcdef", # Example of an additional secret
}

# MTProxy operating modes
MODES = {
    "classic": False, # Classic mode, easily detectable
    "secure": False,  # Improved mode, but not optimal for masquerading
    "tls": True       # TLS masquerading mode, most resistant to detection
}

# Domain for TLS mode. MTProxy will check its availability on startup.
# Use the domain you selected in the Nginx Stream configuration.
TLS_DOMAIN = "myprovider.ru" # Domain that will be used for MTProxy
PROXY_PROTOCOL = True # Mandatory setting for working with Nginx Stream
# AD_TAG = "GET_YOUR_AD_TAG_FROM_@MTProxybot" # Optional: for advertising tag

Wichtige Einstellungen hier sind: LISTEN_ADDR_IPV4 = "127.0.0.1" stellt sicher, dass MTProxy nur über Nginx auf demselben Server zugänglich ist, was die Sicherheit erhöht. MODES = {"tls": True} aktiviert den TLS-Masquerading-Modus, wodurch der MTProxy-Verkehr von regulärem HTTPS nicht zu unterscheiden ist. TLS_DOMAIN muss mit dem in der Nginx Stream map-Direktive angegebenen Domainnamen übereinstimmen, damit Nginx den Verkehr korrekt identifizieren und weiterleiten kann. Schließlich ermöglicht PROXY_PROTOCOL = True MTProxy, die echte IP-Adresse des Clients von Nginx zu empfangen, was für den ordnungsgemäßen Betrieb und die Protokollierung entscheidend ist.

Überprüfung und automatischer Start

Nach der Konfiguration von Nginx und MTProxy ist es unerlässlich, die Funktionalität des gesamten Systems gründlich zu überprüfen.

MTProxy- und Nginx-Funktionalität überprüfen

Manueller MTProxy-Start: Navigieren Sie in das Verzeichnis /opt/mtprotoproxy und starten Sie MTProxy manuell für eine erste Überprüfung:

```bash

python3 mtprotoproxy.py

```

Eine Zeile mit Proxy-Verbindungsparametern sollte in der Konsole erscheinen, zum Beispiel:

```

tg_user_1: tg://proxy?server=YOUR_VM_IP&port=7788&secret=LONG_SECRET

```

Wichtiger Hinweis: Das hier angezeigte Secret wird ein ee-Präfix haben und die kodierte TLS_DOMAIN enthalten, die in config.py angegeben ist. Dies ist Teil des TLS-Masquerading-Mechanismus. Kopieren Sie diesen Link.

Testen mit einem Telegram-Client:

* Ändern Sie im kopierten Link den Port von 7788 auf 443.

* Senden Sie den resultierenden Link an Ihre „Gespeicherten Nachrichten“ in Telegram.

* Klicken Sie auf den Link und wählen Sie „Verbinden“.

* Wenn alles korrekt konfiguriert ist, sollte Telegram erfolgreich über den Proxy verbinden. Für eine zusätzliche Überprüfung können Sie den Befehl /ping an einen beliebigen Bot (z.B. @MTProxybot) senden – eine Nachricht mit dem aktuellen Proxy-Ping sollte zurückgegeben werden.

HTTPS-Masquerading überprüfen: Um zu bestätigen, dass MTProxy sich korrekt als reguläre Website tarnt, führen Sie die folgende Überprüfung durch:

* Fügen Sie die folgende Zeile zu Ihrer lokalen hosts-Datei hinzu (für Linux/macOS ist dies /etc/hosts; für Windows ist es %SystemRoot%\System32\drivers\etc\hosts):

```

YOUR_VM_IP myprovider.ru

```

* Ersetzen Sie YOUR_VM_IP durch die tatsächliche IP-Adresse Ihres Servers.

* Öffnen Sie https://myprovider.ru in Ihrem Browser.

* Wenn alles korrekt funktioniert, sollten Sie den Inhalt von myprovider.ru sehen (die Website Ihres Providers oder eine andere Domain, die Sie in TLS_DOMAIN angegeben haben). Dies bestätigt, dass Nginx Stream die Anfrage an MTProxy umgeleitet hat und MTProxy, da es den Verkehr als Nicht-Telegram-Verkehr erkannte, ihn transparent an die ursprüngliche Webressource weitergeleitet hat, was ein erfolgreiches TLS-Masquerading demonstriert.

* Vergessen Sie nicht, die hinzugefügte Zeile nach der Überprüfung aus Ihrer hosts-Datei zu entfernen.

MTProxy als Systemd-Dienst einrichten

Stoppen Sie den manuell laufenden MTProxy (Strg+C).
Erstellen Sie eine systemd-Unit-Datei unter /etc/systemd/system/mtprotoproxy.service:

```ini

[Unit]

Description=MTProto Proxy

After=network.target

[Service]

Type=simple

User=nobody

Group=nogroup

WorkingDirectory=/opt/mtprotoproxy

ExecStart=/usr/bin/python3 /opt/mtprotoproxy/mtprotoproxy.py

Restart=always

RestartSec=3

[Install]

WantedBy=multi-user.target

```

Hier erhöhen User=nobody und Group=nogroup die Sicherheit, indem der Dienst mit minimalen Berechtigungen ausgeführt wird. WorkingDirectory verweist auf das Verzeichnis, in dem sich das Skript mtprotoproxy.py befindet.

Laden Sie die systemd-Konfiguration neu, aktivieren Sie den Dienst und starten Sie ihn:

```bash

sudo systemctl daemon-reload

sudo systemctl enable mtprotoproxy.service

sudo systemctl start mtprotoproxy.service

```

Überprüfen Sie den Dienststatus:

```bash

systemctl status mtprotoproxy.service

```

Die Ausgabe sollte anzeigen, dass der Dienst active (running) ist.

Protokolle anzeigen: Zur Fehlerbehebung oder Überwachung verwenden Sie:

```bash

journalctl -u mtprotoproxy.service -e

```

Dieses umfassende Setup ermöglicht es Ihnen, Telegram MTProxy auf Port 443 zu verwenden, es effektiv als regulären HTTPS-Verkehr zu tarnen und gleichzeitig die volle Funktionalität bestehender Websites auf demselben Server zu erhalten.

Was wichtig ist:

Die Verwendung von ssl_preread in Nginx Stream ermöglicht das Routing des Datenverkehrs basierend auf SNI ohne Entschlüsselung, was entscheidend für die Trennung von MTProxy- und HTTPS-Verkehr auf einem einzigen Port ist.
Die Konfiguration von proxy_protocol sowohl in Nginx als auch in MTProxy gewährleistet die Übertragung der echten IP-Adresse des Clients, was für Protokollierung und Sicherheit unerlässlich ist.
MTProxy ist im Modus tls: True mit angegebener TLS_DOMAIN konfiguriert, wodurch der Proxy-Verkehr von einer regulären HTTPS-Verbindung zu dieser Domain nicht zu unterscheiden ist.
Die Bindung von MTProxy an 127.0.0.1 erhöht die Sicherheit, indem der direkte externe Zugriff eingeschränkt wird.
Der systemd-Dienst gewährleistet den automatischen Start und die Überwachung von MTProxy und garantiert dessen kontinuierlichen Betrieb.