Erfahrungen mit Telekom LTE Hybrid und SSH Problemen mit IPv4 / IPv6

Die Fördermittel für den Bandbreitenausbau in Deutschland scheinen langsam Wirkung zu zeigen.
Während wir bisher im Büro auf das LTE-Netz der Telekom angewiesen waren und aufgrund des Traffic-Limits regelmäßig nachbuchen mussten,
ist seit diesem Juni bei uns auch normales DSL verfügbar.
Und wir haben uns für MagentaZuhause Hybrid M entschieden, mit dem neuen Speedport LTE Hybrid der deutschen Telekom. Die Technik scheint ja durchaus interessant zu sein.
Mit LTE haben wir bereits sehr gute Erfahrungen, der einzige Negativ-Punkt ist das Traffic-Limit. Nach 40GB werden wir so stark gedrosselt, dass ein sinnvolles Arbeiten nicht mehr möglich ist. Wir sind also dazu gezwungen, ständig nachzubuchen.

Beim neuen Hybrid-Anschluss wird bevorzugt die DSL-Leitung verwendet. Reicht diese nicht mehr aus, wird zusätzlich auf LTE zurück gegriffen.
Hierfür ist jedoch eine besondere Hardware – also ein besonderer Router – nötig.
Die monatlichen Kosten für den Anschluss egal ob mit oder ohne hybrid sind gleich, nur die Hybrid-Hardware ist teurer.

Da man den Telekom-Geräten durchaus keine Featuritis vorwerfen können, wir als Techniker aber gerne etwas tiefer eintauchen, hätten wir anstelle der von der Telekom bereit gestellten Hardware eine alternative Hardware wie beispielsweise eine Fritzbox verwendet. Aber es gibt wohl leider noch keinen alternativen Router, der mit dem Telekom-Vertrag kompatibel sind.

Letzten Dienstag war also Schaltungstermin bei uns und mit dem neuen DSL wurde unser Anschluss von ISDN auf IP umgestellt.
Über unsere die Erfahrungen zur Umstellung und zu den technischen Feinheiten möchte ich im Nachfolgenden berichten:

Die Umstellung selbst war verhältnismäßig unspektakulär. Am Tag des Schaltungstermins ging plötzlich unsere LTE-Verbindung nicht mehr.
Kurz darauf folgte eine SMS der Telekom, in der sie uns die Schaltung bestätigt haben.
Also haben wir kurzerhand den alten LTE-Speedport entfernt, die SIM-Karte in den neuen Speedport Hybrid Router eingelegt.
Außerdem den NTBA entfernt und den Hybrid-Router direkt an der TAE-Dose angesteckt.
Zugangsdaten, Konfiguration, Telefonnummern für VOIP, etc. hatten wir alles bereits eingerichtet, wir waren also relativ schnell wieder online.
Dennoch hatten wir mit diversen Problemchen zu kämpfen, bei denen man nicht annehmen würde, dass sie im Zusammenhang mit einem neuen DSL-Anschluss stehen könnten:

Kein Mail-Versand möglich:
Über unsere Mailclients (Thunderbird) war kein Mailversand mehr möglich.
Die Lösung hierfür war relativ einfach und schnell gefunden:
Beim Speedport musste unser Mailserver in die Liste der vertrauenswürdigen Mailserver eingetragen werden.
Viele Mailserver wie beispielsweise gmx oder web waren bereits enthalten.
Von unserem firmeninternen Mailserver wusste die Telekom verständlicherweise jedoch nichts.

SSH-Problem (QOS) / SSH blieb „hängen“
Etwas seltsamer war, dass plötzlich unsere SSH-Verbindungen instabil wurden.
Entweder blieb die SSH-Verbindung hängen oder wurde abrupt getrennt.
Teilweise konnte auch gar keine SSH-Verbindung zu den Servern mehr aufgebaut werden.

Auf ersteres Problem waren wir gefasst. Dass das Aufteilen der Pakete parallel auf eine physikalische Leitung und auf „die Luft“ via LTE mit allen Anwendungsfällen problemlos möglich sein sollte, war uns von vorne herein suspekt. Und tatsächlich, als wir LTE komplett deaktiviert hatten, waren die Verbindungsabbrüche mit SSH weg.
Glücklicherweise bietet der Speedport Hybrid zusätzlich die Möglichkeit an, LTE für bestimmte Verbindungen auszuschließen. Man kann also einfach Port 22 von LTE ausschließen und muss LTE nicht fortan komplett deaktiviert lassen.

