Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
NewsWireGuard: Testversion von Fritz!OS 7.39 für die Fritz!Box 7590 AX
Ich sprach auch nicht von HTTP/1.x sondern von HTTP/3. Und wir sprechen hier von Wireguard, was sich eben auch darum kümmert. Was bringt also ein Vergleich mit Protokollen aus den 80ern oder 90ern?
xexex schrieb:
IPsec unterstützt im Gegensatz zu WireGuard beides.
Ganz ehrlich: Hast du schonmal was mit IPSec gemacht oder copy/pastest du hier nur wild aus Wikipedia? Es gibt kein TCP bei IPSEC. Es gibt UDP für IKE und Proto 50 (weder UDP noch TCP!) für ESP. VPN über TCP ist total idiotisch, weshalb dir auch jeder dazu rät, bei OVPN nur dann TCP zu verwenden, wenn es nicht anders geht. Bzw. bei SSL VPNs wird daher gerne DTLS (UDP) für die Payload genutzt.
Alleine die Aussage, dass IPSEC TCP verwenden könne, lässt mich daran stark zweifeln.
xexex schrieb:
Ich weiß nicht woher du deine Weisheiten her hast, aber sei dir gesagt, VPN über UDP ist total idiotisch. Wenn es darum geht, dass die Pakete auch ankommen.
Es tut mir leid, das so deutlich sagen zu müssen: Aber du hast keine Ahnung davon. Niemand benutzt freiwillig TCP für VPNs, weil TCP over TCP ein massiver overhead ist und schnarchlahm. Die einzige Daseinsberechtigung sind Netze, bei denen nur TCP/443 Outgoing erlaubt ist. So wird es übrigens auch bei nahezu allen kommerziellen SSL VPN Lösungen gemacht: Connect/Auth: TCP/443, Payload: DTLS. Fallback für Payload: TCP/443.
Lol, du sprichst hier die ganze Zeit von "Enterprise" und kommst nun mit einer Marketing FAQ von NordVPN Welches Protokoll fahren denn üblicherweise die Applikationen, die den Tunnel nutzen? Richtig: TCP. Und genau das sorgt eben dafür, dass die Pakete im Tunnel richtig ankommen.
xexex schrieb:
Ich fasse es kurz, du willst nicht in einem Netzwerk, dass dir irgendwelche Pakete verloren gehen und das tun sie zwangsweise, wenn du keine Kontrolle oder Überprüfungsmöglichkeiten hast ob ein Paket ankommt.
Und genau dafür ist das Protokoll im(!!!) Tunnel da. BTW: Jede sch* DSL Leitung läuft erstmal im UDP L2TP Tunnel. Aber das ist eben völlig egal, weil es darauf ankommt, was im Tunnel passiert. Und genau so ist das bei VPNs auch. Ansonsten müsstest du nun sofort jede DSL Leitung in Frage stellen.
Genau das sagt btw. auch deine falsch interpretierte Wikipedia Grafik, die du hier copy/pasted hast aus. Es ist nur der Tunnel. Den Datenfluss regeln die Protokolle, die durch den Tunnel gehen. Und das ist dann halt in der Regel wieder TCP.
Ganz ehrlich @xexex: Es gehört auch zum guten Ton einfach mal einzugestehen, dass man sich geirrt hat und nicht nur "..." zu schreiben. Du stellst hier mit deinen Aussagen unzählige RFCs und vor allem im Internet und Datacenter geläufige Technologien komplett in Frage. Und mit Aussagen wie "Ich mach das schon 20 Jahre" überzeugt man niemanden.
Wie oben schon geschrieben, läuft der L3BSA Traffic von DSL Leitungen komplett über einen UDP basierten Tunnel (L2TP). Auch nach wie vor üblich ist GRE (z.B. beim Telekom Hybrid Produkt), welches wie IPSEC für den Payload ein eigenes IP Prodokoll nutzt. Sebstverständlich ohne Maßnahmen wie sie TCP nutzt. Weil es schlicht egal ist und nur Nachteile mit sich bringt (siehe der verlinkte TCP over TCP Artikel).
Und im Datacenter Kontext ist es heute üblich, VXLANs oder GENEVE zu nutzen. Auch hier wird nur UDP genutzt und darüber laufen dann massive Datenmengen. Denn es ist, wie ich schon mehrfach geschrieben habe, egal, welches Protokoll der Tunnel nutzt. Sieh es wie eine Leitung an. Das Protokoll darüber kümmert sich darum. Und da hast du ja dann in der Regel wieder TCP. Aber es ist völlig unnötig, dass der Tunnel selbst TCP nutzt.
Du kannst es auch ganz einfach selbst nachvollziehen: Öffne eine stateful TCP Session von A nach B, die über einen Tunnel geht. Dann baust du den Tunnel neu auf und du wirst sehen, dass die TCP Session nach wie vor steht. Es ist egal, dass der Tunnel kurz weg ist, solange er nicht länger als das TCP Timeout weg ist.
Ganz einfach, ich spare es mir hier jetzt eine Protokollbeschreibung über die Funktionsweise von IPsec zu schreiben, aber ja wenn es dich glücklicher macht, IPsec läuft nicht über TCP sondern eine Ebene darunter.
Wir reden die ganze Zeit über den Transport. Und das ist ESP bei IPSEC, Protocol 50. Und das ist in der Transportschicht beheimatet. Egal ob Transport oder Tunnel Mode bei IPSEC. Und selbst bei IPv6, bei dem IPSEC im Extension Header Integriert ist, läuft der Transport separat via ESP. Wie auch AH.
Ohne zwischenfunken zu wollen, das "alt" habe ich so nicht gemeint und um Missverständnisse zu vermeiden extra in Anführungszeichen gesetzt. Zum zweiten, ja AVMs Einschränkung. Ich schreibe doch selber:
Wilhelm14 schrieb:
...Meint ihr damit IPv6 bei WireGuard oder führt AVM tatsächlich IPv6 bei ihrem "alten" VPN ein?
AVMs VPN kann bis dato kein IPv6. Und mit "alt" meinte ich die bis jetzt von AVM eingesetzte VPN-Technik vor WireGuard, welches "neu" bei AVM ist. Die Kritik oder Frage geht an/gegen AVM, nicht gegen IPsec.
Siehst du den Unterschied? Ja ESP ist in der Transportschicht und sorgt für die Integrität der Daten. Die Übertragung der Daten erfolgt jedoch direkt über IP und nicht wie bei WireGuard über UDP. Letztendlich aber irrelevant, so oder so sehe ich WireGuard auch langfristig nicht IPsec ersetzen, auch wenn es als Ergänzung, vor allen bei schwächeren Geräten die keine AES Verschlüsselung in Hardware mitbringen, mit Sicherheit interessant ist.
Danke für den Screenshot... Der zeigt doch nur das, was ich die ganze Zeit schon geschrieben habe. IPSEC nutzt ESP um die Payload zu übermitteln.
Lies dir bitte nochmal das RFC zu ESP (4303) durch und du wirst sehen, dass es da nichts gibt was für "die Integrität der Daten" sorgt. Und nein, die Übertragung der Daten funktioniert auch nicht "direkt über IP", sondern eben über ESP. Das ist neben TCP oder UDP ein Layer 4 Protokoll mit der ID 50, was über IP ist. Genau so wie es TCP oder UDP sind.
xexex schrieb:
vor allen bei schwächeren Geräten die keine AES Verschlüsselung in Hardware mitbringen, mit Sicherheit interessant ist.
Man hat auch die Möglichkeit bei IPSEC kein AES sonder ChaCha20 / Poly 1305 zu nutzen. Dann ist die Performance deutlich besser als ein non-accelerated AES. Zwar ist man auch dann hinter wg, aber immerhin.
Und nein, die Übertragung der Daten funktioniert auch nicht "direkt über IP", sondern eben über ESP. Das ist neben TCP oder UDP ein Layer 4 Protokoll mit der ID 50, was über IP ist. Genau so wie es TCP oder UDP sind.
Du willst es glaube ich nicht verstehen oder? So sieht die Übertragung bei IPsec aus.
Vielleicht noch etwas besser zu sehen, wenn du dir den Tunnelmodus bei IPsec anschaust.
Und jetzt überlege mal wie es bei WireGuard ausschaut, dort wird das ursprüngliche Paket in den UDP Paketen übermittelt, also genau eine Ebene darüber.
Kann dir auch noch gerne eine schönere Grafik zeigen.
Der blaue Part ist bei Nutzung von IPsec bereits das unverändert übermittelte Paket, während bei WireGuard das Paket in den Nutzdaten noch gekapselt und verschlüsselt wäre. Vielleicht drücke ich mich aber auch unverständlich aus, daher noch ein Zitat.
Im ESP-Tunnelmodus wird die Verschlüsselung über das gesamte Paket und dem ESP-Trailer und anschließend die Authentifizierung vom ESP-Header bis einschließlich ESP-Trailer vollzogen. Der Hash wird dann an den ESP-Trailer angehängt.
Im Tunnelmodus wird das gesamte IP-Paket verschlüsselt und in ein neues IP-Paket gepackt. Das bedeutet, die Original-IP-Adresse ist von außen nicht mehr sichtbar. Der Tunnelmodus verschleiert die Original-Adresse des Absenders.
Im Tunnelmodus kommen für den ESP-Header 8 Byte, für den ESP-Trailer 16 bis 20 Byte und für den zusätzlichen IP-Header 20 Byte hinzu.
Es ist für IPsec nicht unbedingt erforderlich IP-Pakete vollständig neu zu encapsulieren (einzukapseln). Beim Transportmodus wird der Original-IP-Header weiter benutzt und zusätzlich ein ESP-Header eingefügt. Es kommen für den ESP-Header 8 Byte und für den ESP-Trailer 16 bis 20 Byte hinzu. Vorteil des Transportmodus ist der geringe Overhead gegenüber dem Tunnelmodus.
Im Transportmodus werden lediglich die Daten verschlüsselt und der alte IP-Header unverändert belassen. Die Daten sind so zwar geschützt, ein Angreifer kann jedoch zumindest eine bestehende VPN-Verbindung zwischen zwei Stationen feststellen. https://www.elektronik-kompendium.de/sites/net/1410261.htm
Man hat auch die Möglichkeit bei IPSEC kein AES sonder ChaCha20 / Poly 1305 zu nutzen. Dann ist die Performance deutlich besser als ein non-accelerated AES.
Das ist zwar korrekt, aber wie du schon sagst nur da interessant, wo die AES Verschlüsselung nicht hardwarebeschleunigt wird, also bestenfalls bei "Baumarktroutern". Mit Hardwarebeschleunigung ist IPSec durchaus performant, hier mal am Beispiel von Lancom.
Dabei befindet sich in einem 1781VA Gerät gerade einmal eine Freescale P1014 CPU mit 800Mhz, daran sieht man wie schlecht die Implementierung von IPsec bei AVM ist.
Och mensch Xexex. Wieso kommst du denn immer mit irgendwelchen Grafiken, die du ergooglest und nicht interpretieren kannst? Diese Grafiken von dir zeigen den inneren weg bzw. die inneren Layer. Wir sprechen doch die ganzen Zeit von den äußeren. Ich nehme jetzt einfach mal die selbe Quelle wie du, aber halt die passende Grafik:
Wenn du jemals wirklich mit IPSEC zu tun hattest, müsstest du doch wissen, welche Ports und Protokolle du im Paketfilter freigeben musst.
Halten wir also fest. IPSEC nutzt ESP um die Payload zu transportieren. Wireguard UDP. Keines von beiden nutzt TCP oder irgendeine Art davon um den Datenfluss sicherzustellen. Warum nicht? Weil es unnötig ist. Und ich habe es schon oben geschrieben: Wenn du der Meinung bist, dass TCP dafür essentiell notwendig sei, dann müsstest du auch etablierten Verfahren wie L2TP, VXLANs oder GENEVE misstrauen. Alles Dinge mit denen du im täglichen leben bei der Nutzung des Internets zu tun hast, ohne das du es merkst. Warum merkst du es nicht? Weil die Protokolle, die du nutzt, HTTP & Co eben TCP nutzen und sorge dafür Tragen, dass die Pakete ordentlich ankommen. Und genau das selbe gilt beim VPN Tunnel.
Und damit bin ich raus aus dem Thema, nicht dass ich hier noch ne Verwarnung wegen massiv OT bekomme.
Naja, gerade für HomeOffice ist das ja meist unnütz, da baust du ja i.d.R. einen Tunnel direkt vom Firmen Laptop/VM in die Firma auf und nutzt nicht die "entgegen gesetzte Richtung" via Fritz.
Diese Funktionen sind in erster Linie für Leute, die von unterwegs oder woanders auf ihr Netz Zuhause zugreifen möchten.
Hallo fo_1337 und xexex.
Könnt ihr bitte weiter streiten uns so weiter machen.
Will noch was lernen von euch.
echt interesant was ihr da schreibt.
hab mit überlegt informatik und netzwerkadministrator ausbildung zu machen.
Aber wenn ihr so weiter macht brauch ich hier nur weiter mit zu lesen.
versöhnt euch.
Geb auch nen Bier aus.
Artikel-Update:Neue Testversion von Fritz!OS 7.39 erschienen
In der Zwischenzeit wurde mit Build 93919 eine neue Testversion von Fritz!OS 7.39 für die Fritz!Box 7590 AX veröffentlicht, die ab sofort von versierten Anwendern auf eigene Gefahr ausprobiert werden kann.
Vor der Installation einer Inhouse-/Testversion sollte die alte Firmware in jedem Fall gesicher werden.
Wie bereits die zuvor veröffentlichte Inhouse-Firmware Fritz!OS 7.39 Build 93233 unterstützt auch die neueste Testversion des AVM-Betriebssystems den freien VPN-Dienst WireGuard, der noch im Laufe des Jahres sein Debüt in der stabilen Version für diverse Router des Herstellers feiern soll.
@AGB-Leser wie mehrfach geschrieben: Der SoC der FB ist lahm, kann aber IPSEC beschleunigen. Dies wurde auch von AVM viele Monate nach Release endlich aktiviert. Dass wg auf einer low-power cpu hardware beschleunigtes IPSEC nicht massiv outperformed sollte doch erwartbar sein?
Spannend wird es auf den ganzen Boxen, auf denen es eben kein hw-accelerated IPSEC gibt bzw. wo AVM es nicht für nötig hielt, es zu aktivieren wie z.B. auf der 7530. Die wird potentiell sogar die 7590 outperformen.
Welches Protokoll fahren denn üblicherweise die Applikationen, die den Tunnel nutzen? Richtig: TCP. Und genau das sorgt eben dafür, dass die Pakete im Tunnel richtig ankommen.
