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 >> [email protected] >> https://lists.funkfeuer.at/mailman/listinfo/wien > > LG > Erich > -- > Wien mailing list > [email protected] > https://lists.funkfeuer.at/mailman/listinfo/wien
-- Wien mailing list [email protected] https://lists.funkfeuer.at/mailman/listinfo/wien
