Netzwerk-Blockade finden?

dettus

Bicycle User
Bei uns auf der Arbeit kriegt man fuer das Homeoffice entweder ein Fenster oder einen Apfel.
Ich finde beides doof, deswegen habe ich jetzt seit neuestem einen Apfel.

Dabei habe ich festgestellt, dass das Laden von den Intranetseiten extrem langsam ist. Manchmal kann ich zugucken, wie sich die Bilder Zeilenweise aufbauen.
Ich bin nicht der einzige, der das festgestellt hatte. Beim Windows-Rechner geht es deutlich flotter.

Natuerlich moechte ich rausfinden, wo diese Entschleunigung herkommt.
Liegt es am Browser?
Am Router?
Am DSL?
Am VPN?
Am Webserver?

Leider habe ich weder Ahnung von Apple, noch von Netzwerkperformance...
Habt ihr Tips?
 
Die Möglichkeiten, woran es scheitern könnte sind vielfältig.

Manche Wlan-Karten arbeiten - auch heutzutage - immer noch nicht richtig mit manchen Access Points zusammen (FritzBoxen sind hier oft problematisch, hatte selber über die Jahre schon oft das "Vergnügen", über verschiedene Modellreihen hinweg).
Oft half es in so einem Fall am fraglichen Laptop nen USB-WiFi (oder früher per PC-Card) zu stecken, dann gings auf einmal.

Wenns mit mancher Hardware (dem Fenster, wie du es nanntest) geht, und mitm Apfel nicht, dann könnte es ggf auf sowas hindeuten.

Teste doch auch mal auf bufferbloat, vom Apfel und vom Fenster aus.
 
Ist das langsam, wenn Du mit dem Rechner lokal in der Firma bist oder von remote ueber VPN?
Remote ueber VPN.


Die Möglichkeiten, woran es scheitern könnte sind vielfältig.

