[Wien] Knoten gatt12

[Fabian Havlik]

Ok, danke für die Hinweise. 
Ich schau, dass ich diese Woche mal zu meinem Schrebergartenhaus fahr und mach mal eine IP anfrage. Ich probier auch tracepath und ping -s aus. Ich hoff dass sich das Problem lösen lässt, ansonsten meld ich mich nochmal!
LG Fabian. 


Am 12.10.2015 um 11:01 schrieb 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
> --
> Wien mailing list
> (spam-protected)
> https://lists.funkfeuer.at/mailman/listinfo/wien

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