Sieht der Peer meine echte IP (Leak)

[sonnytricky]

Kurz: Ja — mit deinem aktuellen Setup wird das normalerweise verhindert, aber nur wenn ein paar Voraussetzungen erfüllt sind. Ich erkläre kurz warum, was du prüfen solltest und welche zusätzlichen Maßnahmen / Tests du sofort machen kannst, damit wirklich kein Peer deine echte IP erreicht.

---

1) Warum dein Setup das grundsätzlich verhindert

• ⚠️ TODO

Dein Skript macht die richtigen Dinge:

• Default‑DROP + Killswitch (iptables -A OUTPUT -o "$EXT_IF" -j DROP) → keine ausgehenden Verbindungen über das externe Interface, außer die zuvor explizit erlaubten.
• Du blockierst eingehende Verbindungsversuche auf typischen Torrent‑Ports am externen Interface:

iptables -A INPUT -i "$EXT_IF" -p tcp --dport 6881:6999 -m conntrack --ctstate NEW -j DROP
iptables -A INPUT -i "$EXT_IF" -p udp --dport 6881:6999 -m conntrack --ctstate NEW -j DROP
iptables -A INPUT -i "$EXT_IF" -p udp --dport 51413 -m conntrack --ctstate NEW -j DROP
iptables -A INPUT -i "$EXT_IF" -p tcp --dport 51413 -m conntrack --ctstate NEW -j DROP

→ Das verhindert, dass jemand von außen eine neue Verbindung zu einem auf diesen Ports lauschen‑den Service (auf dem Host/Host‑Interface) herstellen kann.

• Docker‑Isolation: DOCKER-USER Regeln + FORWARD‑Regeln in deinem Skript verhindern, dass Container direkt über EXT_IF senden.

Zusammen: Peers außerhalb sehen normalerweise nur die VPN‑Exit‑IP und können dich nicht direkt über deine echte IP erreichen.

---

2) Aber: wovon hängt das ab? (Risiken / Fallen)

Damit kein Leak passiert, müssen folgende Voraussetzungen erfüllt sein:

1. Torrent‑Client läuft wirklich nur im VPN‑Netz
   → network_mode: "service:vpn" oder bind an wg0 / VPN‑IP. Wenn der Client im Host‑Netz läuft oder network_mode: host, leakt er.
   Prüfen:

• ⚠️ TODO

  docker inspect -f '{{.HostConfig.NetworkMode}}' qbittorrent

2. Keine Port‑Publishes (-p / ports:...) in Docker‑Compose für diese Services. Sonst lauscht Docker/Host auf EXT_IF.
   Prüfen: docker-compose.yml oder docker ps --format '{{.Names}} {{.Ports}}'

• ⚠️ TODO

3. Keine Router‑Portforwarding / UPnP, die Ports auf deinen Host weiterleiten. Selbst wenn Host firewalled ist, manche Router-Verhalten/ALG können problematisch sein. Prüfen & UPnP deaktivieren.

• ⚠️ TODO

4. DOCKER-USER Chain muss wirklich wirksam sein und früh greifen. Docker fügt seine eigenen FORWARD‑Regeln später — DOCKER-USER wird von Docker vor dessen Regeln ausgeführt (gut), aber deine Regeln müssen mit -I eingefügt werden, damit sie sehr früh greifen.

• ⚠️ TODO

5. Keine Host‑Listener: Wenn ein Prozess auf dem Host (nicht in Container) lauscht auf Torrent‑Ports, kann er erreichbar sein. Prüfen:

• ⚠️ TODO

  ss -tunlp | egrep '6881|51413'

6. IPv6: muss wirklich deaktiviert sein (du hast das getan). Sonst können Verbindungen über IPv6 erfolgen.

• ⚠️ TODO

---

3) Sofort‑Checks (einfach kopieren und ausführen)

Prüfe, ob jemand deine echte IP erreichen könnte:

1. Sind die Container im VPN‑Netz?

• ⚠️ TODO

docker inspect -f '{{.Name}} {{.HostConfig.NetworkMode}}' qbittorrent jackett

