imsnif/bandwhich

Traffic misidentification on routing host

Open

#447 opened on 2024年12月6日

GitHub で見る
 (0 comments) (0 reactions) (0 assignees)Rust (7,686 stars) (237 forks)batch import
bughelp wanted

説明

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.

コントリビューターガイド

技術スタック
rust
領域
cliobservability
Issue 種別
bug
難度新しい貢献者にとっての実装難度です。1 は非常に小さな変更、5 は専門的な作業です。
3
推定時間経験ある貢献者が調査、実装、テスト、pull request 準備にかけるおおよその時間範囲です。
1-2 days
活動状況Issue が今どれだけ取り組みやすいかを示します。新しい、活発、古い、ブロック中、またはメンテナー入力待ちなどです。
fresh
明確さ期待される変更、受け入れ条件、次の手順がどれだけ明確かを示します。
needs investigation
前提条件
Rustnetworking concepts
初心者向け度初回貢献者にどれだけ取り組みやすいかを 1-100 で推定したスコアです。
35
調査方針
Investigate the issue by reproducing the described scenario with three machines and scp transfer. Examine the Rust code in the repository that handles traffic identification and connection tracking, particularly how it maps IP addresses and ports to processes. Look for any assumptions about routing that might cause misidentification when traffic traverses a VPN. The user provided clues; compare the expected behavior with the actual output to pinpoint where the logic fails. Check if there are any existing tests for multi homed hosts or VPN scenarios.