Firewalls, die IKE und ESP erlauben, aber nicht UDP 1701, brechen L2TP-Verbindungen auf eine Weise, die wie ein Problem mit den Zugangsdaten aussieht. Der Grund ist, dass L2TP ein zweites Protokoll ist, das im ersten reist. IPsec trägt und authentifiziert den Austausch, und L2TP betreibt seinen eigenen Tunnel über UDP 1701, den der lokale Stack trotzdem zustellen muss. Zu wissen, wo jeder Header erscheint, erklärt, welches Gerät welche Regel braucht.

Zwei Protokolle, zwei Portsätze

Eine L2TP/IPsec-Verbindung nutzt IKE auf UDP 500, NAT-Traversal auf UDP 4500, wo eine Übersetzung vorhanden ist, und ESP als IP-Protokoll 50, wo nicht. L2TP selbst ist ein Tunnelprotokoll auf UDP 1701 und läuft, nachdem IPsec den Peer authentifiziert hat. Die beiden Hälften scheitern unterschiedlich, und die Logzeilen, die davon berichten, stammen von verschiedenen Komponenten. Ein Regelsatz, der nur die erste Hälfte abdeckt, erzeugt eine Verbindung, die aushandelt und dann in der Tunnelphase stirbt.

Portnummern beschreiben Transportendpunkte, und ESP ist überhaupt kein Port. Deshalb kann eine Firewall-Oberfläche, die nur TCP- und UDP-Regeln anbietet, keine vollständige IPsec-Richtlinie ausdrücken. Protokoll 50 muss als Protokoll erlaubt werden, und eine Regel, die nur UDP nennt, wird es nie treffen.

Die Hülle erklärt den Port

Auf der Leitung zeigt eine L2TP/IPsec-Verbindung normalerweise IKE auf 500 und gekapseltes ESP auf 4500. Der UDP-1701-Header sitzt innerhalb der geschützten Nutzlast, deshalb zeigt ihn ein Mitschnitt an der äußeren Schnittstelle nicht. Der lokale Host muss dieses Datagramm trotzdem an den L2TP-Daemon zustellen, und die Zustellung erfolgt nach dem Entkapseln. Die Regel für 1701 gehört daher an die Firewall des Endpunkts selbst, selbst wenn keine Middlebox den Port jemals sieht.

Die Verarbeitungsreihenfolge erklärt den größten Teil der Verwirrung. Wendet der Stack die IPsec-Richtlinie vor dem Hostfilter an, wird das entkapselte L2TP-Paket als UDP 1701 abgeglichen; ist die Reihenfolge umgekehrt, sieht der Regelsatz die äußeren Ports. Beide Verhaltensweisen gibt es in der Praxis, weshalb derselbe Regelsatz auf einer Plattform zu funktionieren scheint und auf einer anderen scheitert.

Prüfe den Pfad der Reihe nach

Zeichne zuerst die äußere Schnittstelle auf und bestätige, dass sich IKE und gekapseltes ESP in beide Richtungen bewegen. Prüfe dann die Zähler der lokalen Firewall für den entkapselten Verkehr. Die Reihenfolge ist wichtig, denn ein Mitschnitt, der gar nichts zeigt, bedeutet, dass das Problem oberhalb des Hosts liegt.

sudo tcpdump -ni eth0 'udp port 500 or udp port 4500'
sudo nft list ruleset | grep -i -A2 1701
sudo ss -lunp | grep 1701

Der Mitschnitt bestätigt die erste Hälfte des Austauschs und zeigt, ob der Peer antwortet. Die Regelliste zeigt, ob eine Regel für 1701 existiert und wo sie im Verhältnis zu einer Verwerfungsrichtlinie steht. Die Socket-Liste bestätigt, dass der L2TP-Daemon gebunden ist und lauscht, was einen Dienst ausschließt, der nie gestartet wurde. Lies alle drei, bevor du eine Regel änderst, denn ein fehlender Listener und ein gefilterter Port erzeugen beim Nutzer identische Beschwerden.

Was ein Portscan nicht zeigen kann

Ein externer Scan von UDP 1701 gegen einen korrekt konfigurierten Server meldet normalerweise nichts, und das ist das erwartete Ergebnis. Der Port ist nicht ins Internet exponiert; er ist nur erreichbar, nachdem IPsec den Peer authentifiziert hat. Das geschlossene Ergebnis als Fehler zu behandeln, führt dazu, einen Port zu öffnen, der geschlossen bleiben sollte. Der Scan kann nicht in den Tunnel sehen, genauso wenig wie er den Anwendungsverkehr sehen kann.

Teste stattdessen mit einem echten Client und lies nach, bis zu welcher Stufe er kommt. Verhandelt die Verbindung und bleibt dann hängen, sind der L2TP-Daemon oder der lokale Filter verdächtig; verhandelt sie nie, sind es die äußeren Ports. Diese eine Unterscheidung beseitigt den größten Teil des Rätselns darüber, welche Regel hinzugefügt werden muss, und die Protokollschichtung macht es vorhersagbar statt rätselhaft.

Ähnliche Artikel