Manche Wlan-Karten arbeiten - auch heutzutage - immer noch nicht richtig mit manchen Access Points zusammen (FritzBoxen sind hier oft problematisch, hatte selber über

Teste doch auch mal auf bufferbloat, vom Apfel und vom Fenster aus.
WLAN kann man als Fehlerquelle ausschliessen. Glaube ich... Ich bin am Arbeitsplatz zwar kabelgebunden, aber keine Ahnung was der Apple macht.
 
Haben die auch dieses Privacy-DNS-Müll krams den auch die iphones haben? Wenn ja würde ich das mal zuerst ausschalten.

Sonst bieten die meisten Browser mit F12 einen Debug-Modus für Webseiten wo man ua sehen kann was wie, wieschnell geladen wird.

Da sieht man dann schonmal obs am Netzwerk liegt und wenn ja wo oder es eher nen Problem der dastellung ist.

Welchen Browser verwendest du denn? Hast du schon einen anderen getestet? Der Safari ist imho recht gammlig, des auf meinen iphone sogar ober-gammlig im vergleich zu firefox & chrome auf android.

1673447951329.png
 
Und schau mal, ob der Mac denkt, dass er IPv6 hat und das ueber das VPN eben nicht geht, dann hast Du da immer ipv6-prefer-timeout scheiss am hacken.
 
WLAN kann man als Fehlerquelle ausschliessen. Glaube ich... Ich bin am Arbeitsplatz zwar kabelgebunden, aber keine Ahnung was der Apple macht.
Ah, sorry, dann bin ich von falschen Voraussetzungen ausgegangen.
Die Möglichkeiten, woran es scheitern kann sind aber immer noch vielfältig :D
Was mir dazu noch einfiele:
  • ne leicht zu große/zu kleine MTU irgendwo aufm Weg; OS-Abhängig?
  • doch bufferbloat (teste das am Besten mal, mittels der Webseite oben)
  • Apfel wird aufm Transportweg anders behandelt als Fenster bzw bekommt nen ganz anderen Weg (nicht lachen, gabs alles schon)
  • Ist der Apfel bei dir ohne VPN genauso schnell mit dem Seiten laden (Internet, nicht Intranet) wie es ein Fenster wäre (also definitiv nur lahm wenn VPN im Spiel)?
 
Vor einiger zeit hattest Du den einen Glasfaser-Thread gestartet, und wenn ich mich richtig erinnere ging der so zu Ende, daß Du nun über Glasfaser angeschlossen bist.

Ich habe seit einigen Monaten auch Glasfaser und beim Wechsel vom Internet via TV-Kabel auf Glasfaser hatte sich auch der Verbindungsaufbau vom einfachen DHCP auf PPoE geändert. Mein FreeBSD-Home-Server macht die PPoE-Anmeldung via net/mpd5, und der ist auch der Gateway in’s Internet für alle internen Clients. Bei allen Systemen (FreeBSD, macOS, iOS, Android und Windows) mußte ich die MTU von 1500 auf 1492 umstellen, damit die flüssig ins Internet kamen.

Nun, wie ist denn Deine Netzanbindung und welches VPN-System benutzt ihr. Bei meinen Macs und iPhones funktioniert seit eh und je L2TP/IPsec am besten. Windows macht da viel mehr Probleme.
 
Bei einem ordentlichen Netzwerkaufbau wird hinter dem Kabelmodem eine eigene Hardware-Firewall betrieben. Echte BSD-Fans nutzen dazu Vanilla-FreeBSD, OPNsense oder PFsense. Netzwerkdatenverkehr mit dumpcap am entsprechenden LAN- oder WAN-Port dieser Hardware-Firewall aufzeichnen und in Wireshark auswerten. Alternativ kann der Netzwerkdatenverkehr auch per "Port Mirroring" an einem Switch aufgezeichnet werden. Siehe dazu:


Alles andere ist Kaffeesatzlesen...

Nebst den Hinweis auf die üblichen "Verdächtigen" wie:
  • zu hohe Paketverlustrate
  • Path-MTU < 1500 Byte
  • ICMP-blockierender Router oder Firewall
  • Drosselung oder Blockierung von fragmentierten IP-Pakete
  • Fehlkonfiguration der VPN-MTU bei Internetanschlüssen mit einer Path-MTU < 1500 Byte
  • Für Glasfaser-Internetanschlüsse zu langsame Hardware-Firewall
  • Auf UDP-Datenpakete basierende VPN-Lösung ohne Path MTU Discovery”-Verfahren (PMTUD)

möchte ich nachfolgend auf das Thema "ECN" eingehen. Hier mal "eine Ladung" Links zu den üblichen "Verdächtigen". Vielleicht hilft dieser Lesestoff weiter:




Eine Eigenart von Apple-Betriebssystemen (MacOS, iOS, tvOS) ist die standardmässig aktive Unterstützung von ECN. Siehe dazu:



Tritt ein Apple-Produkt auf einen nicht-ECN-fähigen Internetanschluss, kann dies zu "bizarren" Problemen führen. Gegen Bufferbloat verwende ich den Raspberry Pi als "Traffic Shaper", wie es unter:


beschrieben ist. Da die Internetanschlüsse über das Fernsehkabelnetzwerk (EuroDOCSIS) generell nicht ECN-fähig sind, verwende ich die iptables-Firewallregel:

-A POSTROUTING -o eth0.14 -p tcp -m conntrack --ctstate NEW -j ECN --ecn-tcp-remove

zum Ausfiltern der "ECN capable"-Flags in den TCP SYN-Datenpakete (von Apple-Produkten). Die genaue Wirkungsweise dieser iptables-Firewallregel kann man in # man iptables-extensions nachlesen. Die Verwendung eines "Traffic Shaper" ist generell an jedem stationären Internetanschluss zu empfehlen. Der zur Zeit beste unter FreeBSD erhältliche und im Produktiveinsatz einsetzbare "Traffic Shaper" ist der fq_codel. Siehe dazu:

Beim Einsatz eines "Traffic Shaper" ist in der entsprechenden man-page nachzuschlagen, ob dieser "Traffic Shaper" standardmässig ECN verwendet oder nicht. Muss der "Traffic Shaper" eine TCP- oder UDP-Netzwerkverbindung drosseln, so signalisiert er dies bei aktivem ECN mit der Meldung “Congestion experienced” (CE) im IP-Paket oder bei inaktivem ECN mit dem Verwerfen des IP-Pakets (DROP). Verworfene oder verfälschte IP-Datenpakete haben bei TCP-Verbindungen die gleiche Auswirkung wie eine zu hohe Paketverlustrate. Es kommt zu einer Sendewiederholung (TCP-Retransmission) und im Nachgang zu einer Drosselung der Datenübertragungsrate.
 
Zuletzt bearbeitet:
Bei einem ordentlichen Netzwerkaufbau wird hinter dem Kabelmodem eine eigene Hardware-Firewall betrieben. Echte BSD-Fans nutzen dazu Vanilla-FreeBSD, OPNsense oder PFsense. Netzwerkdatenverkehr mit dumpcap am entsprechenden LAN- oder WAN-Port dieser Hardware-Firewall aufzeichnen und in Wireshark auswerten. Alternativ kann der Netzwerkdatenverkehr auch per "Port Mirroring" an einem Switch aufgezeichnet werden. Siehe dazu:

Junge, schreib doch einfach: "Wenn die Basics nichts bringen, mach nen Port Mirror und schneide mal den Datenverkehr mit, alternativ auf dem router" anstelle so einer wall oft text.

(In mehr als 95% aller fälle dürfte es auch reichen einfach lokal mitzuschneiden)

(Wie kommts du eigentlich auf Kabel-Internet / Kabel Modem?)

Nicht finden wirst du da so aber fehler die nicht im Netz sondern anderso zu suchen sind (Browser ohne Hardwarebeschleunigung etc)
 
Da die Internetanschlüsse über das Fernsehkabelnetzwerk (EuroDOCSIS) generell nicht ECN-fähig sind, verwende ich die iptables-Firewallregel:

-A POSTROUTING -o eth0.14 -p tcp -m conntrack --ctstate NEW -j ECN --ecn-tcp-remove

zum Ausfiltern der "ECN capable"-Flags in den TCP SYN-Datenpakete (von Apple-Produkten).
Ich habe einen Kabel-Internetanschluss (EuroDOCSIS) und dieser Internetanschluss ist ECN-fähig. Ich benutze das (absichtlich) gesetzte ECN-Flag als Kriterium/Bedingung, ob eine NEW-Verbindung (aus dem Internet zum Server) zustande kommen kann oder nicht zustande kommen kann.
 
Zurück
Oben