M
McDV
Fortgeschrittenes Mitglied
- 51
So, habe ein paar weitere Infos.
Zunächst einmal habe ich recherchiert, wie man generell NAT-Routing feststellen kann. Genutzt werden dafür die TCP-Header-Informationen, besonders die TTL, Indizien können sich aber auch aus der ID ergeben.
Dann habe ich einmal einen Packet Sniffer auf meinem rechner installiert und verschiedene TCP-Pakete von unterschiedlichen Geräten angesehen.
Android vergibt zufällige Paket-IDs und nutzt zufällige ausgehende Ports zwischen 35.000 und 55.000 (ca.). Die time to live (TTL) der Pakete beträgt anfänglich 64.
Das iPad vergibt auch zufällige IDs, allerdings scheint es die Ports hochzuzählen. Die TTL ist auch 64.
Schließlich benutzt Kubuntu10.04 hochzählende IDs, aber zufällige Ports und eine TTL von 64.
Eine Erkennung über die Ports ist ungünstig für den Provider. Einerseits wäre sie, wenn das getetherte Gerät auch zufällie Ports verwendet, nicht machbar. Andererseits sollte das NAT ohnehin die Ports umschreiben und in den dann zufälligen Bereich des N1 legen, sodass die wahren Ports verschleiert werden. Das ist ja gerade dasa Prinzip von Port forwarding.
Anders sieht es mit den Paket IDs aus. Die werden normalweise nicht umgeschrieben. Also könnte der Provider es erkennen, wenn dasa getetherte Gerät plötzlich hochzählende IDs nutzt. Das wäre aber stark vom Zufall abhängig, welches Gerät gerade angeschlossen wird. Bei meinem Beispiel wäre Kubuntu verdächtig, dasa iPad hingegen nicht. Im Endeffekt also auch nicht sehr praktikabel, da das N1 selbst keine aufsteigenden IDs, sondern zufällige nutzt.
Bleibt die time to live. Das ist wohl die ganz übliche Methode zur Erkennung. Hier kommt es erst einmal stark darauf an, wie das NAT arbeitet. Klassischerweise zählt das NAT die TTL runter. Beim Provider kämen also N1-Pakete mit einer TTL von 64 am Gateway an, während getetherte nur noch bei 63 wären. Das ist aber nicht zwingend, es gibt auch NATs, die nicht herunterzählen, also die Pakete mit derselben TTL durchleiten. In dem Fall könnte der Provider die oben genannten Geräte nicht erkennen. Allerdings nutzen Windows-Systeme wohl eine TTL von 128, nicht 64 wie bei UNIX/Linux. Ein getetherter Windows-Computer würde also sofort auffallen, selbst wenn das NAT die TTL nicht dekrementiert. Hier würde lediglich ein NAT wirken, das die TTL auf 64 umschreibt - das wird es aber vermutlich im N1 nicht tun.
Leider kann ich nicht herausfinden, was das N1 mit der TTL so macht, weil ich über 3G ausgehende Pakete nicht lesen kann. Vielleicht ist aber jemand von Euch, der ein gerootetes N1 hat (aber möglich mit weitgehend originalem ROM, bei dem die Tethering-Funktion nicht manipuliert wurde) dazu bereit, mal aus dem Market den packet sniffer zu installieren (gratis) ein ganz bisschen zu tethern und das dann über den Sniffer mitzuschneiden. Hier hochgeldaden können wir uns die Paket-Headervdann mal genauer ansehen und mit ein bisschen Glück wissen wir in Kürze genauer, was das NAT macht.
Meine Vermutung geht da dahin, dass die TTL nicht geändert wird. Das würde dann auch erklären, warum einige berichten, getetherte Handys würden nicht berechnet, ihr getetherter PC aber doch. In dem Fall würde VF vielleicht wirklich nach der TTL gehen und einfach nur eine TTL von 128 erkennen und berechnen. Das würde zwar nur Windows-Rechner erfassen, aber das ist ja die Mehrheit und es wäre super einfach. Ist abe nur Spekulation, deshalb wäre ein Test erforderlich.
Zunächst einmal habe ich recherchiert, wie man generell NAT-Routing feststellen kann. Genutzt werden dafür die TCP-Header-Informationen, besonders die TTL, Indizien können sich aber auch aus der ID ergeben.
Dann habe ich einmal einen Packet Sniffer auf meinem rechner installiert und verschiedene TCP-Pakete von unterschiedlichen Geräten angesehen.
Android vergibt zufällige Paket-IDs und nutzt zufällige ausgehende Ports zwischen 35.000 und 55.000 (ca.). Die time to live (TTL) der Pakete beträgt anfänglich 64.
Das iPad vergibt auch zufällige IDs, allerdings scheint es die Ports hochzuzählen. Die TTL ist auch 64.
Schließlich benutzt Kubuntu10.04 hochzählende IDs, aber zufällige Ports und eine TTL von 64.
Eine Erkennung über die Ports ist ungünstig für den Provider. Einerseits wäre sie, wenn das getetherte Gerät auch zufällie Ports verwendet, nicht machbar. Andererseits sollte das NAT ohnehin die Ports umschreiben und in den dann zufälligen Bereich des N1 legen, sodass die wahren Ports verschleiert werden. Das ist ja gerade dasa Prinzip von Port forwarding.
Anders sieht es mit den Paket IDs aus. Die werden normalweise nicht umgeschrieben. Also könnte der Provider es erkennen, wenn dasa getetherte Gerät plötzlich hochzählende IDs nutzt. Das wäre aber stark vom Zufall abhängig, welches Gerät gerade angeschlossen wird. Bei meinem Beispiel wäre Kubuntu verdächtig, dasa iPad hingegen nicht. Im Endeffekt also auch nicht sehr praktikabel, da das N1 selbst keine aufsteigenden IDs, sondern zufällige nutzt.
Bleibt die time to live. Das ist wohl die ganz übliche Methode zur Erkennung. Hier kommt es erst einmal stark darauf an, wie das NAT arbeitet. Klassischerweise zählt das NAT die TTL runter. Beim Provider kämen also N1-Pakete mit einer TTL von 64 am Gateway an, während getetherte nur noch bei 63 wären. Das ist aber nicht zwingend, es gibt auch NATs, die nicht herunterzählen, also die Pakete mit derselben TTL durchleiten. In dem Fall könnte der Provider die oben genannten Geräte nicht erkennen. Allerdings nutzen Windows-Systeme wohl eine TTL von 128, nicht 64 wie bei UNIX/Linux. Ein getetherter Windows-Computer würde also sofort auffallen, selbst wenn das NAT die TTL nicht dekrementiert. Hier würde lediglich ein NAT wirken, das die TTL auf 64 umschreibt - das wird es aber vermutlich im N1 nicht tun.
Leider kann ich nicht herausfinden, was das N1 mit der TTL so macht, weil ich über 3G ausgehende Pakete nicht lesen kann. Vielleicht ist aber jemand von Euch, der ein gerootetes N1 hat (aber möglich mit weitgehend originalem ROM, bei dem die Tethering-Funktion nicht manipuliert wurde) dazu bereit, mal aus dem Market den packet sniffer zu installieren (gratis) ein ganz bisschen zu tethern und das dann über den Sniffer mitzuschneiden. Hier hochgeldaden können wir uns die Paket-Headervdann mal genauer ansehen und mit ein bisschen Glück wissen wir in Kürze genauer, was das NAT macht.
Meine Vermutung geht da dahin, dass die TTL nicht geändert wird. Das würde dann auch erklären, warum einige berichten, getetherte Handys würden nicht berechnet, ihr getetherter PC aber doch. In dem Fall würde VF vielleicht wirklich nach der TTL gehen und einfach nur eine TTL von 128 erkennen und berechnen. Das würde zwar nur Windows-Rechner erfassen, aber das ist ja die Mehrheit und es wäre super einfach. Ist abe nur Spekulation, deshalb wäre ein Test erforderlich.
