[Wien] Knoten gatt12

[Erich N. Pekarek]

Hallo!
Am 2015-10-12 um 10:33 schrieb Adi Kriegisch:
> Hallo!
>
>> ich betreibe in einem Schrebergartenhaus den Knoten gatt12 mit der Antenne
>> NanoBeam M2.
> [...]
>> Jetzt hab ich folgendes Problem:
>> Eine Zeitlang konnte ich keine verschlüsselten Seiten aufrufen (https://).
>> Auch Google ging nicht. Dieses Problem scheint sich in Luft aufgelöst zu
>> haben, aber trotzdem gibts noch komplikationen. Ich kann einige Seiten
>> nicht öffnen, ich erkenn aber kein Muster darin. Also z.B.: kickstarter.com,
>> upc.at und noch ein paar andere funktionieren nicht.
> Dieses "Phänomen" konnte ich schon ein paar Mal beobachten, wenn irgendwo
> (ev. auch auf Zwischenknoten) die MTU verstellt ist und per Firewall ICMP
> geblocked wird (wegen MTU path discovery).
Dieses Problem ist bei NAT Trunks auch bei der Mobilfunkdatenübertragung 
allgegenwärtig.

Im Funkfeuer-Netz ist vermutlich bei einem oder mehreren Router 
Extern-Extern-NAT aktiviert. Das Blocken von ICMP ist dann nicht 
zwangsläufig die Ursache.
Das Problem liegt darin, dass die auf OpenWRT-basierenden 
Funkfeuer-Firmwares allesamt in der Standardeinstellung, wenn NAT 
aktiviert ist, jedes Paket - auch von öffentlichen IPs natten.

Wenn normal geroutet würde, müsste die/eine externe IP Deiner Nanobeam 
als Quelle einer Anfrage aufscheinen - Du kannst das unter zb
http://whatismyipaddress.com/de/meine-ip

prüfen.
Steht dort eine IP, die nicht Dir gehört, aber im Funkfeuernetz liegt, 
dann ist dieser Router die Ursache.

Der Betreiber muss dann in der 0xFF-Zone seiner Firewall unter 
"Erweitert" die Quellnetze für NAT eintragen. Das ist in der Regel sein 
internes LAN, das gem. RFC1918 10.0.0.0/8, 172.16.0.0/12 oder 
192.168.0.0/16 sein kann. Auch der APIPA-Range (Zeroconf) 169.254.0.0/16 
kann sinnvollerweise dort einzutragen, wenn das gewünscht ist.

Jede IP, die dann nicht einem dieser Ranges entspricht, wird normal 
geroutet.
Tritt das Problem nach der Korrektur noch bei einer weiteren IP auf, die 
nicht die Deine ist, hat ein weiterer Router dasselbe Problem. Dort 
würde dann üblicherweise auch die MTU Path Discovery fehlschlagen, wenn 
auf dem ersten Router ICMP nicht geblockt war.

> Der "Effekt" erklärt sich dadurch, daß alle Pakete, die 1500 Byte groß sind
> irgendwo unterwegs verworfen werden. Gerade HTTPS-Handshakes bestehen aufgrund
> des Schlüsselaustausches i.a. immer aus zumindest einem "vollen" 1500 Byte
> Paket; Web 17.0-Seiten laden üblicherweise ziemlich viel Javascript von
> irgendwelchen CDNs und das kommt dann natürlich auch nicht an...
> Ev. kommst Du mit tracepath und "ping -s" der Sache auf die Spur...
Detto mit OpenVPN über Mobilfunk...
Im Falle eines solchen Tunnels helfen üblicherweise die folgenden 
Parameter: tun-mtu 1500;fragment 1280;mssfix;
Der Tunnel würde dann maximal Fragmente mit 1280 Byte übertragen uz. 
fragmentiert. Intern wäre die MTU wie üblich 1500. Performanceverlust 
inklusive.
>
> Glg Adi
>
>
> --
> Wien mailing list
> (spam-protected)
> https://lists.funkfeuer.at/mailman/listinfo/wien

LG
Erich
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.funkfeuer.at/pipermail/wien/attachments/20151012/c815c73a/attachment.htm>