imsnif/bandwhich

Traffic misidentification on routing host

Open

#447 geöffnet am 6. Dez. 2024

Auf GitHub ansehen
 (0 Kommentare) (0 Reaktionen) (0 zugewiesene Personen)Rust (237 Forks)batch import
bughelp wanted

Repository-Metriken

Stars
 (7.686 Stars)
PR-Merge-Metriken
 (Keine gemergten PRs in 30 T)

Beschreibung

Three machines are involved here:

  • My personal laptop A, connected to the local network (green).
  • The server S that routes traffic between the local network and the OpenVPN subnet, on which bandwhich is running.
    • S has two addresses - a local network address Slocal and an OpenVPN subnet address Svpn.
  • A remote client machine B connected to the OpenVPN subnet (cyan).
    • B has two addresses - a public address Bpub and an OpenVPN subnet address Bvpn.

Misidentified traffic

Here I am initiating a file transfer on A using scp from A to Bvpn, so on layer 4 the connection should be from A:56994 to Bvpn:22.

But bandwhich seems to believe that it's from A:56994 to Slocal:22 instead, and by extension believes that this traffic should be attributed to the local sshd process.

I think I've got some clues on what's wrong. Help welcomed nonetheless.

Contributor Guide

Research-Richtung
Untersuche das Problem, indem du das beschriebene Szenario mit drei Maschinen und scp Übertragung reproduzierst. Überprüfe den Rust Code im Repository, der die Verkehrsidentifikation und Verbindungsverfolgung behandelt, insbesondere wie er IP Adressen und Ports Prozessen zuordnet. Suche nach Annahmen über das Routing, die zu Fehlidentifikation führen könnten, wenn Verkehr über ein VPN geleitet wird. Der Benutzer hat Hinweise gegeben; vergleiche das erwartete Verhalten mit der tatsächlichen Ausgabe, um zu ermitteln, wo die Logik versagt. Prüfe, ob es bereits Tests für Multi Homed Hosts oder VPN Szenarien gibt.
Tech Stack
rust
Domain
cli
Issue Type
Fehler
SchwierigkeitGeschätzte Implementierungsschwierigkeit für neue Contributors, von 1 für sehr kleine Änderungen bis 5 für Expertenarbeit.
3
Geschätzte ZeitEin grober Zeitrahmen, um zu recherchieren, zu implementieren, zu testen und einen Pull Request vorzubereiten.
1-2 Tage
AktivitätsstatusWie verfügbar das Issue gerade wirkt: frisch, aktiv, stale, blockiert oder wartet auf Maintainer-Input.
Aktiv
KlarheitWie klar das Issue die erwartete Änderung, Akzeptanzkriterien und den nächsten Schritt erklärt.
Klar
Voraussetzungen
Rust
EinsteigerfreundlichkeitEin Score von 1 bis 100, der schätzt, wie zugänglich dieses Issue für First-Time Contributors ist.
50