Verwendung (iProyal-kompatibles Format):
http://<username>:<password>_country-us_session-abc12345_lifetime-10m@:
Parameter im Passwort (mit Underscore getrennt):
_country-XXISO-Code (z.B.us,de,gb)_session-XXXXXXXXSticky-Session-Key (4-32 alphanumerisch)_lifetime-XmSticky-Dauer (z.B.5s,10m,20h,7d)
Traffic-Übersicht
Top Hosts
IP-Whitelist
Nur diese IP-Adressen dürfen auf die Proxy-Ports (2222-2333) zugreifen. Änderungen werden innerhalb von 5 Sekunden vom Gateway übernommen.
| IP | Bezeichnung | Erstellt |
|---|
Sicherheitsarchitektur
Kill-Switch (nftables)
Jeder VPN-Worker hat einen nftables-basierten Kill-Switch, der sämtlichen Netzwerkverkehr ohne aktiven VPN-Tunnel blockiert.
- Default Policy: DROP — Alles wird blockiert, was nicht explizit erlaubt ist
- Erlaubt: DNS nur zu
8.8.8.8,8.8.4.4,9.9.9.9,1.1.1.1 - Erlaubt: Ausgehend nur zum aktuellen VPN-Server (1 IP-Adresse)
- Erlaubt: Alles über
tun0(der VPN-Tunnel) - Erlaubt: Eingehend auf Port
8888(TinyProxy, nur Docker-intern) - Erlaubt: Ausgehend zu MariaDB Port
3306(Docker-intern) - Alles andere wird verworfen — kein Traffic kann ohne VPN nach außen
Wenn das VPN ausfällt, gibt es keinen Fallback über die echte IP. Der Container ist dann komplett offline — genau so gewollt.
IP-Whitelist (iptables im Gateway)
Das Gateway ist der einzige Container mit exponierten Ports (2222-2333). Es erlaubt nur Verbindungen von IPs die in der Whitelist stehen.
- Jeder Port bekommt eine eigene iptables-Regel
- Nicht-gelistete IPs werden sofort gedroppt (kein REJECT, kein Feedback)
- Die Whitelist wird alle 5 Sekunden aus der DB nachgeladen
- Änderungen über das Dashboard wirken innerhalb von 5 Sekunden
Netzwerk-Isolation (Docker)
- VPN-Worker sind nur im
backend-Netzwerk (172.19.0.0/16, Docker-intern) - Kein Worker hat exponierte Ports — Zugriff nur über das Gateway
- Jeder Worker hat
NET_ADMIN+/dev/net/tunfür OpenVPN - Das Gateway hat
privileged-Modus für iptables - Die API ist nur über Traefik (HTTPS) erreichbar
DNS-Leak-Schutz
- DNS-Anfragen sind per nftables auf 4 Server beschränkt
- Über den VPN-Tunnel wird der DNS des VPN-Providers genutzt
- IPv6 wird komplett ignoriert (
pull-filter ignore route-ipv6)
Automatische Sicherheitstests
Jeder Worker führt regelmäßig Selbsttests durch und meldet die Ergebnisse:
- eth0-Leak-Test: Versucht über eth0 (ohne VPN) eine externe IP zu erreichen — muss fehlschlagen
- tun0-Test: Prüft ob der VPN-Tunnel aktiv ist
- nftables-Test: Prüft ob die Firewall-Regeln geladen sind
- IP-Vergleich: Prüft ob die VPN-Exit-IP sich von der Server-IP unterscheidet
Ergebnisse im Audit-Log und als Status hier:
Bei jedem Proxy-Request fügt der Smart-Gateway zwei Header in die Antwort an den Client:
X-Proxy-Request-ID (UUID) und X-Proxy-Exit-IP. Diese Header sind nur
zwischen Client und Gateway sichtbar — der Ziel-Server bekommt sie nie zu sehen.
Der Client schickt anschließend einen separaten POST an
/api/proxy-feedback mit der UUID und einer Bewertung (-1/0/+1).
Alternativ können session + host als Identifier dienen.
⚙ Auto-Block-Regel
Score-Formel: weighted = pos × positive_weight − neg × negative_weight ·
Block bei weighted ≤ −threshold UND total ≥ min_feedback_count.
Positives Feedback wiegt absichtlich mehr — ein guter Eintrag kann mehrere schlechte neutralisieren.
Worker-Scores
Problematische Exit-IPs
Letzte Feedback-Einträge
📋 Automation-Log (Block / Reconnect / Rule-Changes)
Pro Provider kann festgelegt werden, wie viele Worker in welchem Land laufen. Der Rest wird zufällig aus allen verfügbaren Servern gewählt. Wird die Quota geändert, lösen alle Worker des Providers einen Reconnect aus — das überschreibt manuell gesetzte Country-Werte.
IP-Bans
Gebannte IPs werden vom Worker bei Reconnects übersprungen. Default-Dauer pro Provider in der Country&Quota-Sektion.
| IP | Verbleibend | Grund | Worker | Erstellt | Status |
|---|