[Problem] LAN-LAN VPN: Probleme mit GIT Server aufgrund der MTU?

[balistox]

Hallo,

wie bereits in einem anderen Thread beschrieben habe ich eine LAN-LAN VPN Verbindung zwischen zwei meiner FritzBoxen hergestellt. Das funktioniert jetzt soweit ganz gut, allerdings habe ich noch ein Problem wenn zwei bestimmte Hosts zwischen den beiden Netzwerken kommunizieren.

Mein Szenario ist folgendes:

In Netz 192.168.1.0 hängt mein Synology NAS mit einem GIT Server.
In Netz 192.168.65.0 hängt mein Raspberry Pi, welchen ich als GIT Client verwenden will.

Nun habe ich versucht mein Repository mittels "git clone" Befehl auf meinem Raspberry auszuchecken. Allerdings laufe ich dort in ein relativ seltsames Timeout:

user@host:~/gitbase $ git clone -v ssh://[email protected]/pfad/repo
Cloning into 'repo'...
remote: Counting objects: 353, done.
remote: Compressing objects: 100% (331/331), done.

dann vergehen einige Minuten, bis schließlich folgendes erscheint:

Timeout, server 192.168.1.23 not responding.
fatal: The remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed

Ich habe jetzt einige Stunden recherchiert bis ich schließlich einen Hinweis auf StackOverflow gefunden habe. Dort wird berichtet dass es an der MTU auf dem Client liegen könnte, welche bei Verwendung eines VPNs nicht passt. Und tatsächlich: Ändere ich die MTU auf dem Raspberry Pi auf 1406 oder niedriger wird das Kommando richtig abgeschlossen und alle Files übertragen!

Nun meine Frage: Habe ich noch etwas auf eine der FritzBoxen falsch konfiguriert? Auf meinem NAS ist die MTU jedenfalls auch auf 1500 gestellt. Die Route zu meinem NAS hin sieht jedenfalls auch okay aus:

$ traceroute 192.168.1.23
traceroute to 192.168.1.23 (192.168.1.23), 30 hops max, 60 byte packets
 1  fritz.box (192.168.65.1)  0.583 ms  0.485 ms  0.472 ms
 2  192.168.1.23 (192.168.1.23)  24.171 ms  28.319 ms  28.047 ms
 3  192.168.1.23 (192.168.1.23)  27.785 ms  32.219 ms  31.956 ms

Über Hinweise wäre ich sehr dankbar!

Liebe Grüße,
balistox

 

[balistox]

Ich habe das Problem mittlerweile auch öfter mal wenn ich über einen SSH Client im 192.168.65.0 Netz auf einen Server im 192.168.1.0 Netz zugreifen will. Dabei friert die Verbindung einfach ein wenn ich einen längeren Output habe und nichts reagiert mehr. Laut meiner Recherchen liegt es am genau gleichen Problem mit der MTU.

Hat hier jemand eine elegante Lösung? Kann ich die MTU irgendwie auf der FritzBox konfigurieren? Ich finde dazu leider keine Infos.

Liebe Grüße,
balistox

 

[PeterPawn]

Etwas mehr Info wäre schon nötig ... ich tippe mal darauf, daß eine der beiden Boxen auch noch an einem "komischen" Anschluß hängt, denn 1406 ist schon arg wenig, wenn da nur ESP in IPv4-Paketen verwendet wird. Normalerweise sollte das AVM-VPN die Pakete auf der Empfängerseite auch wieder zusammensetzen, wenn sie wirklich für die Übertragung fragmentiert werden mußten. Allerdings fragmentiert es eben auch bei der Länge, die es für den Tunnel annimmt ... ist das dann zu groß für die Transportverbindung, kommt es zu solchen Problemen.

Kandidaten für zusätzliche "Abschläge" beim übertragbaren Payload sind üblicherweise IPv6-Kapselung, wenn ein Anschluß DS-Lite verwendet oder PPP-Header, wenn es eine DSL-Verbindung mit PPPoE ist oder auch eine Mobilfunkverbindung (die verwenden auch gerne PPP) oder irgendwelche exotischen Kapselungen beim Provider. Auch braucht natürlich der UDP-Header bei NAT-Traversal zusätzlichen Platz - aber das sollte die Box eigentlich alles selbst ausrechnen können.

Für so einen IPSec-Tunnel bei AVM scheint PTMU-Discovery auch nicht zu funktionieren (vor der Auswertung von Länge und DF-Flags kommt wohl schon die Fragmentierung für den Tunnel) ... daß die entfernte Box bei LAN2LAN gar kein "echter Hop" ist (weil das am Routing vorbeiläuft), sieht man i.d.R. auch schon mit einem einfachen "traceroute" - und so ist das ja auch bei Dir (denn Deine entfernte FRITZ!Box hat ja sicherlich auch die 192.168.1.1 - zumindest nicht die .23).

