Doppelte NAT-MTU-Einstellung für das innere Netzwerk

890
noseratio

Ich habe ein Heimnetzwerk mit zwei Routern hintereinander. Der WAN-Port des äußeren Routers ist eine VDSL2-PPPoE-Verbindung mit einer aktiven IP-Adresse und einer MTU-Größe von 1492. Der WAN-Port des inneren Routers wird über DHCP als nur ein anderer Client im LAN-Netzwerk des äußeren Routers zugewiesen. Die Standard-MTU war standardmäßig 1500. Ich habe es auf 1492 geändert, um dem äußeren Router zu entsprechen.

Nun frage ich mich, ob es sinnvoll ist, die MTU-Größe für das innere Netzwerk weiter zu reduzieren. Würde das innere Netzwerk in diesem Szenario mit doppeltem NAT robuster machen?

0
Hast du einen Grund, NAT zu verdoppeln? Normalerweise ist es viel einfacher, das Netzwerk zu überbrücken und zu erweitern. Tim_Stewart vor 6 Jahren 0
@Tim_Stewart, der Grund ist meistens, dass meine arbeitsbezogenen PCs / VMs / Geräte hinter einer separaten Firewall von den restlichen Benutzern / Geräten meines Heimnetzwerks hinterlegt sind, diese aber immer noch sehen und darauf zugreifen können. noseratio vor 6 Jahren 0

2 Antworten auf die Frage

3
dirkt

NAT ändert lediglich die IP-Adressen / Ports in den Paketen, es enthält keine zusätzlichen Informationen (Header usw.) im Paket. Daher wird die MTU in keiner Weise reduziert, und es ist in Ordnung, dieselbe MTU zu haben.

Soll ich die WAN-MTU auf dem * inneren * Router noch auf 1492 einstellen? Oder bei 1500 lassen? noseratio vor 6 Jahren 0
MTU-Entdeckung kann schwierig sein, und ich bin kein Experte für alle Fälle, die schief gehen können oder die sogar mit verschiedenen MTUs funktionieren. Wenn bei abgehenden Paketen eine schlechte Leistung auftritt, sollten Sie als Erstes die MTU des inneren Routers auf 1492 setzen, um zu vermeiden, dass abgehende Pakete fragmentiert werden. Und es tut nicht weh, dies von Anfang an zu tun. Messen Sie im Zweifelsfall mit tcpdump usw., um zu sehen, ob etwas * fragmentiert wird. dirkt vor 6 Jahren 1
1
Nevin Williams

Während NAT die Paketgröße nicht erhöht (oder, genauer gesagt, die maximale Payload-Größe pro Paket verringert), ist dies häufig bei PPoE und anderen Tunnelprotokollen der Fall.

Die meisten modernen Betriebssysteme haben jedoch die in RFC1191 beschriebene Path MTU Discovery implementiert, die ausgehende Pakete optimal an die der kleinsten MTU einer beliebigen Verbindung zwischen dem sendenden Host und dem Ziel anpasst. Dazu wird DF bitin großen abgehenden Paketen (Nicht fragmentieren) festgelegt und nach einem ICMP-Fehler gesucht Fragmentation Needed.

In MacOS und anderen Unix-ähnlichen Betriebssystemen verfügt das pingDienstprogramm über mehrere Switches, mit denen Sie die DF bitGröße und die Größe der Payload festlegen und sogar einen Größenbereich durchlaufen können, um so effektiv eine MTU zwischen dem Quellhost und dem Ziel zu bestimmen. Es gibt 8 Bytes Overhead im ICMP Echo Request pingSende-Out und 20 Bytes Overhead im IP-Paket, wodurch die maximale Nutzlast von 1472 für ein Ping-Paket mit dem DF bitSet auf einer 1500-Byte-MTU-Schnittstelle festgelegt wird.

Sie können Ihre MTU niedriger einstellen, um diesen einen bestimmten Pfad auf eine sehr kleine Weise zu optimieren, im Gegenzug für eine etwas weniger optimale Paketgröße für jeden anderen Paketstrom, an dem der Host teilnimmt.

Wenn Sie also keine Probleme mit Dateiübertragungen haben, empfiehlt es sich, das Betriebssystem MTU automatisch mit MTU umgehen zu lassen.

[Nevin-Mac-Mini: ~] Nevin% Ping -c 1 -D -s 1472 192.168.2.1 PING 192.168.2.1 (192.168.2.1): 1472 Datenbytes 1480 Bytes von 192.168.2.1: icmp_seq = 0 ttl = 64 Zeit = 0,667 ms  --- 192.168.2.1 Ping-Statistiken --- 1 Pakete gesendet, 1 Pakete empfangen, 0,0% Paketverlust Umlauf min / avg / max / stddev = 0,667 / 0,667 / 0,667 / 0,000 ms [Nevin-Mac-Mini: ~] Nevin% Ping -c 1 -D -s 1473 192.168.2.1 PING 192.168.2.1 (192.168.2.1): 1473 Datenbytes ping: sendto: Nachricht zu lang  --- 192.168.2.1 Ping-Statistiken --- 1 Pakete gesendet, 0 Pakete empfangen, 100,0% Paketverlust
Vielen Dank für die Antwort, ich kenne PMTUD und habe sogar MSS Clamping auf meinem Router implementiert ([hier ist ein Follow-Up] (https://www.snbforums.com/threads/set-mtu-for-clients-in-lan) -wifi-wlan.42483 / # post-399938), aber ich habe immer noch gelegentliche Probleme mit HTTPS-Sites in Chrome / Win10. Ich werde MTU manuell über netsh konfigurieren und sehen, ob sich etwas ändert. noseratio vor 6 Jahren 0
Ich habe keinen Zugriff auf irgendwelche Windows-Boxen, um die neueste Implementierung von "ping" zu überprüfen, aber die MacOS / BSD-Version lässt die Größe mit den -g / -G-Flags mitschwenken, also `ping -D -g 1450 -G 1500 host.name` würde helfen. Beziehen sich Ihre Probleme auf das Senden von Daten (z. B. Hochladen von Bildern) oder Empfangen von Daten? Wenn letzteres, dann ist das mögliche MTU-Problem auf der Remote-Seite und fast außerhalb Ihrer Kontrolle: Stellen Sie sicher, dass Ihre Geräte ICMP-Fehlermeldungen senden können, wenn große Pakete empfangen werden. Nevin Williams vor 6 Jahren 1

Verwandte Probleme