☰

Szenario:

tag-icon • tag-icon linux networking routing firewall network-interface
Szenario:

Zusammenfassend

Pakete, die von einer TUN-Schnittstelle gelesen werden, finden ihren Weg nicht, wenn sie auf dieselbe TUN-Schnittstelle zurückgeschrieben werden.

Vollständig

Szenario:

Auf einer Maschine mit nur1NIC (eth0), das mit dem Internet verbunden ist. Ich habe eine Anwendung geschrieben, die IP-Pakete von der TUN-Schnittstelle liest. Dann kann sie:

  • Schreiben Sie das Paket ohne Änderungen zurück auf die gleiche TUN-Schnittstelle
  • Paket blockieren
  • Nehmen Sie Änderungen am Paket vor (z. B. verschlüsseln Sie die Nutzlast) und schreiben Sie das manipulierte Paket zurück an die TUN-Schnittstelle.

Erledigt:

Ich habe die folgenden Schritte ausgeführt:

  1. Ich führe mein Programm aus. Es weist das TUN-Gerät zu, instanziiert es und wartet, bis das Gerät hochgefahren wird.

  2. Dann führe ich die folgenden Befehle aus:

    ifconfig tun0 up ifconfig tun0 10.0.0.2 route add -net 0.0.0.0 netmask 0.0.0.0 dev tun0 echo 1 > /proc/sys/net/ipv4/ip_forward

  3. Jetzt beginnt mein Programm erfolgreich, Pakete zu lesen (und druckt/protokolliert deren Inhalt).

  4. Mein Programm schreibt das Paket zurückohne jede Änderungzurück zum tun0-Gerät

PROBLEM:

Zurückgeschriebenes Paket findet seinen Weg zurück nicht, um beispielsweise zu eth0 oder zur Anwendungsschicht zu gelangen. Wenn ich beispielsweise einen Ping ausführe:

ping 4.2.2.4

und auf einem anderen Terminal:

tshark -i tun0

Ich sehe, dass tun0 das ICMP-Echopaket sieht (auch mein Programm):

 10.0.0.2 → 4.2.2.4      ICMP 84 Echo (ping) request  id=0x14b1, seq=2/512, ttl=64
 10.0.0.2 → 4.2.2.4      ICMP 84 Echo (ping) request  id=0x14b1, seq=3/768, ttl=64
 10.0.0.2 → 4.2.2.4      ICMP 84 Unknown ICMP (obsolete or malformed?)

Mein Programm schreibt das Paket zurück an tun0 und tsharksieht es (im obigen Snippet)

Die ICMP-Anfrage erreicht jedoch nichteth0damit es seinen Weg dorthin finden kann 4.2.2.4. Meiner Meinung nach gibt es ein Problem mit den Routing-Regeln, aber ich konnte nicht herausfinden, wie ich es ändern kann.

Jeder Kommentar ist willkommen, Grüße

Antwort1

natürlich gibt es ein Problem mit den Routing-Regeln, Sie haben dem Kernel gesagt, dass er alle Pakete über tun0:) weiterleiten soll. Wenn Sie das Paket zurücksenden tun0, wird es wieder über weitergeleitet tun0, nicht über eth0. Allerdings klingt es so, als ob das Paket in Ihrem Fall aufgrund eines „Reverse Path Filters“ verworfen wird, d. h. es weigert sich, Pakete über dieselbe Schnittstelle zurückzusenden, über die sie eingegangen sind.

verwandte Informationen