Ohne entsprechende ICMP-Pakete funktioniert dann auch PMTU-Discovery nicht richtig - ich kann mich jedenfalls nicht entsinnen, daß bei mir mal irgendeine VPN-Verbindung unter "/proc/kdsld/dsliface/internet/ipsec/connections" etwas anderes als "0" für "pmtu" angezeigt hätte - das findet man notfalls auch in den Support-Daten, wenn man keinen Shell-Zugriff hat.

Mir fällt auch, wenn das wirklich an irgendeiner exotischen, zusätzlichen Kapselung liegt (6490 mit alter Provider-Firmware am DS-Lite war auch so ein Kandidat, wo die MTU von der Box falsch berechnet wurde und in der Folge VPN-Verbindungen nicht zu gebrauchen waren), kein wirklich gangbarer Weg ein, das einer FRITZ!Box noch nachträglich beizubiegen. Da ist dann der RasPi schon die richtige Stelle für einen solchen Eingriff ... man kann ja auch eine spezifische Route mit eíner MTU-Angabe setzen (ip route help), damit davon nicht alle Verbindungen vom/zum RasPi betroffen sind.

EDIT: Wobei man für IPv6 tatsächlich eine MTU einstellen kann ... aber das dürfte beim IPSec von AVM keine Rolle spielen, denn dieses kann nur IPv4 als Transportprotokoll verwenden.

 

[balistox]

Ja, dass eine der Boxen an einem exotischen Anschluss hängt kann ich bestätigen, nämlich die im 192.168.65.0 Netz. Diese hängt in einem DS-Lite CGN Netz.
Hier mein genaues Szenario:

A: Fritz!Box 7530
keine öffentliche IP (100.64.x.x - DS-Lite CGN)
Lokales Netz: 192.168.65.0

B: Fritz!Box 7490
öffentliche, statische IP (213.x.x.x)
Lokales Netz: 192.168.1.0

Würde es mir helfen wenn ich die MTU manuell auf der FritzBox A konfiguriere? Wenn ja, hätte das dann auch negative Auswirkungen auf die Internetverbindung nach außen?

Die manuelle Konfiguration der MTU bzw. einer Route auf den Clientrechnern ist für mich eher ein ungünstiger Workaround, da ich viele Clients habe wo ich das machen müsste und dies bei manchen wohl gar nicht möglich wäre (iOS Geräte, Spielekonsolen, ...).

 

[PeterPawn]

da ich viele Clients habe

Und die müssen alle über den VPN-Tunnel auf irgendetwas zugreifen? Sounds weird ... oder die Beschreibung läßt wichtige Infos aus. Erst der Tunnel dürfte es hier aber sein, der Pakete > MTU generiert ... ansonsten würdest Du das nicht nur bei der VPN-Verbindung, sondern schon bei jedem FTP- oder HTTP-Download merken an diesem Anschluß.

Wenn man die MTU an der Box mit CGN konfigurieren kann (ich weiß das nicht, AVM macht ja gerne die eine Einstellung von anderen abhängig), dann gilt das natürlich für alle Pakete, die über deren WAN-Anbindung laufen sollen. Und ja, das hat logischerweise auch Auswirkungen auf die Internet-Verbindung ... ansonsten würde man ja gleich überall mit MTU 1200 arbeiten und gut wäre es eben auch überall. Aber damit verschenkt man natürlich Platz in den Paketen und das Verhältnis zwischen Payload und Overhead (in Bytes) wird generell schlechter.

Eine MTU-Einstellung (das heißt ja nicht umsonst "Maximum Transmission Unit") begrenzt die Größe des L3-Payloads für ALLE Verbindungen ... aber das wäre i.d.R. auch gut so, weil diese MTU-Angabe ja nur die Realität dessen widerspiegelt, was tatsächlich "auf der Leitung" möglich ist.

Die spannendere Frage wäre hier ohnehin, warum die Größe nicht korrekt berechnet wird. Aber wenn die Einstellung möglich ist und tatsächlich auch Auswirkungen hat (immerhin muß das Fragmentieren durch die AVM-Implementierung die MTU dann auch noch korrekt berücksichtigen - die ganzen "Abschläge" dürfte sie (die Implementierung) auch selbst berechnen), dann kann man es ja darüber mal versuchen.

Ich glaube bloß nicht mal daran, daß man bei IPv4-CGN (denn das ist ja kein DS-Lite, wenn da IPv4-Adressen für die 7530 zugewiesen werden - DS-Lite steht i.d.R. für IPv6-Anschlüsse mit IPv4 über AFTR-Server und da hat der Router keine eigene IPv4, auch keine private bzw. für CGN reservierte) die MTU bei AVM konfigurieren kann - ob das ggf. über die "ar7.cfg" möglich ist, müßte ich selbst erst überlegen bzw. nachschauen. Nur macht letzteres gar keinen Sinn, wenn man die konkreten Angaben nicht kennt ... und ich würde hier meine "ar7.cfg" nicht einstellen.