2. Hört etwas auf Torrent‑Ports am Host?

• ⚠️ TODO

ss -tunlp | egrep '6881|51413' || echo "Keine Listener auf Torrent-Ports"

3. Zeigt Docker published ports?

• ⚠️ TODO

docker ps --format '{{.Names}}\t{{.Ports}}'

4. DOCKER-USER vorhanden & Regeln?

• ⚠️ TODO

iptables -L DOCKER-USER -n -v || echo "DOCKER-USER fehlt"
iptables -L FORWARD -n -v | egrep 'docker0|br-' || true

5. Router/UPnP prüfen (lokal):

• ⚠️ TODO

# quick UPnP probe (wenn upnpc installiert)
upnpc -l 2>/dev/null || echo "kein upnpc"
# oder prüfe fritzbox Portfreigaben manuell in UI

6. Externer Portscan (von außerhalb) gegen deine öffentliche IP:

• ⚠️ TODO

# auf einem anderen Host / VPS ausführen
nmap -Pn -p 6881,51413 <deine_public_ip>

---

4) Zusätzliche robuste Maßnahmen (Empfehlung, falls du maximal sicher sein willst)

• Explizit NEW‑INPUT für Torrent‑Ports DROP (du hast es schon). Optional: weiter unten -I statt -A um sicherzustellen Regelposition:

• ⚠️ TODO

iptables -I INPUT 1 -i "$EXT_IF" -p tcp --dport 6881:6999 -m conntrack --ctstate NEW -j DROP
iptables -I INPUT 1 -i "$EXT_IF" -p udp --dport 6881:6999 -m conntrack --ctstate NEW -j DROP

• Verstärke DOCKER-USER: setze Drop‑Regeln ganz oben in DOCKER-USER:

• ⚠️ TODO

iptables -I DOCKER-USER -i docker0 -o "$EXT_IF" -j DROP
iptables -I DOCKER-USER -i br-+ -o "$EXT_IF" -j DROP  # für alle bridge-interfaces

• Blockiere FORWARD vom docker-bridge→EXT_IF (du hast REPJECT, gut). Nutze -I um sicher zu sein:

• ⚠️ TODO

iptables -I FORWARD 1 -i docker0 -o "$EXT_IF" -j REJECT
iptables -I FORWARD 1 -o docker0 -i "$EXT_IF" -j REJECT

• Deaktiviere UPnP/NAT‑PMP auf Fritzbox & Host.

• ⚠️ TODO

• Stoppe Torrent‑Container beim VPN‑Down (du hast Watchdog, gut) und verhindere Autostart der Torrent-Container beim Systemstart, bis VPN bestätigt verbunden ist (oder nutze depends_on: condition: service_healthy und healthcheck).

• Kein network_mode: host verwenden.

---

5) Falls trotzdem Leak — mögliche Ursachen & wie du sie findest

• Container laufen nicht im VPN‑Netz → docker inspect check.
• Published port existiert → docker ps zeigt 0.0.0.0:51413->51413/tcp.
• Router/UPnP hat Port‑Forward angelegt → prüfe Fritzbox.
• Host‑Listener auf Port vorhanden → ss -tunlp.
• IPv6 aktiv → curl -6 https://ifconfig.co prüfen.

---

6) Fazit (konkret)

Mit deinem Firewall‑Skript und deiner Docker‑Konfiguration (network_mode: "service:vpn") plus:

• keine published ports,
• UPnP/Port‑forwarding im Router deaktiviert,
• DOCKER-USER Regeln aktiv,
• Watchdog stoppt Torrent‑Container beim VPN‑Ausfall,

wird ein Peer keine TCP/UDP‑Verbindung zu einem Torrent‑Port über dein externes Interface herstellen können — ergo kein Leak deiner echten IP.

Wenn du willst, mache ich dir jetzt 1) ein kleines Prüfskript, das alle oben genannten Checks automatisiert ausführt, oder 2) füge die stärkeren iptables -I Regeln in dein setup_firewall.sh ein und zeige dir genau, wie du docker-compose-Publishes findest/entfernst. Welche Option willst du?