Kommentare zu folgendem Beitrag: OnionHop: Tool leitet Daten durch das Tor-Netzwerk
OnionHop für Linux, macOS und Windows ist ein Routing-Manager, der die Daten einzelner oder aller Programme über das Tor-Netzwerk leitet.
Kommentare zu folgendem Beitrag: OnionHop: Tool leitet Daten durch das Tor-Netzwerk
Ich erkenne so einige Parallelen zum alten „Orbot“ (Android). Wurde mal Zeit, dass für die anderen Systeme mal was neues kommt!
Tor container via Docker, Socksify auf die Binary ansetzen, done 
Aber manchmal braucht die Welt einfach ein neues Tool, dass die Funktion eines alten Tools nochmal neu erfindet, habe ich das Gefühl.
Guten Tag!
Hier ist der Entwickler von OnionHop. Zunächst einmal vielen Dank für diesen ausführlichen Beitrag. Es ist mir eine große Ehre, auf Tarnkappe erwähnt zu werden.
Nur eine kurze Korrektur: Ich habe zwar verwandtschaftliche Verbindungen zu Robert Rudolph, mein tatsächlicher Name ist jedoch Jakob Rudolph.
Vielen Dank!
Mag ja sein, aber nur bei DuckDuckGo erscheint der Name, wohl aus einem alten Snapshot der Website. Wie kommt’s, dass du nicht mehr in Erscheinung trittst. Im Grunde ist das ja kein Recherchefehler von @Ghandy.
Da Ghandy nicht so sehr auf die Funktionsweise der Software eingegangen ist, möchte ich mal wissen, wo die Vorteile von OnionHop gegenüber der Tor CLI sind. Die Tor CLI bietet auch Pluggable Transports wie obfs4, Snowflake (mit AMP-Cache-Fronting), WebTunnel, Conjure, Meek, DNSTT und Vanilla. Also abgesehen von der einfacheren Bedienung über die GUI.
Kein Recherche Fehler, ich habe mich in der neusten Version der Website entschieden das Firm Impressum zu nehmen welches nicht meinen eigenen Namen beinhält.
Und zu deiner Frage:
Die Transports sind dieselben, die kommen ja alle aus dem Tor-Projekt. Der Unterschied ist nicht was transportiert wird, sondern was drumherum passiert.
Der Hauptpunkt ist der TUN-Modus: Die CLI gibt dir einen SOCKS-Port, und alles was nicht proxy-fähig ist oder den Proxy einfach ignoriert, läuft daran vorbei. OnionHop legt einen eigenen Adapter an und schickt das komplette System durch Tor, inklusive DNS zwingend über Tor, UDP geblockt (sonst rutscht QUIC still vorbei) und Kill Switch. Das ist der eigentliche Grund, warum es das Projekt gibt.
Das zweite ist der Umgang mit Bridges. Wir holen sie automatisch und prüfen sie vorher richtig, obfs4 mit einem echten obfs4-Handshake, WebTunnel mit einem echten WebSocket-Upgrade. Ein TCP-Connect sagt dir nämlich nichts, eine tote Bridge hinter einem lebenden CDN antwortet trotzdem brav. Ohne das sitzt du vor einer Wand aus „general SOCKS server failure“ und wartest, bis zufällig eine funktionierende drankommt.
Der Rest ist Komfort z.B. Regeln pro App oder Land, Exit festnageln.
Und tbh Wenn du mit torrc klarkommst und eh nur einen SOCKS-Port für den Browser brauchst, reicht die CLI völlig.