Vielen Dokumenten zufolge sollte bei Host-zu-Host-IPSec der Transportmodus verwendet werden, während Tunneling zum Verbinden von Gateways und L2TP für den Remotezugriff genutzt wird.
Aber nichts hindert mich daran, den Transportmodus von Gateway zu Gateway zu verwenden, oder? Ein Gateway kann ESP (oder AH) lesen, entfernen und das nackte IP-Paket an sein Netzwerk weiterleiten.
Und ich kann auch den Tunnelmodus zwischen meinem PC und dem Datenbankserver verwenden. Es ist wahrscheinlich redundant, jedes Paket in separates UDP zu verpacken, aber verwendbar.
Und ich kann reines IPSec (ohne L2TP) für den Fernzugriff verwenden, wenn ich der einzige Benutzer auf meinem PC bin. Ich werde keine Abrechnung, Netzwerkkonfiguration über IPCP und andere PPP-Sachen haben, aber das ist nicht immer erforderlich.
Schließlich könnte man mit L2TP zwei Gateways verbinden ;)
Meine Frage ist also, warum all diese Ansätze existieren und sich gegenseitig duplizieren? Warum gibt es noch IPSec-Transport, wenn er fast immer in Tunneling geändert werden könnte und umgekehrt? Können Sie mir ein Beispiel für eine Situation geben, in der eine dieser Methoden „die einzig richtige ist“?
Antwort1
Warum gibt es noch IPSec-Transport, wenn er fast immer auf Tunneln und umgekehrt umgestellt werden könnte?
Ich sehe nicht, dass der Transportmodus IPSec heute von der breiten Masse der Benutzer vernetzter Geräte verwendet wird. Ich denke, es hat nie genug Schwung gewonnen, um allgemein eingesetzt zu werden. Software- und Netzwerkanbieter hatten ein Interesse daran, Tunnelmodus-Implementierungen (plus umfangreiche Backends) an Unternehmenskunden mit Bedarf an Fernzugriff zu verkaufen, haben den Transportmodus aber niemandem aufgedrängt. Die Funktionen mögen vorhanden gewesen sein, aber die Benutzerfreundlichkeit lässt immer noch zu wünschen übrig.
Es existiert also, aber ist es noch relevant? Der Transportmodus war historisch gesehen für viele Benutzer nicht zugänglich. Eine Ausnahme waren die Leute, die kostenlose Software verwendeten.
Verlauf und Implementierungsstatus der Opportunistic Encryption für IPsec
Der obige Link beschreibt die historischen Bemühungen, IPSec überall einzuführen, und wie diese Bemühungen behindert wurden. Die Gründe dafür können zusammengefasst werden als die Unsicherheit der Internet-Infrastruktur (z. B. DNS) und die relative Selbstzufriedenheit der Beteiligten, diese zu ändern.
Warum gibt es all diese Ansätze und warum duplizieren sie sich gegenseitig?
Alle diese Ansätze existieren hauptsächlich aufgrund der unabhängigen Identifizierung und Lösung unterschiedlicher Anforderungen an sicheren Fernzugriff, und zwar ungefähr im gleichen Zeitraum. Eine leicht verbesserte Version Ihrer Frage könnte lauten: „Warum werden all diese Ansätze noch immer verwendet?“
Sie haben Ihre Frage, warum L2TP noch immer verwendet wird, selbst beantwortet: Abrechnung und Konfiguration. (Es ist vielleicht interessanter, sich anzuschauen, warum andere Protokolle, wie z. B. PPTP, nicht mehr verwendet werden.) In vielen Fällen, selbst wenn Sie sich nicht um Abrechnung und Konfiguration kümmern,
In anderen Fällen ist die Antwort nicht so eindeutig. Nehmen wir den Fall von Gateway zu Gateway. Sie könnten reines Tunnelmodus-IPSec verwenden oder GRE-Tunnel über IPSec (ich glaube sogar, dass sie über Transportmodus-IPSec laufen). Ich weiß nicht, ob es außer der Vertrautheit einen Vorteil in irgendeiner Weise gibt. Ich persönlich habe noch nie Tunnelmodus-IPSec auf einem Cisco-Router eingerichtet. Ich habe immer verschlüsseltes GRE verwendet. Warum? Weil alles, was ich über einfaches GRE weiß, auch für verschlüsseltes GRE gilt. Es ist mir also vertraut.
Vergessen Sie nicht VPNs/Tunnel auf Anwendungsebene wie OpenVPN oder Secure Shell. Diese haben im Allgemeinen eine schlechtere Leistung als Implementierungen auf Kernel- oder Appliance-Ebene. Aber sie waren (und sind) im Allgemeinen einfacher zu verwenden und hatten den Vorteil, dass sie leichter durch Proxys und Firewalls kamen (zumindest bis zum Aufkommen der Deep Content Inspection). Außerdem haben sie oft weniger Abhängigkeiten; es ist viel einfacher, OpenVPN auf einem alten Linux-Server zu kompilieren, als den Kernel neu zu kompilieren, um IPSec zu unterstützen.
Können Sie mir ein Beispiel für eine Situation nennen, in der eine dieser Methoden „die einzig richtige“ ist?
Beim Networking (wie bei so vielen anderen Dingen in der Computertechnik) gibt es nie „die einzig richtige Lösung“. In den meisten Fällen muss man sich auf das beschränken, was machbar ist. Beispielsweise funktionieren alle Android-Geräte mit L2TP-basierten VPNs. Das ist also machbar, auch wenn Sie keine Konfiguration oder Abrechnung benötigen. Da ich mit GRE-Tunneln auf Cisco-Geräten vertraut bin, sind sie für mich einfacher zu implementieren als reines IPSec im Tunnelmodus. Und ich kann auf einem alten Linux-Server, den ich (aus irgendeinem Grund) nicht aktualisieren kann, einen OpenVPN- oder SSH-basierten Tunnel erstellen.
Antwort2
- IPsec-Tunnel vs. Transportmodus
- Tunnelmodus hat mehr Overhead
- Der Transportmodus funktioniert nur zwischen Hosts, da die Umhüllung keinen zusätzlichen Satz von IP-Adressen enthält
- ist der Overhead ein Problem?
- Stellen Sie sich eine Zeit vor, in der Hosts vor jeder Kommunikation eine IPsec-Verbindung untereinander herstellen. ** IPsec wäre überall ** im Tunnelmodus wären die IP-Adressen in jedem Paket zweimal vorhanden → Ressourcenverschwendung