Listen, Bind und BindSame bei Tinyproxy: Welche Adresse gewinnt

Der Proxy antwortet, die Anfrage läuft durch, und trotzdem notiert das Ziel weiterhin die LAN-Adresse. Im Proxy-Log sieht nichts falsch aus, und die geänderte Zeile ist genau die, die die Dokumentation zu ändern hieß. Auf einem Host mit LAN-Adresse und Tunneladresse entscheiden drei Direktiven, welche Adresse wo erscheint, und nur eine davon betrifft die ausgehende Seite. Liest man sie in falscher Reihenfolge, landet man ohne Grund in der Routingtabelle.

Das Symptom: das Ziel sieht die LAN-Adresse

Ein Client verbindet sich über die LAN-Adresse mit dem Proxy, und der Proxy öffnet seine eigene Verbindung zum Ziel. Diese zweite Verbindung wählt eine Quelladresse nach den Regeln des Kernels, und standardmäßig ist es die, die die Routensuche auswählt. Das Ziel notiert daher die primäre Adresse des Hosts, obwohl jedes Byte durch den Proxy lief. Am Weiterleiten ist nichts kaputt, und deshalb hat das Proxy-Log dazu nichts zu sagen.

Das Spiegelbild dieses Fehlers ist leichter zu sehen: nagelt die ausgehende Quelle auf die Tunneladresse fest, und LAN-Clients erreichen den Listener überhaupt nicht mehr. Diese Variante meldet sich selbst, während die erste sich hinter einer funktionierenden Anfrage versteckt. Beide entstehen daraus, eine Direktive zu behandeln, als beantworte sie beide Fragen.

Drei Direktiven, drei verschiedene Adressen

Listen benennt die lokale Adresse, die Proxy-Clients annimmt. Bind liefert eine Quelladresse für die Verbindungen, die der Proxy nach außen aufbaut, und BindSame weist ihn an, die lokale Adresse der gerade angenommenen Verbindung wiederzuverwenden. Das sind drei getrennte Fragen, und eine einzelne Zeile beantwortet nur eine davon. Sie zu verwechseln ist der übliche Grund, warum eine Änderung wirkungslos erscheint.

Lesen Sie die kommentierte Konfiguration, die mit der installierten Version ausgeliefert wird, denn Standardwerte und akzeptierte Syntax verschieben sich zwischen Releases. Die Beispielkonfiguration des Projekts dokumentiert jede Direktive neben den anderen. Vergleichen Sie diese Datei mit der auf der Platte, nicht mit einer Anleitung für eine andere Distribution.

Listener und ausgehende Quelle getrennt setzen

Nehmen Sie einen Host, dessen LAN-Adresse 192.168.50.10 und dessen Tunneladresse 10.90.0.3 ist. Sollen LAN-Clients den Proxy erreichen, während ihre Anfragen über den Tunnel hinausgehen, sind das zwei unabhängige Entscheidungen, und beide müssen notiert werden. Das folgende Fragment drückt genau das aus und nichts weiter.

Listen 192.168.50.10
Bind 10.90.0.3
BindSame no

Das ist keine vollständige Konfiguration, behalten Sie also den freigegebenen Port, die Authentifizierung, die Client-Zugriffskontrollen und die Zielbeschränkungen bei. Beide Adressen müssen diesem Host innerhalb des Netzwerk-Namespace von Tinyproxy gehören, denn ein Bind-Wert, den der Prozess nicht besitzen kann, scheitert beim Verbinden, nicht beim Start. BindSame yes beschreibt eine andere Politik, bei der die lokale Adresse der angenommenen Verbindung zur ausgehenden Quelle wird. In aktuellen Releases hat dieser Zweig Vorrang vor der Bind-Liste, und so verschwindet eine konfigurierte Quelle ohne Fehlermeldung.

Prüfen Sie die Route, die die Quelle impliziert

Eine Quelladresse zu wählen schafft keinen Pfad, fragen Sie den Kernel also, was er mit dieser Quelle und diesem Ziel täte. Eine Suche, die das Tunnel-Interface nennt, ist der Mindestbeleg, und eine, die das LAN-Interface nennt, bedeutet, dass die Quelle so nicht funktionieren kann. Die Suche ist kontextabhängig: Sie wertet die Policy-Regeln und die Tabelle aus, die in diesem Namespace gelten. Sie ist keine Verbindung und sagt nichts darüber, was ein nachgelagertes NAT dem Dienst präsentiert.

ip -4 route get 203.0.113.25 from 10.90.0.3

Verwenden Sie im Beispiel eine Dokumentationsadresse und setzen Sie den Dienst ein, den zu testen Sie berechtigt sind. Führen Sie die Suche im Namespace des Proxys aus, wenn der Proxy containerisiert läuft, denn die Regeln des Hosts sind nicht die Regeln, die der Prozess sieht. Fehlt die beabsichtigte Tunnelroute, soll der Netzwerkeigentümer sie richten, statt zielspezifische Regeln auf dem Proxy-Host zu ergänzen. Löschen Sie keine Host-Routen und deaktivieren Sie keine servergepushten Routen, damit eine Suche gelingt, auch wenn eine ältere Anleitung das tat, denn solche Änderungen verschieben das gesamte freigegebene VPN-Verhalten des Hosts, um einen Proxy-Pfad zu reparieren.

Bestätigen Sie die Quelle am Ziel

Lesen Sie die Quelle dort, wo die Anfrage ankommt, nicht wo sie hinausgeht. Das Anwendungslog des Ziels oder das Edge-Gerät davor notiert die Adresse, die es tatsächlich gesehen hat, während der Proxy Ihnen nur sagen kann, was er beabsichtigte. Schicken Sie nach der Änderung eine frische Anfrage über den beabsichtigten Listener, denn eine zwischengespeicherte Verbindung beweist nichts über die neue Bindung. Vergleichen Sie dann die notierte Adresse mit der konfigurierten.

ss -ltnp | grep tinyproxy
curl -x http://192.168.50.10:8888 https://example.com -o /dev/null -sS

curl ist nur der Verkehrsgenerator; die Adresse, die eine Prüfung verdient, ist die, die die ferne Seite protokolliert hat, nicht der Peer, mit dem curl zufällig verbunden war. Widersprechen sich beide, klären Sie, ob der Unterschied aus der Quellwahl oder aus einer Übersetzung weiter hinten kommt, denn beides wird an verschiedenen Stellen behoben. Planen Sie Adressänderungen und Proxy-Neustarts zusammen, denn das Binden einer Adresse, die der Tunnel nicht mehr hält, scheitert nach einer Neuverbindung still. Definieren Sie DNS- und IPv6-Verhalten ebenfalls getrennt, denn das IPv4-Fragment oben beweist über keines von beiden etwas.