Wenn ich richtig vermute, schickt die Software eine gewisse Anzahl präparierter Anfrage- und Antwortpakete von beiden hosts gleichzeitig in Richtung des anderen los, so dass ein Antwortpaket des einen hosts auf das Anfragepaket des anderen scheinbar antwortet. Das würde bedeuten, dass die Pakete das NAT zwar voll mitmachen, aber eine Verbindung zustande kommt, die sonst nie zustande gekommen wäre. Das Vorgehen ist zwar clever, dürfte aber für p2p zu aufwändig sein, was das timing betrifft. Ausserdem müssten Netzwerkdetails beider Seiten bekannt sein. Falls ich mich irre, lieber Autor, wie funktionierts ? :)
Solange alle Adressen (Router und Hosts) bekannt und auf beiden Hosts richtig konfiguriert sind, und ausserdem die Software zu etwa der gleichen Zeit auf beiden Hosts gestartet wird, müsste es eigentlich egal sein wo die Hosts die Adressen her haben und auf welche Weise sie vergeben wurden.
Von Ingo Blechschmidt am Do, 14. Juli 2005 um 14:08 #
Genau. Man kann über die Optionen --timeout und --window (Anzahl am Anfang zu versendender Müllpakete) das Verhalten von nat-traverse noch ein bisschen anpassen, falls die Standard-Einstellugen nicht funktionieren sollten. Das kann z.B. sein, wenn viele UDP-Pakete nicht durchkommen -- dann kann einfach --window erhöhen und gut ist (entscheidend ist für nat-traverse dabei BTW nur der Anfang -- wenn die Verbindung erst einmal aufgebaut ist, läuft nat-traverse nicht einmal mehr).
Feste IP-Adressen braucht man nicht, jedoch wird die Verbindung wohl zusammenbrechen, wenn sich die Adressen der beteiligten Rechner ändern. Wenn man allerdings den pppd über nat-traverse laufen lässt, könnte man z.B. einen Cron-Job einrichten, der alle n Minuten überprüft, ob der Tunnel noch steht, und sonst nat-traverse neustartet.
"Anwendungen müssen dabei, wie bei PPP üblich, nichts vom Tunnel oder nat-traverse wissen. Liefe also zum Beispiel ein Webserver auf rechts, könnte man diesen über http://10.0.0.2/ von links aus erreichen."
Warum sollte nicht auf "rechts" ein SSHD laufen, oder ein VPN-Server.. oder was auch immer?
Nö, isses nich. Aber darüber kannst du dann mit was-auch-immer-du-magst einen sicheren Tunnel fahren... OpenVPN oder what ever. Dieses Tool hilft dir ja ersma nur überhaupt dateien von Host A zu Host B zu schaffen was ja wegen NAT sonst net geht.
Und VPN muss ja net unbedingt secure sein, das hat ja erstmal was mit virtuell und so zu tun, net unbedingt mit verschluesselt...
"Nö, isses nich. Aber darüber kannst du dann mit was-auch-immer-du-magst einen sicheren Tunnel fahren... OpenVPN oder what ever. Dieses Tool hilft dir ja ersma nur überhaupt dateien von Host A zu Host B zu schaffen was ja wegen NAT sonst net geht."
Eben
"Und VPN muss ja net unbedingt secure sein, das hat ja erstmal was mit virtuell und so zu tun, net unbedingt mit verschluesselt..."
Jein, verschlüsselt sind sie irgendwie schon alle. VPNs sind ja im Prinzip dazu da eine private Netzwerktopologie vorzugaukeln, obwohl die Verbindung u.U. über das halbe Internet geroutet wird. Damit das private Netzwerk auch privat ist, darf natürlich nicht jeder mitlesen, also wird entweder die Nutzlast der Netzwerkpakete des privaten Netzwerkes verschlüsselt, oder die kompletten Pakete werden verschlüsselt und neu verpackt versendet.
"Nun möchte man aber eine direkte Verbindung zwischen zwei Computern aufbauen, die beide hinter NAT-Gateways sitzen. Wenn zumindest einer der Rechner eine öffentliche IP-Adresse hätte, könnte man einfach SSH einsetzen, um einen Tunnel aufzubauen. Sitzen jedoch beide Computer hinter NAT-Gateways, ist man bei SSH auf einen vermittelnden Server mit öffentlicher IP-Adresse angewiesen."
Ich brauche doch nicht des anderen öffentliche IP, sondern richte mir einen speziellen port für machine xyz ein und forwarde den z.B. 4500. Maschine a baut dann nen SSH Tunnel auf über NAT Router x der zu Rechner b forwarded und ich hab meinen Tunnel, so mach ich das zumindestens. Und das Problem mit dynmischen IPs ist auch keins, kann ja bei den Routern dynamische Ips reservieren für bestimmte clients.
In dem obigen Beispiel muss ich ja zuerst mal auf beiden Rechnern das Skript starten, also wie mache ich das, wenn ich mich noch nicht mal mit dem einen Verbinden kann, weil der Router keinen Port forewarded z.B. SSH.
Von Ingo Blechschmidt am Do, 14. Juli 2005 um 13:56 #
Ja, wenn du Kontrolle über die Port-Forwarding-Einstellungen eines Routers hast, ist nat-traverse hinfällig.
Allerdings gibt es oftmals Situationen, in denen man die Router-Konfigurationen nicht ändern kann/will/darf, und dann kann man nat-traverse einsetzen, um trotzdem durch die NAT-Gateways zu kommen.
Ah okay jetzt verstehe ich den Sinn und da fällt mir auch ein Netz ein bei ich was ähnliches am laufen habe. Ich hab einfach ein Programm, das von dem Netz einen Tunnel aufbaut und zu meiner Mascine hält, von dem ich normalerweise nicht die Möglichkeit die Firewall oder Router zu konfigurieren :-)
Ich denke, dass es relativ selten ist, dass man zwei Rechner hat, die über NAT im Netz sind und man bei beiden die Router nicht anpassen kann, aber ich galube ich guck mir netraverse mal näher an.
Von Ingo Blechschmidt am Do, 14. Juli 2005 um 14:01 #
Es gibt ein paar Bedingungen, damit das ganze funktioniert.
Zum einen müssen natürlich UDP-Pakete generell durchgelassen werden, klar. (Ansonsten könnte man evtl. nat-traverse so modifizieren, dass es ICMP- statt UDP-Paketen nimmt, aber das wäre ein bisschen komplizierter.)
Dann können noch einzelne Firewall-Regeln das Ganze blockieren, z.B. Limits, dass nur n UDP-Pakete alle m Sekunden durchgelassen werden oder so.
Schließlich müssen noch die Router UDP-Pakete auch durchleiten bzw. "richtig" NATten, aber all diese Bedingungen sind in der Praxis ja meistens erfüllt. :)
Oag, dass das so einfach funktioniert, aber irgendwie logisch.
Da drängt sich jetzt mir die Frage auf: Wie lange bleibt eine solche Verbindung durch die Firewall als "aktiv" gespeichert? Gerade bei UDP, das ja connectionless ist, kann ich mir nur einen Timeout vorstellen, der die rück-NAT-Regel wieder löscht.
Und noch eine Frage: nat-traverse funktioniert sowohl bei stateless wie bei statefull/conntrack Firewalls, oder?
Von Ingo Blechschmidt am Do, 14. Juli 2005 um 21:53 #
Ja, genau, nach einem bestimmten Timeout wird die entsprechende Regel wieder gelöscht. Abhilfe ist natürlich einfach, einfach alle n Sekunden paar Pings 'rüberschicken.
Zu deiner zweiten Frage, beide Router müssen halt die Antwortpakete korrekt durchleiten -- wenn ich nat-traverse die Tunnelspezifikation p1:B:p2 mitgebe, erwartet nat-traverse die Antwort-Pakete natürlich auf p1, gesendet von p2. Wenn's nicht klappt, sind tcpdump und ethereal wertvolle Helfer.
BTW, nur so als Erfahrungswert: Ich habe hier nat-traverse mit drei verschiedenen Routern testen können, davon haben zwei funktioniert, und der eine, der nicht funktionierte, blockt *alle* UDP-Pakete nach außen. Versuch's also einfach, die Chancen stehen gut =)
... ist das Ganze aus sicherhetistechnischer Sicht auf alle Fälle. Ihr wollt ein unbekanntes Ninary ausführen, um ein Loch in euer NAT-Gateway zu bohren? Wenn ich das richtig verstanden habe ist doch in dem tarball nur ein Binary. Oder sind da auch die Sourcen dabei? Und was wird wohl der Admin in der Firma zu sowas sagen? Und erst die firmeninterne Sicherheitspolicy?
Von Ingo Blechschmidt am Do, 14. Juli 2005 um 22:03 #
Die Möglichkeit, Perl-Programm wirklich gut kompilieren zu können, gibt es erst ab Perl 6 (z.B. über Pugs). nat-traverse ist aber noch in Perl 5 geschrieben, also, und das hättest du gesehen, wenn du den Tarball heruntergeladen hättest ;), liegt nat-traverse *ausschließlich* als Source vor -- mit Dokumentation 377 Zeilen, die kannst also relativ schnell durchlesen, wenn dich das interessiert :)
Und ja, wenn die Firmenpolicy das ganze verbietet, sollte man nat-traverse natürlich nicht benutzen. Genauso wenig wie alle anderen denkbaren Tunnel-Mechanismen (Proxyketten [PDF], Data-over-DNS [PDF], IPv6-in-IPv4 [PDF], und noch viele weitere (BTW, im aktuellen Linux-Magazin wird auch ein Tunnel-Mechanismus vorgestellt, PPP-über-TCP IIRC)).
Ich nutze hier nat-traverse u.a., um einen Tunnel zu einem Freund aufzubauen, der einen Router besitzt, der nur zehn Ports weiterleiten kann, und von denen diese zehn Ports schon benutzt werden.
Oder vielleicht willst du schnell irgendwas zu einem anderen Rechner, der dir gehört, kopieren, und du hast vielleicht sogar Zugriff auf die Routerkonfigurationen? Mit nat-traverse musst du nicht deine Firewalls umkonfigurieren, deine Sachen übertragen, und dann die Konfiguration wieder zurücksetzen. :)
"Die Möglichkeit, Perl-Programm wirklich gut kompilieren zu können, gibt es erst ab Perl 6 "
Hmmmm also ich hab schon einige Perlscripte kompiliert mit Perl 5 und da gabs nie Probleme, nun gut es waren fast keine uses drin, aber die Frage ist eher was würde man damit gewinnen, kompilierte Perlscripte sind in der Regel nicht schneller, macnhmal sogar langsamer
Von Ingo BLechschmidt am Fr, 15. Juli 2005 um 08:04 #
Hast schon Recht, Autrijus Tang's exzellentes PAR-Modul ist wirklich cool. Allerdings funktioniert es *manchmal* nicht (aber man darf Autrijus da wirklich keinen Vorwurf machen, die Ursache liegt bei Perl 5 und nicht bei ihm).
Und du hast auch mit deiner zweiten Aussage z.T. recht, solange du dich auf Perl 5 beziehst. Perl 6 allerdings sieht Kompilierung als Standard vor. Du kannst auch mal einen ganz einfachen Benchmark ausführen: Hole dir Pugs und messe die Zeit von pugs examples/mandel.p6. Und dann miss die Zeit, wenn du das Teil erst kompilierst (pugs -CPIR examples/mandel.p6 > mandel.pir) und dann startest (parrot mandel.pir).
Von Ingo Blechschmidt am So, 1. April 2018 um 18:50 #
Hey zeldor,
wow, dass dieser uralte Artikel nach so langer Zeit kommentiert wird! Ein aktueller Tarball ist unter https://www.speicherleck.de/iblech/nat-traverse/ zu finden.
Hätte nicht gedacht, dass das so ohne weiteres geht! Gleich mal schauen, wie das funktioniert....
Warum machen p2p-Programme wie z.B. bittorrent das nicht?
Wolfgang
Falls ich mich irre, lieber Autor, wie funktionierts ? :)
Gruss Winston84
./nat-traverse 60001:HierDieEchte-IP-vomRouter?:60002
Wnston84
Feste IP-Adressen braucht man nicht, jedoch wird die Verbindung wohl zusammenbrechen, wenn sich die Adressen der beteiligten Rechner ändern. Wenn man allerdings den pppd über nat-traverse laufen lässt, könnte man z.B. einen Cron-Job einrichten, der alle n Minuten überprüft, ob der Tunnel noch steht, und sonst nat-traverse neustartet.
--Ingo
( ok, man kann ja nacher ein ssh drüberlegen.. )
Winston84
Grüße,
Gunter
Warum sollte nicht auf "rechts" ein SSHD laufen, oder ein VPN-Server.. oder was auch immer?
Gruss Winston84
Warum nicht VPN und dann SSH
OpenVPN oder what ever.
Dieses Tool hilft dir ja ersma nur überhaupt dateien von Host A zu Host B zu schaffen was ja wegen NAT sonst net geht.
Und VPN muss ja net unbedingt secure sein, das hat ja erstmal was mit virtuell und so zu tun, net unbedingt mit verschluesselt...
OpenVPN oder what ever.
Dieses Tool hilft dir ja ersma nur überhaupt dateien von Host A zu Host B zu schaffen was ja wegen NAT sonst net geht."
Eben
"Und VPN muss ja net unbedingt secure sein, das hat ja erstmal was mit virtuell und so zu tun, net unbedingt mit verschluesselt..."
Jein, verschlüsselt sind sie irgendwie schon alle. VPNs sind ja im Prinzip dazu da eine private Netzwerktopologie vorzugaukeln, obwohl die Verbindung u.U. über das halbe Internet geroutet wird. Damit das private Netzwerk auch privat ist, darf natürlich nicht jeder mitlesen, also wird entweder die Nutzlast der Netzwerkpakete des privaten Netzwerkes verschlüsselt, oder die kompletten Pakete werden verschlüsselt und neu verpackt versendet.
Gruss Winston84
Ich brauche doch nicht des anderen öffentliche IP, sondern richte mir einen speziellen port für machine xyz ein und forwarde den z.B. 4500.
Maschine a baut dann nen SSH Tunnel auf über NAT Router x der zu Rechner b forwarded und ich hab meinen Tunnel, so mach ich das zumindestens. Und das Problem mit dynmischen IPs ist auch keins, kann ja bei den Routern dynamische Ips reservieren für bestimmte clients.
In dem obigen Beispiel muss ich ja zuerst mal auf beiden Rechnern das Skript starten, also wie mache ich das, wenn ich mich noch nicht mal mit dem einen Verbinden kann, weil der Router keinen Port forewarded z.B. SSH.
Irgendwie sehe ich nicht den Sinn in dem ganzen.
Allerdings gibt es oftmals Situationen, in denen man die Router-Konfigurationen nicht ändern kann/will/darf, und dann kann man nat-traverse einsetzen, um trotzdem durch die NAT-Gateways zu kommen.
--Ingo
Ich denke, dass es relativ selten ist, dass man zwei Rechner hat, die über NAT im Netz sind und man bei beiden die Router nicht anpassen kann, aber ich galube ich guck mir netraverse mal näher an.
Glaub aber ich habs von der Homepage verstanden.
Geht das bei allen Routern?
Allo
Zum einen müssen natürlich UDP-Pakete generell durchgelassen werden, klar. (Ansonsten könnte man evtl. nat-traverse so modifizieren, dass es ICMP- statt UDP-Paketen nimmt, aber das wäre ein bisschen komplizierter.)
Dann können noch einzelne Firewall-Regeln das Ganze blockieren, z.B. Limits, dass nur n UDP-Pakete alle m Sekunden durchgelassen werden oder so.
Schließlich müssen noch die Router UDP-Pakete auch durchleiten bzw. "richtig" NATten, aber all diese Bedingungen sind in der Praxis ja meistens erfüllt. :)
--Ingo
Oag, dass das so einfach funktioniert, aber irgendwie logisch.
Da drängt sich jetzt mir die Frage auf: Wie lange bleibt eine solche Verbindung durch die Firewall als "aktiv" gespeichert? Gerade bei UDP, das ja connectionless ist, kann ich mir nur einen Timeout vorstellen, der die rück-NAT-Regel wieder löscht.
Und noch eine Frage: nat-traverse funktioniert sowohl bei stateless wie bei statefull/conntrack Firewalls, oder?
Bye
Hansi
Zu deiner zweiten Frage, beide Router müssen halt die Antwortpakete korrekt durchleiten -- wenn ich nat-traverse die Tunnelspezifikation p1:B:p2 mitgebe, erwartet nat-traverse die Antwort-Pakete natürlich auf p1, gesendet von p2. Wenn's nicht klappt, sind tcpdump und ethereal wertvolle Helfer.
BTW, nur so als Erfahrungswert: Ich habe hier nat-traverse mit drei verschiedenen Routern testen können, davon haben zwei funktioniert, und der eine, der nicht funktionierte, blockt *alle* UDP-Pakete nach außen. Versuch's also einfach, die Chancen stehen gut =)
--Ingo
Und was wird wohl der Admin in der Firma zu sowas sagen? Und erst die firmeninterne Sicherheitspolicy?
Nachdenkliche Gruesse,
Michael
Grüße,
Gunter
Und ja, wenn die Firmenpolicy das ganze verbietet, sollte man nat-traverse natürlich nicht benutzen. Genauso wenig wie alle anderen denkbaren Tunnel-Mechanismen (Proxyketten [PDF], Data-over-DNS [PDF], IPv6-in-IPv4 [PDF], und noch viele weitere (BTW, im aktuellen Linux-Magazin wird auch ein Tunnel-Mechanismus vorgestellt, PPP-über-TCP IIRC)).
Ich nutze hier nat-traverse u.a., um einen Tunnel zu einem Freund aufzubauen, der einen Router besitzt, der nur zehn Ports weiterleiten kann, und von denen diese zehn Ports schon benutzt werden.
Oder vielleicht willst du schnell irgendwas zu einem anderen Rechner, der dir gehört, kopieren, und du hast vielleicht sogar Zugriff auf die Routerkonfigurationen? Mit nat-traverse musst du nicht deine Firewalls umkonfigurieren, deine Sachen übertragen, und dann die Konfiguration wieder zurücksetzen. :)
--Ingo
--Ingo
Jörg
Hmmmm also ich hab schon einige Perlscripte kompiliert mit Perl 5 und da gabs nie Probleme, nun gut es waren fast keine uses drin, aber die Frage ist eher was würde man damit gewinnen, kompilierte Perlscripte sind in der Regel nicht schneller, macnhmal sogar langsamer
Und du hast auch mit deiner zweiten Aussage z.T. recht, solange du dich auf Perl 5 beziehst. Perl 6 allerdings sieht Kompilierung als Standard vor. Du kannst auch mal einen ganz einfachen Benchmark ausführen: Hole dir Pugs und messe die Zeit von pugs examples/mandel.p6. Und dann miss die Zeit, wenn du das Teil erst kompilierst (pugs -CPIR examples/mandel.p6 > mandel.pir) und dann startest (parrot mandel.pir).
--Ingo
Das Ding scheint echt cool zu sein.
Ich werde es sofort benutzen!
Funktioniert das Ding auch unter Windows? Mein Freund lies sich noch nicht zum Umstieg bewegen.
AFAIK geht Perl auch unter Windows. Ob nat-traverse hier mitmacht, müsste man noch testen. Die Wahrscheinlichkeit ist imo aber sehr hoch
Guten Tag,
der hinterlegte Tarball Link funktioniert leider nicht
Hey zeldor,
wow, dass dieser uralte Artikel nach so langer Zeit kommentiert wird! Ein aktueller Tarball ist unter https://www.speicherleck.de/iblech/nat-traverse/ zu finden.
Viele Grüße
Ingo