MULTI: ungültige Quelladresse vom Client: Wessen Adresse war das?
Die innere Quelle stimmt nicht mit dem Client überein, der sie geliefert hat. Ordnen Sie sie einer Tunnelzuweisung, einem LAN hinter dem Client oder einer doppelten Identität zu.
Das Serverprotokoll gibt MULTI: bad source address from client aus, verwirft das Paket, und die Sitzung bleibt verbunden. Diese Kombination verwirrt Leute, die die Meldung als fehlgeschlagene Authentifizierung lesen. Das ist sie nicht: Der Client hat sich authentifiziert, und das ankommende Paket trug eine innere Quelladresse, die der Server nicht dieser Client-Instanz zuordnen konnte. Die Prüfung erfolgt vor der Zustellung, weshalb der Tunnel gesund aussieht, während nichts Nützliches ihn passiert.
Was der Server vor der Zustellung vergleicht
Für jedes von einem Client eintreffende Paket betrachtet der Userspace-Server die Quelladresse innerhalb des Tunnels und fragt seinen internen Routingzustand, welchem Client diese Adresse gehört. Ist der Eigentümer eine andere Instanz oder gibt es gar keinen Eigentümer, wird das Paket verworfen und die Warnung ausgegeben.
Eine gewöhnliche Zustellung über die Tunnelschnittstelle findet nie statt.
Diese Reihenfolge erklärt ein Detail, das Leute verblüfft: Die Zähler der Host-Firewall bewegen sich nicht, weil das Paket die Firewall nie erreicht hat. Die Anpassung der Reverse-Path-Filterung auf dem Host ändert hier nichts, da die Ablehnung in der eigenen Zuordnungsprüfung des Daemons geschah. Lesen Sie die Meldung als Aussage über Eigentum und finden Sie dann heraus, welche der drei Situationen sie hervorrief.
Drei Ursachen einer nicht passenden inneren Adresse
Der Client sendet möglicherweise von einer Adresse, die ihm nicht zugewiesen wurde, aus einem Netz, das niemand als ihm gehörend erklärt hat, oder von einer Kopie einer Identität, die bereits einen Eigentümer hat. Alle drei erzeugen dieselbe Protokollzeile. Sie unterscheiden sich darin, was Sie ändern müssen. Beginnen Sie mit der Adresse und der aktuellen Zuweisungsliste, und lassen Sie diese beiden Fakten den Fall auswählen.
Um sie zu unterscheiden, braucht es zwei Fakten: die abgelehnte Adresse im Protokoll und die Zuweisungen, die der Server für aktuell hält. Letzteres ist in der Status- oder Verwaltungsansicht der laufenden Instanz verfügbar und die einzige maßgebliche Quelle, weil eine Konfigurationsdatei Absichten festhält und nicht den gegenwärtigen Zustand.
Notieren Sie beides, bevor Sie etwas ändern, und klassifizieren Sie dann. Ein danach aufgenommener Screenshot ist kein Beleg für den Zustand, der die Warnung erzeugte. Halten Sie auch den Zeitstempel fest, weil Zuweisungen zwischen Sitzungen wandern.
| Rejected source is | Likely cause |
|---|---|
| The client's own tunnel address | Static assignment conflict, wrong profile, or manual address change |
| A host behind that client | Missing internal ownership for that prefix |
| An address belonging to another session | Two devices sharing one identity or one static address |
Das LAN hinter einem Client und iroute
Wenn ein Standort-Client sein eigenes privates Netz routet, muss dieses Netz als zum Client gehörend erklärt werden. Eine client-spezifische Datei mit einem iroute-Eintrag tut das, und der Eintrag benennt das Präfix, das der Client transportieren darf.
Eine Kernelroute, die dasselbe Präfix auf den Tunnel zeigt, ist eine separate Anforderung, und ihr Hinzufügen ändert nichts am internen Eigentum des Daemons.
# /etc/openvpn/server/ccd/site-b
iroute 192.168.70.0 255.255.255.0Bestätigen Sie, dass die effektive Identität dem Dateinamen entspricht, denn eine Abweichung bedeutet, dass die Datei nie geladen wird, und das Symptom gleicht einem fehlenden Eintrag. Fügen Sie keine breite iroute hinzu, um die Warnung zu dämpfen, denn das macht eine unerwartete Quelle zu einer autorisierten, ohne zu beantworten, warum der Client sie gesendet hat. Das OpenVPN-2.6-Handbuch dokumentiert iroute, duplicate-cn und Identitätszuordnung als getrennte Kontrollen.
Dieselbe Identität auf zwei Rechnern
Ein auf einen zweiten Laptop kopiertes Profil trägt dasselbe Zertifikat und denselben Common Name. Je nach Servereinstellungen kann die neuere Verbindung die ältere ersetzen, und welche Instanz das Eigentum hält, gewinnt die Zuordnungsprüfung.
Dadurch wirkt der Fehler sporadisch und tritt nur auf, wenn beide Geräte wach sind.
Doppelte Common Names zuzulassen erlaubt beiden die Verbindung, gibt ihnen aber keine unabhängigen statischen Adressen oder unabhängiges Eigentum. Wenn zwei Geräte koexistieren müssen, registrieren Sie sie getrennt, damit jedes seine eigene Identität und seine eigene Zuweisung hat. Die Dubletten-Einstellung als Reparatur dieser Warnung zu behandeln lässt das Rätsel bestehen und fügt ein zweites hinzu.
Beweisen Sie, dass sich die Zuordnung geändert hat
Wenden Sie die Korrektur über den Konfigurationseigentümer an und verbinden Sie dann den betroffenen Client neu, damit die neue Richtlinie geladen wird.
Wiederholen Sie denselben Ablauf und bestätigen Sie drei Dinge: die innere Quelle des Pakets, die Client-Instanz, die der Server damit verbindet, und das Verhalten des Ziels danach.
Wenn die Warnung aufhört, die Anwendung aber weiterhin scheitert, hat sich das Problem verschoben statt verschwunden. Weiterleitung, Firewallregeln und Rückweg sind getrennte Stufen, und die Zuordnungsprüfung zu bestehen heißt nur, dass das Paket den Tunnel verlassen durfte.