Das zweite Problem, dass gar keine SSH-Verbindung aufgebaut werden konnte bestand jedoch immer noch.
Ließ sich jedoch auf Server reduzieren, die bereits via IPv6 angebunden waren.

Merkwürdig daran war jedoch, dass die IPv6-Verbindung an sich funktionierte.
Der Server war Pingbar und auch der initiale Verbindungsaufbau klappte:

$ ssh -v root@serverX
debug1: Server accepts key: pkalg ssh-dss blen 433
debug1: Enabling compression at level 6.
debug1: Authentication succeeded (publickey).
Authenticated to serverX
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = de_DE.UTF-8
Write failed: Broken pipe

….
Also hier brach die Verbindung ab.

Witzigerweise funktionierte die Verbindung, wenn explizit die BASH gestartet werden sollte:
$ ssh root@serverX bash -i

Auch, wenn wir SSH angewiesen haben, explizit eine IPv4 Verbindung aufzubauen, funktionierte es:
$ ssh -4 root@serverX

Wir wollten deshalb beim Verbindungsaufbau via IPv6 zunächst sicherstellen, dass keine Pakete verloren gingen.
Hierzu haben wir sowohl auf dem Server als auch auf dem Client die Pakete mittels tcpdump verfolgt:

$ tcpdump -i eth0 -vvv -tttt -n ‚port 22 and ip6‘

Und siehe da, die ersten Pakete kamen perfekt durch:
2015-06-11 16:15:18.945743 IP6 (hlim 64, next-header TCP (6) payload length: 72) 2a01:4f8:140:72c2::2.22 > 2003:62:5f2b:e207:ccb7:146f:cbe5:b810.37357: Flags [P.], cksum 0x1bdf (correct), seq 2248:2288, ack 3384, win 196, options [nop,nop,TS val 2171104204 ecr 18722466], length 40

Und ab einem bestimmten Zeitpunkt, wurden zwar Pakete vom Server versendet, vom Client jedoch nicht mehr empfangen:
———–
2015-06-11 16:15:18.984022 IP6 (class 0x10, hlim 64, next-header TCP (6) payload length: 120) 2a01:4f8:140:72c2::2.22 > 2003:62:5f2b:e207:ccb7:146f:cbe5:b810.37357: Flags [P.], cksum 0xb2b2 (correct), seq 2288:2376, ack 3680, win 216, options [nop,nop,TS val 2171104242 ecr 18722476], length 88

Und es lässt sich sogar ein Unterschied ausmachen „class 0x10“.
Diese Angabe bezieht sich auf ein sog. QOS – Quality of Service, TOS Type-of-Service bzw. mittlerweilse DSCP (Differentiated Services Code Point) genannt und bedeutet, dass dem Traffic eine Klasse zugeordnet wurde. Ziel dabei ist es, bestimmte IP-Pakete zu bevorzugen. Class 0x10 bedeutet in diesem Fall, dass das Paket nicht stark verzögert bzw. im Umkehrschluss bevorzugt werden soll.
Ist bei SSH logisch, man möchte ja beim Eintippen von Befehlen möglichst schnell das resultat sehen.

Aus irgend einem bisher uns unbekannten Grund, scheint das Routing dieser speziell gekennzeichneten Pakete beim MagentaZuhause Hybrid M nicht korrekt zu funktionieren.
Glücklicherweise kann man SSH so konfigurieren, dass es den Paketen keine Klasse mehr zuordnet.

Hierzu einfach in die Dateien
/etc/ssh/ssh_config
/etc/ssh/sshd_config
diese Zeile einfügen:
IPQoS 0x0
Und den SSH-Server neustarten:
/etc/init.d/ssh restart

Optional könnte man diese Angabe auch beim SSH-Befehl mitgeben:
$ ssh -6 -l root -o IPQoS=0x00 serverX
Oder die Zeile in der Datei ~/.ssh/config einfügen.

Aber ACHTUNG: Das Routing-Problem scheint in beiden Richtungen aufzutreten!
Also der SSH-Client muss angewiesen werden, auf QoS zu verzichten, damit die Pakete beim Server ankommen.
Und der Server muss ebenfalls darauf verzichten QoS zu verwenden, damit dessen Pakete wiederum beim Client ankommen!
Bei unseren Tests haben nicht alle SSH-Server QoS standardmäßig verwendet. Während bei den alten Debian Squeeze Servern scheinbar noch kein QoS zum Einsatz kommt, kommt bei unseren Debian Wheezy-Servern QoS zum Einsatz.