Fallstudie // Private VPN-Infrastruktur

Fortochka
Private VPN

Python 3.12FastAPIaiogram 3SQLAlchemy 2AmneziaWGWireGuardsystemdNext.js 16
Zur archivierten Website
01 // Zusammenfassung
Die Herausforderung

Ein Dienst,
von Hand betrieben

Ein privates VPN für Freunde und Familie funktioniert, bis es über eine Handvoll Leute hinauswächst. Jedes neue Gerät bedeutete eine SSH-Sitzung, ein Shell-Skript, eine per Hand verschickte Konfigurationsdatei. Niemand wusste, wie viel Traffic wer verbraucht hatte, ein abgelaufenes Abo fiel einem ein oder eben nicht, und wenn jemand sagte "es geht nicht mehr", blieb nur, sich auf den Server einzuloggen und den Zustand des Interfaces selbst zu lesen.

Die Lösung

Ein Boss und
seine Worker

Statt eines Skripts, das alles macht, ist der Dienst zweigeteilt. Auf jedem VPN-Knoten läuft ein Agent: ein kleiner HTTP-Dienst mit genau sechs Operationen, der ausschließlich innerhalb eines reinen Management-WireGuard-Tunnels lauscht — von außen existiert sein Port nicht. Separat läuft der Boss: Datenbank, Scheduler und der Telegram-Bot, mit dem die Leute tatsächlich sprechen. Der Boss initiiert jede Kommunikation, die Agenten antworten nur. Entscheidend: Der Boss liegt nicht im Datenpfad — fällt er aus, transportiert das VPN weiter Pakete, nur die Abrechnung pausiert.

02 // Wichtige Ergebnisse
260

Tests

183 Boss · 77 Agent

6

Agent-Operationen

der gesamte Vertrag

0

Traffic über den Boss

nur Steuerungsebene

2

Verwaltete Knoten

Produktiv und Labor

03 // Technische Highlights

Der Agent hat keine öffentliche Angriffsfläche

Er bindet nur an die Tunnel-Adresse; ein Scan des Servers findet auf seinem Port nichts — von außen geprüft. Seine sechs Operationen sind die komplette API: Peers auflisten, anlegen, aktivieren, deaktivieren, Statistik, Diagnose. Das Auth-Token wird mit einer laufzeitkonstanten Funktion verglichen statt mit einfachem Gleichheitsvergleich, denn String-Vergleiche verraten ihr Ergebnis über das Timing.

Ausfall der Steuerungsebene ist kein Ausfall des Dienstes

Der Boss hält die Datenbank und steuert alles, aber kein Paket läuft durch ihn. Nimmt man ihn offline, funktionieren bestehende Tunnel weiter; nur Abrechnung und Benachrichtigungen pausieren. Dasselbe Prinzip entscheidet über einen schweigenden Agenten: keine frischen Daten bedeutet, dass niemand wegen Quotenüberschreitung getrennt wird — stattdessen bekommt der Admin eine Warnung, denn auf fehlende Daten zu reagieren ist schlimmer als spät zu reagieren.

Verbrauchszählung, die einen Neustart übersteht

WireGuard-Zähler werden bei jedem Interface-Neustart zurückgesetzt, was sich läse, als hätte jemand plötzlich negativen Traffic verbraucht. Der Verbrauch wird deshalb gegen einen gespeicherten Basiswert kumuliert statt direkt gelesen, und ein rückwärts gelaufener Zähler wird als Neustart erkannt, nicht als Anomalie.

04 // Projekt-Walkthrough
DEMO_RENDER // PENDING
PRJ-002

Archiviert // 2026

Der Dienst lief für eine kleine Gruppe echter Menschen auf zwei Knoten und wurde im September 2026 abgeschaltet: Zwei Server für eine Handvoll Freunde zu bezahlen und zu überwachen, hat sich nicht mehr gelohnt. Die Website bleibt als Demo der Landingpage online; kaufen kann man dort nichts.

Zu diesem Projekt

Fragen
zur Architektur?

Ich erkläre gern, warum der Agent hinter einem Tunnel sitzt, was passiert, wenn er verstummt, und warum die Traffic-Zähler einen Basiswert brauchten statt eines einfachen Auslesens.