Proxyauthentifizierung mit Benutzername und Passwort: Verbindung und Fehlervermeidung

Bei Benutzername-Passwort-Authentifizierung sendet Ihre Anwendung die vom Anbieter vergebenen Zugangsdaten an den Proxy. Dieser prüft sie und erlaubt die Dienstnutzung. Das Verfahren hilft bei unterschiedlichen Geräten und Netzwerken: Verlangt der Dienst keine zusätzliche IP-Freigabe, muss beim Umzug eines Skripts auf einen anderen Server keine erlaubte IP-Adresse geändert werden.

Eine funktionierende Verbindung benötigt mehr als Benutzername und Passwort. Auch Proxyadresse, Port und Protokoll müssen stimmen; die Anwendung muss das verlangte Authentifizierungsverfahren unterstützen. Ein Authentifizierungsfehler bedeutet daher nicht zwangsläufig ein falsches Passwort.

Vergleich und Auswahl der Zugangsverfahren behandelt Proxyauthentifizierung. Dieser Artikel führt von der Eingabe der Einstellungen bis zur Fehlersuche in einem laufenden Skript durch den Zugang mit Benutzername und Passwort.

Was Benutzername-Passwort-Authentifizierung bedeutet

Der Benutzername identifiziert ein Konto oder den Zugang zu einem bestimmten Dienst; das Passwort bestätigt Ihre Nutzungsberechtigung. Nach erfolgreicher Prüfung verarbeitet der Proxy die Verbindung im erlaubten Rahmen: verfügbare Adressliste, gekauftes Kontingent und geltende Limits.

Verwechseln Sie Proxyzugangsdaten nicht mit dem Dashboard-Passwort. Die Anwendungsdaten können sich von der Anmeldung auf der Anbieterwebsite unterscheiden. Ein API-Schlüssel dient Anfragen an die Dienst-API, das Passwort einer Zielwebsite deren Anmeldung. Verwenden Sie eines davon nur dann als Proxypasswort, wenn der Anbieter dieses Verfahren ausdrücklich vorgibt.

Erfolgreiche Proxyauthentifizierung meldet Sie nicht an der Zielwebsite an. Verlangt diese ein eigenes Konto, Cookies oder ein Token, muss die Anwendung sie gesondert liefern.

Wann dieses Verfahren nützlich ist

Benutzername und Passwort können Anwendungen an mehreren festen oder wechselnden Standorten bedienen. Ohne IP-Beschränkung benötigt jede Anwendung Zugangsdaten und Verbindungseinstellungen, aber keinen eigenen Freigabeeintrag für ihr Netzwerk.

Ein Team arbeitet beispielsweise aus zwei Büros und von zu Hause mit jeweils anderer öffentlicher IP-Adresse. Die Anwendungen können dieselben Proxyzugangsdaten verwenden, wenn der Dienst deren gemeinsame Nutzung ohne IP-Bindung erlaubt. Jede Anwendung behält eigene Verbindungseinstellungen; der Proxy prüft die jeweils gesendeten Zugangsdaten.

Das funktioniert auch bei mehreren dauerhaft betriebenen Servern. Geräteanzahl, gleichzeitige Verbindungen und Ressourcen hängen jedoch vom Tarif ab. Ein Passwort erlaubt keinen unbegrenzten Zugang.

Wie eine Anwendung Proxyzugangsdaten sendet

Der Grundablauf ist einfach: Die Anwendung kontaktiert den Proxy, besteht die Zugangsprüfung und erreicht darüber die angeforderte Ressource. Einzelheiten hängen vom Protokoll ab.

Ein HTTP-Proxy kann zuerst 407 Proxy Authentication Required mit dem akzeptierten Verfahren senden. Die Anwendung übermittelt Authentifizierungsinformationen im Header Proxy-Authorization. Manche Clients senden sie sofort; die anfängliche Aufforderung erscheint dann möglicherweise nicht im Protokoll.

Beim Öffnen einer HTTPS-Website über einen gewöhnlichen HTTP-Proxy kann die Authentifizierung während der CONNECT-Anfrage zum Tunnelaufbau erfolgen. Anschließend baut die Anwendung die sichere Websiteverbindung auf. Weitere Anfragen durch diesen bestehenden Tunnel wiederholen dessen Proxyanmeldung nicht.

