Re: IPv6 und fehlende Antwortpakete

2019-04-10 Diskussionsfäden Christian Perle
Hallo Konrad,

On Wed, Apr 10, 2019 at 10:13:26 +0200, Konrad Rosenbaum wrote:

> Ist ein DSL-Link oder sowas dazwischen? Dann wäre die Path-MTU maximal
> 1492.
> 
> Hier gibt es einen netten Überblick:
> 
> http://www.nwlab.net/art/mtu/mtu.html

Und falls ICMPv6 packet too big korrekt zugestellt werden, kann man
die Path-MTU auch mit tracepath (Debian-Paket: iputils-tracepath)
ermitteln.

$ tracepath 

Das sollte natuerlich auf einem Client im LAB gemacht werden, weil
bei den Clients im LAN die lokale MTU (Interface) schon auf dem
IPv6-Minimum (1280) sitzt.

Gruss,
  Christian
-- 
Christian Perlechris AT linuxinfotag.de
010111  http://chris.silmor.de/
101010  LinuxGuitarKitesBicyclesBeerPizzaRaytracing



Re: IPv6 und fehlende Antwortpakete

2019-04-10 Diskussionsfäden Konrad Rosenbaum

Hi,

On 4/10/19 9:41 AM, Christian Perle wrote:



Nun ist es so dass Clients aus dem einen Netz Probleme mit HTTPS haben und
die des anderen Netzes nicht.

Wohl eher mit grossen Paketen, die vom Server kommen.




Das SYN-Paket in lan.dump wird mit mss 1220 gesendet, von der
Interface-MTU 1280 abgeleitet, die Serverseite antwortet mit mss 1440.
Damit muessen sie sich auf der kleineren Wert (1220) einigen, der dann
fuer *beide* Richtungen der TCP-Verbindung benutzt wird.

Das SYN-Paket in lab.dump wird mit mss 1440 gesendet, abgeleitet von der
Interface-MTU 1500. Da der Server auch mss 1440 verwendet, sind fuer
diese TCP-Verbindung groessere Pakete erlaubt, die dann wahrscheinlich
irgendeinem Router auf der Strecke vom Server zum Client zu gross
werden.


Ist ein DSL-Link oder sowas dazwischen? Dann wäre die Path-MTU maximal 1492.


Hier gibt es einen netten Überblick:

http://www.nwlab.net/art/mtu/mtu.html



    Konrad




Re: IPv6 und fehlende Antwortpakete

2019-04-10 Diskussionsfäden Christian Perle
Hallo Ronny,

On Tue, Apr 09, 2019 at 11:47:40 +0200, Ronny Seffner wrote:

> ich habe hier einen Router mit 2 NIC, die je einen IPv6-Adressbereich
> beziehen und an Clients dahinter verteilen.
> 
> Nun ist es so dass Clients aus dem einen Netz Probleme mit HTTPS haben und
> die des anderen Netzes nicht.

Wohl eher mit grossen Paketen, die vom Server kommen.

[...]
> Zusätzlich verteile ich die Netzinformation für die dahinterliegenden
> Clients mit radvd wie folgt:
> 
> interface eth0 {
> AdvSendAdvert on;
> AdvManagedFlag on;
> AdvOtherConfigFlag on;
> AdvDefaultPreference high;
> AdvLinkMTU 1280;
[...]
> interface eth1 {
> AdvSendAdvert on;
> prefix 2a00:fda0:6:cd10::/64 {

Ohne radvd besonders gut zu kennen faellt mir auf, dass Du nur fuer
eth0 (LAN) die Link-MTU der Clients auf 1280 senkst, bei eth1 (LAB)
tust Du das nicht. Entsprechend setzen die Clients im LAN ihre
Interface-MTU auf 1280, waehrend die Clients im LAB die Interface-MTU
beim Default, also 1500 belassen.

> Nennen wir das Netz hinter eth0 LAN und das hinter eth1 LAB.
> Auf mindestens einen Webserver im WAN mit IPv6 habe ich Zugriff. Daher hier
> mal die Paketmitschnitte aus Sicht dieses Webservers, wenn eine Anfrage aus
> dem LAN kommt und eine aus LAB.

TCP handelt beim Verbindungsaufbau die mss (maximum segment size)
zwischen Client und Server aus.

Das SYN-Paket in lan.dump wird mit mss 1220 gesendet, von der
Interface-MTU 1280 abgeleitet, die Serverseite antwortet mit mss 1440.
Damit muessen sie sich auf der kleineren Wert (1220) einigen, der dann
fuer *beide* Richtungen der TCP-Verbindung benutzt wird.

Das SYN-Paket in lab.dump wird mit mss 1440 gesendet, abgeleitet von der
Interface-MTU 1500. Da der Server auch mss 1440 verwendet, sind fuer
diese TCP-Verbindung groessere Pakete erlaubt, die dann wahrscheinlich
irgendeinem Router auf der Strecke vom Server zum Client zu gross
werden.

Gruss,
  Christian
-- 
Christian Perlechris AT linuxinfotag.de
010111  http://chris.silmor.de/
101010  LinuxGuitarKitesBicyclesBeerPizzaRaytracing