L2TP, GRE oder IPsec: Welche Schicht soll die Sitzung tragen?

Zwei Fragen geraten durcheinander, sobald L2TP, GRE und IPsec in derselben Designnotiz landen: Welche Sitzung trage ich, und welche Schicht schützt sie? Beantwortet man die erste falsch, bleibt alles Nachgelagerte intern stimmig, während das falsche Problem gelöst wird — ein geroutetes Overlay, wo Nutzer sich einwählen mussten, oder ein Einwahlkonzentrator als Ersatz für ein Standort-zu-Standort-Gateway. Das Arbeitsblatt unten erzwingt diese Unterscheidung, bevor jemand sich an einem Gerät anmeldet. Füllen Sie es der Reihe nach aus, dann wird jede Zeile zu etwas, das sich einzeln prüfen lässt.

Beginnen Sie bei der Sitzung, nicht bei der Protokollliste

Ein entfernter Nutzer mit einer PPP-Sitzung und ein geroutetes Overlay zwischen zwei Gateways sind unterschiedliche Netzbeziehungen, selbst wenn beide am Ende in IPsec verpackt werden. Die erste beendet eine Verbindung pro Nutzer und braucht Adresszuweisung, Authentifizierung einer Person oder eines Geräts sowie eine Richtlinie, die benennt, welche internen Netze dieser Nutzer erreichen darf. Die zweite leitet Pakete zwischen Standorten weiter, in die sich niemand einwählt.

Schreiben Sie einen Satz, der benennt, welche der beiden Varianten Sie bauen, und lesen Sie ihn dann so, als wären Sie die Person, die ihn betreiben muss. Wenn der Satz das Wort „und“ braucht, bauen Sie beides, und das Arbeitsblatt braucht zwei Spalten statt einer Kompromissspalte, die jeder Seite nur halb dient. Wenn er einen Nutzer, aber keinen Adresspool nennt, oder ein Präfix, aber keine Weiterleitungsrichtlinie, ist der Satz noch unvollständig. Die Formulierung klingt bürokratisch, aber sie ist die billigste Stelle, um ein Design zu erwischen, das sonst über ein Helpdesk-Ticket entdeckt wird.

Geben Sie jeder Schicht genau eine Aufgabe

L2TPv2 trägt PPP-Sitzungen zwischen seinen beiden Endpunkten. PPP übernimmt die Linkaushandlung und, wenn sie ausgehandelt wird, die Nutzerauthentifizierung; L2TP fügt keine Kryptografie hinzu, deshalb implementiert ein reiner L2TP-Daemon keinen Teil der IPsec-Sicherheitsbeziehung und gehört nur in eine Verbindung, der Sie bereits vertrauen.

GRE ist eine Kapselung zwischen zwei Adressen. Es überträgt Pakete der Netzwerkschicht über ein logisches Overlay und bietet für sich genommen weder Vertraulichkeit noch eine authentifizierte Peer-Identität. Das ist kein Defekt: Der Header wurde einfach gestaltet, damit er auf Weiterleitungs-Hardware günstig zu verarbeiten bleibt. Die Folge ist, dass GRE die Frage „Wie ich dieses Paket zwischen zwei Adressen bewege“ beantwortet und sonst nichts — genau die Frage, die Sie ihm stellen sollten.

Damit bleibt IPsec als die Schicht, die Verkehr auswählt, die Peers authentifiziert und verschlüsselt, was sie schützen soll. Welchen Verkehr sie schützt, ist eine Konfigurationsentscheidung, die zur Kapselung passen muss, die die Endpunkte tatsächlich erzeugen, denn eine Richtlinie für die äußere GRE-Adresse verhält sich anders als eine für die inneren Präfixe. Die GRE-Spezifikation hält Nutzlast, GRE-Header und äußeres Transportprotokoll sichtbar getrennt, und Ihre Richtlinie braucht dieselbe Trennung.

Schreiben Sie den Paketpfad vor der Konfiguration