Aber vielleicht findest Du selbst ja in der Box dann (irgendwo bei "dslifaces" würde ich mit der Suche beginnen und hoffen, daß diese Einstellung vom AVM-IP-Stack berücksichtigt wird) eine Einstellung, deren Name vielversprechend klingt. Ohne jede Menge Änderungen und eigene Tests (ob die Änderungen wirken, wie man es erwartet) geht das jedenfalls garantiert nicht ab, wenn es nicht doch eine MTU-Einstellung geben sollte, sowie die Firmware feststellt, daß hier ein IPv4-CGN auf der WAN-Seite verwendet wird - wie bereits geschrieben, gibt es bei AVM gerne mal Abhängigkeiten bei der Anzeige, die auf anderen Werten basieren.

 

[balistox]

Und die müssen alle über den VPN-Tunnel auf irgendetwas zugreifen? Sounds weird ... oder die Beschreibung läßt wichtige Infos aus.

Nunja, es geht da hauptsächlich um Zugriffe auf Speichermedien in dem jeweils anderen Netz (NAS Storage und Co.). Auf Fotos u.ä. würde ich schon gern auch bei Bedarf mittels Handy zugreifen können.

IPv4-CGN (denn das ist ja kein DS-Lite, wenn da IPv4-Adressen für die 7530 zugewiesen werden - DS-Lite steht i.d.R. für IPv6-Anschlüsse mit IPv4 über AFTR-Server und da hat der Router keine eigene IPv4, auch keine private bzw. für CGN reservierte)

Von meinem Provider habe ich damals die Information bekommen, dass die IPv4 Adresse nur eine "Komfortfunktion" ist und diese, wenn gewünscht, auch abgeschaltet werden kann. Wenn dies gemacht wird würde sich ein Gateway darum kümmern dass ich weiter auf IPv4 Hosts zugreifen kann. So deren Wortlaut.

Ich habe mal einen Screenshot von dem Webinterface der FritzBox A angehängt. In den IPv6 Einstellungen habe ich jedenfalls die Möglichkeit die MTU Einstellungen selbst vorzunehmen. Ich will nur vermeiden, allzu große Abstriche beim Surfen/Downloaden aus dem Internet machen zu müssen wenn ich hier selbst die Einstellungen übersteuere.


[Edit Novize: Bild gemäß den Forumsregeln geschrumpft]

 

[PeterPawn]

So deren Wortlaut.

Wenn das dann ein "echter" DS-Lite-Anschluß wäre, ist das gar keine sooo schlechte Idee - nur müßte man das eben erst mal testen und das heißt, daß man es notfalls auch wieder reaktivieren können sollte. Jedenfalls müßte die Berechnung der MTU (in aktueller Firmware) bei DS-Lite sauber funktionieren (sonst hätten wir hier vermutlich mehr Leute mit solchen Problemen) - da wäre das Abschalten der (eigenen) IPv4-Adresse zumindest mal einen Versuch wert.

Durch diese ist das FRITZ!OS halt der Ansicht, es wäre eine "native IPv4 connection" und kein Tunnel (mit per se geringerer MTU, denn auch IPv4-in-IPv4 braucht ja zusätzliche Daten im Paket - wobei außer dem Provider ja auch niemand so richtig weiß, was da noch mit den IPv4-Paketen in seinem Netz passiert) - die Auswertung der 100.64/10-Adressen als "private" hat bei AVM bisher jedenfalls nie so richtig geklappt und ich weiß nicht, ob sich das geändert hat; wenn ja, dann würde die Box z:B. das Einrichten einer DynDNS-Adresse verweigern bzw. zumindest warnen, daß es sich um eine nicht-erreichbare Adresse handelt.

Vielleicht reicht es sogar schon aus, wenn man die FRITZ!Box auf "Native IPv6-Verbindung verwenden" umstellt und IPv4 dann über den AFTR-Server macht (die Einstellung ist nur bei "Natives IPv6 verwenden" sichtbar - das ist einer der Fälle, die ich oben angesprochen hatte) ... nur weiß ich natürlich nicht, ob Dein Provider den AFTR-Server über DHCPv6 annonciert oder wie dessen Name/Adresse ist, wenn man den von Hand konfigurieren muß.

EDIT:

Auf Fotos u.ä. würde ich schon gern auch bei Bedarf mittels Handy zugreifen können.

Dann ist es halt komisch, wenn man im Thread-Titel nur von Git schreibt - das assoziiert das Problem ja nun eher mit einem bestimmten Service und nicht mit allem, was über die VPN-Verbindung geht und von Problemen, mit einem Handy irgendwelche Fotos vom NAS anzuzeigen, hattest Du gar nichts erwähnt.