Die sinnvolle Reihenfolge für die Serverseite einer eigenen Proxy-IP: zuerst den SSH-Zugang prüfen, dann Port ändern und auf Schlüsselanmeldung umstellen, die Grundhärtung erledigen, den Proxy-Dienst installieren und den Port freigeben und schließlich den Client anbinden und testen.
Wer einen Cloud-Server als Proxy nutzt, scheitert nur selten an der reinen Erreichbarkeit. Häufiger liegt das Problem in der Reihenfolge der Vorbereitung auf der Serverseite. Stimmt die Reihenfolge, klappt die Client-Verbindung meist beim ersten Versuch; ist sie durcheinander, muss man immer wieder ins Terminal zurück und Einstellungen ändern.
Hier geht es nur um die Serverseite: vom ersten Login und dem Absichern des Zugangs über den laufenden Proxy-Dienst und die Portfreigabe bis zur Client-Verbindung und einer schichtweisen Fehlersuche, wenn es nicht klappt.
Beim ersten Login zuerst den Zugang prüfen
Nachdem die Instanz erstellt wurde, melden Sie sich zunächst über das Web-Terminal in der Konsole des Anbieters an und verlassen Sie sich nicht sofort auf ein lokales Tool. In diesem Schritt geht es nur darum zu prüfen, ob die Maschine läuft und das Netzwerk erreichbar ist.
Wechseln Sie danach zu root, führen Sie sudo -i aus und drücken Sie Enter. Wenn sich die Eingabeaufforderung von $ zu # ändert, war die Rechteerhöhung erfolgreich. Die folgenden Schritte werden mit dieser Identität ausgeführt.
Notieren Sie dabei vier Angaben: öffentliche IP, Login-Benutzername (unter Linux standardmäßig root), Passwort und SSH-Port (standardmäßig 22). Genau diese vier Werte werden beim Client-Zugriff benötigt; fehlt einer, kommt keine Verbindung zustande.
Standardport ändern und anschließend auf Schlüsselanmeldung umstellen
Port 22 wird täglich unzählige Male gescannt, und automatisierte Anmeldeversuche sind normal. Ein anderer Port macht den Server nicht grundsätzlich sicherer, filtert aber einen großen Teil des automatisierten Hintergrundrauschens heraus.
Die Änderung erfolgt in /etc/ssh/sshd_config. Öffnen Sie die Datei mit vi, drücken Sie i für den Bearbeitungsmodus, setzen Sie die Zeilen PermitRootLogin und PasswordAuthentication auf yes und speichern Sie nach Esc mit :wq. Wenn der Anbieter die Schlüsselanmeldung unterstützt, ist es robuster, den lokalen öffentlichen Schlüssel in authorized_keys auf dem Server einzutragen und anschließend PasswordAuthentication auf no zu setzen, sodass nur noch Schlüssel akzeptiert werden.
Beenden Sie die aktuelle Sitzung nach der Änderung nicht sofort. Öffnen Sie zuerst ein zweites Terminalfenster, melden Sie sich einmal mit dem neuen Port und der neuen Methode an und schließen Sie das alte Fenster erst, wenn der Login funktioniert. Andernfalls kann ein Konfigurationsfehler Sie aussperren, sodass nur noch die Anbieter-Konsole zur Rettung bleibt.
Der SSH-Port steht in der Zeile Port. Starten Sie nach der Änderung den SSH-Dienst neu, damit die Konfiguration wirksam wird. Auf Debian- und Ubuntu-Systemen können Sie /etc/init.d/ssh restart ausführen.
Grundhärtung gleich am ersten Tag erledigen
Neben Portwechsel und Schlüsseln sind zwei kleine Aufgaben sinnvoll. Erstens sollte root mit passwd root ein ausreichend langes, zufälliges Passwort erhalten, statt einer leicht zu erratenden Kombination. Zweitens sollten nicht benötigte Dienste und Ports abgeschaltet werden. Je weniger auf der Maschine läuft, desto kleiner ist die Angriffsfläche; die System-Firewall sollte nur tatsächlich benötigte Ports freigeben.
Wenn der Server langfristig nur für einige feste Quelladressen genutzt wird, können diese Quellen in der Sicherheitsgruppe eingeschränkt werden. Das ist deutlich sicherer als eine Freigabe für das gesamte Internet.
Proxy-Dienst installieren und Authentifizierung konfigurieren
Nach der Initialisierung des Servers kommt der eigentliche Proxy an die Reihe.
Eine Möglichkeit ist ein direkter SSH-Tunnel. Auf dem Server muss nichts zusätzlich installiert werden; der Client nutzt den eingebauten SSH-Dienst des Systems zur Weiterleitung und verwendet die normalen Server-Zugangsdaten. Das ist bequem, bietet aber nur mittlere Leistung und stößt bei hoher Parallelität schnell an Grenzen. Es eignet sich daher für vorübergehende Nutzung oder wenige Konten.
Die andere Möglichkeit ist ein eigener Proxy-Dienst auf dem Server. Meist lässt er sich mit einem einzelnen Installationsbefehl einrichten, danach konfigurieren Sie Authentifizierung und Listen-Port selbst. Aktivieren Sie den Dienst für den automatischen Start; sonst ist der Proxy nach einem Server-Neustart nicht mehr verfügbar.
Bei der Authentifizierung gibt es drei übliche Stufen mit steigender Sicherheit: Benutzername und Passwort sind am einfachsten, aber bei einem Leak ist der Proxy praktisch freigegeben; Passwort plus Quell-IP-Whitelist reicht für den Alltag oft aus; Schlüssel- oder Zertifikatsauthentifizierung ist am robustesten, erfordert jedoch mehr Einrichtung und lohnt sich für langfristig genutzte Konten.
Port an zwei Stellen getrennt freigeben
Hier entstehen besonders häufig Probleme. Der Listen-Port des Proxy-Dienstes muss sowohl in der System-Firewall als auch in der Sicherheitsgruppe des Anbieters freigegeben werden. Beide Regeln sind unabhängig; nur eine Seite zu öffnen reicht nicht.
Leicht übersehen wird auch die Listen-Adresse des Dienstes. Manche Dienste binden standardmäßig nur an 127.0.0.1. Funktioniert der Test direkt auf dem Server, aber nicht von außen, liegt es oft daran. Ändern Sie die Listen-Adresse auf die private Serveradresse oder auf 0.0.0.0.
Verbindung vom lokalen Client herstellen
Legen Sie im Umgebungsverwaltungs-Tool eine neue Umgebung an und wählen Sie den tatsächlich verwendeten Proxy-Typ. Bei einem SSH-Tunnel ist die Adresse die öffentliche IP des Servers, der Port ist der SSH-Port und Benutzername sowie Passwort entsprechen den Server-Zugangsdaten. Führen Sie danach den Verbindungstest aus.
Ein erfolgreicher Test zeigt nur, dass die Verbindung grundsätzlich steht. Öffnen Sie die Umgebung und prüfen Sie drei weitere Punkte: Entspricht die Ausgangs-IP der öffentlichen IP des Servers? Läuft DNS ebenfalls über den Proxy, denn lokale DNS-Auflösung kann Regionsdaten offenlegen, die nicht zur Ausgangs-IP passen? Stimmen Zeitzone und Sprache mit der Ausgangsregion überein? Erst wenn alle drei Punkte passen, ist die Umgebung einsatzbereit.
Wenn die Zahl der Konten wächst, sollte die Zuordnung zwischen Umgebung und Ausgang fest bleiben, damit nicht mehrere Konten dieselbe Umgebung teilen. Werkzeuge wie PurpleMark können jedem Konto einen eigenen Ausgang zuweisen und sind damit verlässlicher als eine manuell gepflegte Zuordnungstabelle.
Bei Verbindungsproblemen von außen nach innen prüfen
Beginnen Sie ganz außen: Ist die Sicherheitsgruppe freigegeben? Ist die System-Firewall freigegeben? Erst wenn beides bestätigt ist, gehen Sie weiter.
Prüfen Sie danach den Dienst selbst: Läuft der Prozess noch, besonders nach einem Server-Neustart? Ist die Listen-Adresse nur lokal gebunden?
Danach folgt die Authentifizierung: Sind Benutzername oder Passwort falsch? Sind die Berechtigungen der Schlüsseldatei zu weit gefasst? SSHD lehnt Schlüssel bei falschen Berechtigungen direkt ab. Erst ganz zum Schluss sollte die Client-Seite geprüft werden: Wurde die öffentliche IP oder versehentlich die private IP eingetragen? Diese Verwechslung kommt besonders häufig vor.
Mit dieser Reihenfolge lässt sich die fehlerhafte Schicht meist nach zwei oder drei Durchgängen finden, statt den Dienst immer wieder neu zu installieren.
Abschluss
Die Vorbereitung der Serverseite dauert weniger als eine halbe Stunde, bestimmt aber, wie pflegeleicht der Server in den folgenden Monaten bleibt. Zugang absichern, Ports korrekt freigeben und die Authentifizierung sauber konfigurieren; danach bleibt nur noch die normale Wartung.
