Warum sendet mein TUN-Gerät kein UDP / IP an 192.168.2.x?

481
Minix

Ich habe ein TUN-Gerät auf meinem Host-Computer mit diesem Skript eingerichtet:

echo 1 > /proc/sys/net/ipv4/ip_forward  #do NAT on packets from our 'local' net iptables -t nat --flush POSTROUTING iptables -t nat -A POSTROUTING -s 10.0.0.0/8 -o eth0 -j MASQUERADE  #initialise the tun device (tun0) ip tuntap add dev tun0 mode tun  #give the tun device IP 10.0.0.1 ifconfig tun0 10.0.0.1 netmask 255.255.255.0 up  #disable IPv6 on tun device sysctl net.ipv6.conf.tun0.disable_ipv6=1  #some firewall rules iptables -A INPUT -i tun0 -d 127.0.0.0/8 -j DROP

Ich versuche, UDP-Pakete von meinem Host-Computer über WLAN an meinen Laptop zu senden. Die an das TUN-Gerät angeschlossene Anwendung ist eine Serveranwendung, die ein ähnliches Protokoll wie SOCKS5 verwendet, um formatierte TCP-Pakete zu übernehmen, UDP / IP-Pakete zu konstruieren und sie an eine angegebene Adresse mit einer festgelegten src-IP-Adresse zu senden (aus irgendeinem Grund).

Das Senden von UDP-Paketen über das TUN mit einer SRC-Adresse von 10.0.0.2 funktioniert einwandfrei. Ich kann es durch Ändern der Netzmaske auf 10.0.0.0/8 bringen, aber wenn ich die IP-Adresse des IP-Pakets src (!) Setze, möchte ich das TUN-Gerät an 192.168.2.112 senden (die tatsächliche IP meines Hosts)., das TUN-Gerät wird es abholen, aber es wird nicht auf meinem Laptop empfangen. Die Verwendung von Python zum Senden eines UDP-Datagramms funktioniert normalerweise wie erwartet und die korrekte src-IP-Adresse wird auf meinem Laptop gelesen. Das TUN-Gerät sendet die erstellten Pakete, wenn die src-IP-Adresse im Bereich 10.0.0.0/8 liegt, nicht aber bei 192. *.

Die iptables sind auf beiden Computern leer, bevor das Skript verwendet wird. Was vermisse ich?

/proc/sys/net/ipv4/conf/all/rp_filter: 1 /proc/sys/net/ipv4/conf/default/rp_filter: 1 /proc/sys/net/ipv4/conf/enp0s31f6/rp_filter: 1 /proc/sys/net/ipv4/conf/lo/rp_filter: 0 /proc/sys/net/ipv4/conf/tun0/rp_filter: 1 /proc/sys/net/ipv4/conf/wlp4s0/rp_filter: 1 /proc/sys/net/ipv4/conf/wwp0s20f0u3c2/rp_filter:1
0
Wird dieses Skript auf Ihrem Laptop oder einem anderen Computer ausgeführt? Welche Software ist an das andere Ende des Tun-Geräts angeschlossen? Was sind die Werte von `/ proc / sys / net / ipv4 / conf / * / rp_filter`? grawity vor 6 Jahren 0
@grawity Ich habe meine Frage aktualisiert. Minix vor 6 Jahren 0

1 Antwort auf die Frage

1
dirkt

Zur Wiederholung erzeugt Ihre Anwendung ein Paket mit einer Quelladresse, legt es in die Tuning-Schnittstelle, leitet es von Ihrem Host-Computer weiter, maskiert es eth0und von eth0 aus wird es auf mysteriöse Weise über WLAN an Ihren Laptop gesendet. Dies funktioniert für 10.0.0.2 als Quelle, aber nicht für 192.168.2.112.

Doch in der Realität, Sie haben keine eth0Schnittstelle, aber die Schnittstellen sind enp0s31f6, wlp4s0und wwp0s20f0u3c2.

Ist das richtig?

Wenn ja, besteht der wahrscheinliche Schuldige darin, dass Sie sich statt auf der WLAN-Schnittstelle eth0maskieren müssen, und Sie müssen sich für alle Quelladressen maskieren, nicht nur für 10.0.0.0/8. Die eigentliche Frage ist, wie es für 10.0.0.2 an erster Stelle funktioniert hat, aber das wird wahrscheinlich durch den Teil Ihrer Konfiguration erklärt, den Sie uns nicht mitgeteilt haben.

Sie müssen sich wahrscheinlich unter WLAN maskieren, da Sie andernfalls Routen im anderen Teil Ihres Netzwerks festlegen müssen.

Tools zum Debuggen: ip route get 1.2.3.4zum Überprüfen von Routen tcpdump -ni wlp4s0usw. an allen Schnittstellen, die möglicherweise interessant sind, um zu sehen, wo die Pakete tatsächlich hingelangen.

Ich habe mit dem Skript gearbeitet. Irgendwann habe ich "eth0" in "wlp4so" geändert, bin aber nicht sicher, wie viel ich sonst geändert habe. Ich werde prüfen, was Sie vorgeschlagen haben, wenn ich wieder zu Hause bin. Ich bin mir nicht sicher, welchen Teil der Konfiguration ich außer dem Quellcode der beteiligten Programme zurückhalte. Minix vor 6 Jahren 0
Wenn bei wlp4so Maskerade aktiv war, als es funktionierte, dann sollte es das sein. Was Sie wahrscheinlich wollen, ist eine Regel, die alles, was von "tun" kommt, zu "wlp4so" maskiert, egal welche Quelladresse. Abhängig von der Standardrichtlinie müssen Sie möglicherweise auch die umgekehrte Richtung für vorhandene Verbindungen akzeptieren. Ein sauberes Beispiel finden Sie unter [hier] (https://www.revsys.com/writings/quicktips/nat.html). dirkt vor 6 Jahren 0
Es scheint, dass ich die falsche Zeile zur falschen Zeit geändert habe und nicht die richtige Kombination erhalten habe. Nachdem Sie die Schnittstelle in "wlp4so" geändert haben und die src-IP auf "10.0.0.2" behalten, funktioniert es jetzt. Danke vielmals. Ich lernte dabei ein wenig über NAT und `iptables`. Minix vor 6 Jahren 0

Verwandte Probleme