Bei SOCKS5 werden Benutzername und Passwort zu Verbindungsbeginn geprüft, vor der Zielverbindungsanfrage. Scheitert die Prüfung, erhält die Anwendung die gewünschte Proxyverbindung nicht. Ein nativer SOCKS5-Authentifizierungsfehler ist keine HTTP-407-Antwort.

Wählen Sie das unterstützte Protokoll und Authentifizierungsverfahren. SOCKS4 hat ein Nutzerkennungsfeld, definiert aber keinen SOCKS5-Benutzername-Passwort-Austausch. Das Ausfüllen dieses Feldes befähigt einen SOCKS4-Client nicht zur SOCKS5-Passwortauthentifizierung.

Welche Anwendungseinstellungen Sie eintragen

Beginnen Sie mit den Verbindungsdaten Ihres konkreten Dienstes. Gibt es getrennte Felder, tragen Sie jeden Wert in sein eigenes Feld ein:

Manche Anwendungen akzeptieren eine Zeichenfolge im Format protocol://username:password@host:port. In http://client01:River%[email protected]:8080 ist beispielsweise client01 der Benutzername, River@2026 das Passwort, proxy.example der Host und 8080 der Port. Das @ im Passwort wird als %40 dargestellt, um es vom Trennzeichen vor dem Host zu unterscheiden.

curl unterstützt beispielsweise diese Auswertung einer Proxy-URL. Ein eigenes Passwortfeld erwartet gewöhnlich das Passwort selbst ohne URL-Codierung. Kopieren Sie einen codierten URL-Wert nicht ungeprüft in ein getrenntes Feld: Die Anwendung könnte ihn als anderes Passwort behandeln. Bei %, Doppelpunkten oder anderen Sonderzeichen gelten die Formatvorgaben des Clients.

Codieren Sie erforderliche Zeichen innerhalb der Zugangsdaten einmal. Die Codierung der gesamten Zeichenfolge würde ihre Trennzeichen zerstören. Anführungszeichen um ein Befehlsargument ersetzen keine URL-Codierung. Auch das Authentifizierungsverfahren kann Grenzen haben: HTTP Basic erlaubt beispielsweise einen Doppelpunkt im Passwort, aber nicht im Benutzernamen.

Auch Importformate unterscheiden sich. host:port:username:password und username:password@host:port sind nicht austauschbar. Korrekte Werte in falscher Reihenfolge funktionieren nicht, wenn der Importer eine andere Anordnung erwartet.

Das Präfix http:// einer Proxy-URL beschreibt die Clientverbindung zum Proxy selbst. Es verhindert keine HTTPS-Websites: Dafür kann der Client einen Tunnel aufbauen. Ein Präfixwechsel zu https:// ergänzt keine sichere Proxyverbindungsunterstützung auf dem Server.

Manche Dienste nehmen Land, Ausgangsgruppe oder Sitzungsparameter in den Benutzernamen auf. Kopieren Sie die vollständige Zeichenfolge. Diese Parameter steuern Routing nach Anbieterregeln. Erfinden Sie keine Syntax und übernehmen Sie keine von einem anderen Dienst.

Warum die Authentifizierungsunterstützung der Anwendung geprüft werden muss

Proxyunterstützung und Proxyauthentifizierung sind getrennte Fähigkeiten. Host- und Portfelder bedeuten nicht zwangsläufig, dass der Client Benutzername und Passwort senden kann.

Prüfen Sie die genaue Kombination aus Protokoll, Verfahren und Anwendung. Chromes eingebautes SOCKS5 unterstützt beispielsweise keine SOCKS5-Proxyauthentifizierung. Korrekte Zugangsdaten allein beheben diese Grenze nicht. Auch eine Erweiterung zur Proxyauswahl ergänzt das fehlende Verfahren nicht zwangsläufig.

Bei Skripten kann die Unterstützung von Bibliothek, optionalen Komponenten und Einstellungsübergabe abhängen. Eine Anwendung verwendet nicht zwangsläufig System-Proxyeinstellungen oder die Einstellungen eines bereits funktionierenden Browsers.