Nehmen Sie ein Paket und listen Sie jeden hinzugefügten Header in der Reihenfolge auf, in der er hinzukommt, samt dem Gerät, das ihn hinzufügt. Bei einem Einwahlnutzer ist das meist PPP in L2TP in IPsec; bei einem Standort-Overlay das innere IP-Paket in GRE in IPsec. Wenn zwei Geräte denselben Header hinzufügen, haben Sie eine Schleife oder einen doppelten Tunnel, und keine Richtlinienänderung behebt das.

Dieselbe Liste klärt die MTU, denn die nutzbare innere Größe ist die gemessene Pfad-MTU minus der eben aufgezählten Header und sonst nichts. Übernehmen Sie keine Zahl aus einem Forenbeitrag: Addieren Sie den Overhead von äußerem IP, UDP und ESP, dann GRE oder L2TP, dann PPP, wo es gilt, und ziehen Sie das von der tatsächlich gemessenen Pfad-MTU ab. Symptome, die nur bei großen Übertragungen auftreten, oder Sitzungen, die aufgebaut werden und dann bei der ersten großen Antwort sterben, führen meist darauf zurück, dass diese Addition geschätzt wurde.

Prüfen Sie jede Schicht einzeln, von außen nach innen

Führen Sie die Prüfungen der Reihe nach aus und halten Sie bei der ersten an, die fehlschlägt. Jede Zeile beantwortet eine andere Frage, ein Fehlschlag zeigt also auf eine Spalte des Arbeitsblatts statt darauf, dass der Tunnel defekt ist.

ip xfrm state                  # is the IPsec SA up?
ip -s link show gre1           # does the overlay interface carry packets?
ip route get 10.20.0.5         # does the inner prefix route where you think?
ss -lun | grep -E "1701|4500"  # are the L2TP and NAT-T listeners bound?

Auf einer Cisco-Box ist das Äquivalent rollenspezifisch, und die genaue Syntax hängt von Plattform und Release ab: show crypto session für die IPsec-Peers, Interface-Zähler für das GRE- oder Tunnel-Interface und die VPDN- oder PPP-Prüfung für die Einwahlrolle. Eine Befehlssammlung, die PPP beendet, beweist nichts über GRE-Unterstützung, und ein funktionierendes GRE-Interface beweist nichts über den PPP-Dienst; prüfen Sie also die Rolle, die Sie tatsächlich konfiguriert haben, statt die im Diagramm.

Notieren Sie jede Ausgabe neben der Arbeitsblattzeile, zu der sie gehört. Notizen, die während des Fehlers entstehen, sind mehr wert als eine Topologie, die danach aus dem Gedächtnis neu gezeichnet wird.

Ordnen Sie den Abbau, dann prüfen Sie erneut

Der Abbau läuft aus gutem Grund in umgekehrter Reihenfolge: Nehmen Sie den geschützten Verkehr aus der IPsec-Richtlinie, bevor Sie die Kapselung entfernen, für die sie geschrieben wurde, sonst zeigt die Richtlinie weiter auf ein Interface, das nicht mehr existiert, und der nächste Konfigurationsladevorgang scheitert an einer Stelle, die unzusammenhängend wirkt. Auf Linux heißt das, die State- und Policy-Einträge vor dem Tunnel-Interface zu löschen; auf einem Router, den Crypto-Map- oder Profile-Eintrag vor dem Tunnel zu entfernen.

Wiederholen Sie nach dem Neuaufbau die vier Abnahme-Beobachtungen einzeln: äußere Erreichbarkeit, eine aufgebaute IPsec-Assoziation, eine aufgebaute PPP-Sitzung, wo das Design eine enthält, und innere Weiterleitung an eine echte Zieladresse. Ein grünes Licht ist kein Beleg für die anderen drei, und diese Lücke ist der Fehler, der in der Produktion am längsten überlebt — ein Tunnel, der steht, verschlüsselt ist und nichts weiterleitet, weil die innere Route nie hinzugefügt wurde.

Halten Sie das ausgefüllte Arbeitsblatt neben der Gerätekonfiguration. Jede Spalte, die Sie nicht füllen können, ist eine Schicht ohne zugewiesene Aufgabe, und eine Schicht ohne zugewiesene Aufgabe ist meist eine Schicht, die nicht im Stack sein sollte.