Testen Sie vor einer großen Aufgabe eine Anfrage in der späteren Arbeitsanwendung. Bestätigen Sie den angegebenen Proxy und prüfen Sie, dass die Anwendung nach Fehlern nicht direkt weiterverbindet. Ein erfolgreicher Seitenaufruf allein bestätigt keine korrekten Einstellungen.

Was bei einer IP-Änderung geschieht

Bei einem ADSL-Anschluss mit dynamischer IP-Adresse kann der Anbieter nach Routerneustart oder Neuverbindung eine neue Adresse vergeben. Prüft der Proxy nur Benutzername und Passwort, verbindet sich die Anwendung mit denselben Daten. Im Dashboard muss keine neue IP-Adresse hinzugefügt werden. Dasselbe gilt für den Wechsel vom Büro ins Heimnetz.

Ein Netzwerkwechsel kann allerdings bestehende Verbindungen unterbrechen. Der Client muss neu verbinden; eine offene Anfrage muss möglicherweise wiederholt werden. Ein Fehler unmittelbar nach dem Wechsel von WLAN auf Mobilfunk ist nicht automatisch ein Passwortproblem.

Manche Dienste prüfen Zugangsdaten und Quelladresse gemeinsam. Ein korrektes Passwort hebt die Netzwerkbeschränkung nicht auf: Die neue IP-Adresse muss zu einer erlaubten Adresse oder einem Bereich passen. Klären Sie vor dem Skriptumzug, ob beliebige Netzwerke akzeptiert oder kombinierte Prüfungen angewendet werden.

Ist das Passwort während der Übertragung geschützt?

Authentifizierung bestimmt, wer Zugang erhält. Verschlüsselung bestimmt, ob jemand auf dem Weg die Daten lesen kann. Ein Passwort allein verschlüsselt die Verbindung nicht.

HTTP Basic codiert Benutzername und Passwort mit Base64. Das ist eine umkehrbare Darstellung, keine Verschlüsselung. Ohne Schutz zum Proxy können Beobachter des Netzwerkwegs die Daten erhalten. Auch übliche SOCKS5-Benutzername-Passwort-Authentifizierung verschlüsselt ihre Übertragung nicht.

HTTPS der Zielwebsite schützt die Verbindung zwischen Anwendung und Website. Bei einem HTTP-Proxy erfolgt die Authentifizierung beim Tunnelaufbau früher; Website-TLS schützt bereits gesendete Proxyzugangsdaten nicht. Ebenso verschlüsselt eine HTTPS-Anfrage durch SOCKS5 nicht die vorausgehende Passwortprüfung.

Der betreffende Weg benötigt Schutz zwischen Anwendung und Proxy, etwa durch einen HTTPS-Proxy mit TLS, sofern Dienst und Client dies unterstützen. Die Anwendung muss das Proxyzertifikat prüfen. Manche Verkaufsangebote meinen mit „HTTPS-Proxy“ nur die Erreichbarkeit von HTTPS-Websites. Prüfen Sie deshalb, wo TLS tatsächlich gilt.

Wird eine vollständige Verbindungszeichenfolge mit gültigem Passwort offengelegt, können andere den Dienst innerhalb seiner Regeln nutzen, Kontingente verbrauchen oder Verbindungen belegen. Bei getrennten Zugangsdaten entspricht das nicht dem Erhalt des Dashboard-Passworts. Das Verfahren garantiert auch keine Nichterkennbarkeit als Proxy: Eine extern erreichbare Authentifizierungsaufforderung kann den Dienst verraten.

Können mehrere Anwendungen dieselben Zugangsdaten nutzen?

Technisch können mehrere Clients denselben Benutzernamen und dasselbe Passwort senden. Ob das erlaubt ist und welche Grenzen gelten, bestimmt der Anbieter: Teilungsbedingungen, aktive Verbindungslimits, gekauftes Kontingent und zusätzliche Einschränkungen.

Zwei Skripte können beispielsweise ein Konto mit unterschiedlich vielen Verbindungen verwenden. Ein Passwort bedeutet nicht eine Verbindung. Ebenso verzehnfachen zehn Prozesse das Gesamtverbindungskontingent nicht.

Die Anzahl der Zugangsdatenpaare unterscheidet sich von der Anzahl der Ausgangs-IP-Adressen. Ein Paar kann Zugang zu einer statischen Proxyliste oder einem Gateway mit Adresspool geben. Die Website-IP-Adresse hängt vom ausgewählten Proxy und den Routing-Regeln ab.

Bietet der Dienst getrennte Zugangsdaten für Anwendungen oder Teammitglieder, kann ein Satz ohne Änderung der anderen deaktiviert werden. Ein gemeinsamer Passwortwechsel verlangt dagegen die Aktualisierung aller verwendenden Anwendungen. Separate Zugangsdaten bedeuten dennoch keine getrennten Verbindungs- oder Datenkontingente. Prüfen Sie gemeinsame Limits.

Warum ein Proxy Benutzername und Passwort ablehnt

Klären Sie zuerst den Fehlerursprung. HTTP 407 betrifft Proxyauthentifizierung; 401 der Zielwebsite deren Zugang. Eine 403-Meldung oder Zeitüberschreitung beweist ohne weitere Hinweise weder richtige noch falsche Proxyzugangsdaten.

Prüfen Sie Dienststatus und Restkontingent und testen Sie eine Anfrage mit den gelieferten Einstellungen in der tatsächlichen Anwendung. Scheitert sie, prüfen Sie anhand der Tabelle Clientunterstützung, Format und Quell-IP-Regeln. Ändern Sie jeweils eine Einstellung. Funktioniert die Anfrage zuverlässig, erhöhen Sie die Last und beobachten nur darunter auftretende Limits.

Zugangsdaten in laufenden Skripten speichern und ändern

Halten Sie Zugangsdaten getrennt vom Code in zugriffsgeschützter Konfiguration oder im Geheimnisspeicher Ihrer Umgebung. Umgebungsvariablen können sie übergeben, sind aber selbst keine Verschlüsselung. Halten Sie aktive Passwörter aus Repositories und geteilten Vorlagen heraus.

Ein Protokoll benötigt gewöhnlich Proxyhost und Port, Verbindungsergebnis und Fehlercode. Eine vollständige Verbindungszeichenfolge enthält das Passwort. Entfernen Sie es vor dem Protokollieren. Bei Kommandozeilenwerkzeugen können Geheimnisse je nach Anwendung und System in Befehlsverlauf oder Prozessargumenten sichtbar bleiben.

Ermitteln Sie vor einem Passwortwechsel alle Verbraucher: lokale Anwendungen, Serverprozesse, Zeitplanaufgaben und Build-Systeme. Aktualisieren Sie anschließend deren Einstellungen und testen Sie neue Verbindungen. Prüfen Sie auch lang laufende Prozesse auf den neuen Wert; manche benötigen einen Neustart.

Soll das alte Passwort unwirksam sein, testen Sie die Ablehnung einer neuen Verbindung damit. Bestehende Verbindungen folgen den Dienstregeln. Ein Passwortwechsel schließt sie nicht immer sofort. Verwenden Sie bei dringendem Widerruf das unterstützte Verfahren zur Zugangssperrung.

Kombinierte Authentifizierung: IP-Adresse und Passwort

Bei kombinierter Authentifizierung prüft der Proxy Zugangsdaten und Quelladresse der Anwendung. Beide Bedingungen müssen erfüllt sein. Ein korrektes Passwort allein hebt die IP-Beschränkung nicht auf.

Für statische ProxyCompass-Pakete verwendet der kombinierte Modus ein /24-Subnetz. Haben Sie mehrere öffentliche IPv4-Adressen desselben Subnetzes, genügt ein einziger Zulassungseintrag. Die übrigen können sich mit korrektem Benutzernamen und Passwort ohne eigene Einträge verbinden.

In der Abbildung stimmen die ersten drei Zahlen der öffentlichen Anwendungsadresse mit der freigegebenen Adresse überein. Mit gültigen Zugangsdaten kann sie verbinden. Eine Adresse außerhalb des Subnetzes scheitert an der Netzprüfung; ein falsches Passwort scheitert auch innerhalb. Andere Client-IP-Adressen desselben Subnetzes können den Eintrag ebenfalls nutzen. Das hilft Anwendungen mit erforderlichen Zugangsdatenfeldern. Die Regel betrifft öffentliche Anwendungsadressen, nicht gekaufte Proxy-Ausgangs-IP-Adressen.