Moin, Port 443 sollte offen sein, da ansonsten kein Gerät mehr ohne einkonfigurierten HTTPS-Proxy mehr rauskommt. Port 80 kann auch offen sein, da der squid ein transparenter Proxy ist und m.e. nach den Port 80 Traffic filtert.
VG Yannik Am 22.05.2015 um 23:11 schrieb Juergen Engeland: > Hallo Michael, > > kann es sein, dass Deine WLAN-Clients am Proxy vorbei surfen? > Sind Port 80 und 443 auf IPFire von BLAU nach ROT dicht? > > In unserer "WPA-RADIUS von BLAU"-Lösung "beißt" der URL-Filter zu. > Wenn Du möchtest, schicke ich Dir gern unsere Firewallregeln per PM. > > Gruß Jürgen > > Am 22.05.2015 um 13:30 schrieb Michael Hagedorn: >> Hallo. >> Heute kam mir eine weitere Vertretungsstunde (ausnahmsweise) wie >> gerufen: Ich konnte mit der Klasse den Zugang zum WLAN mit Coovachilli >> und "neuem" disconnect-Befehl testen..... >> >> Hier erste Ergebnisse: >> >> 1.) Die Klasse war *begeistert*, dass es das nun gibt. >> >> 2.) Trotz Handy-Verbots war die Smartphone-Dichte bei 100%! >> *Ausgeschaltet* in der Tasche waren 0% -- das aber >> nur am Rande... >> >> 3.) Die Schüler konnten sich ordnungsgemäß am Coovachilli anmelden und >> danach surfen. Weiterleitung, Freigabe per SchuKo und Login >> funktionierten also super. >> Die VM mit dem Coovachilli ging nicht höher als ~20% Last; die >> AccesPoints zogen auch unter Volllast nie mehr als 13 Watt... >> >> 4.) Jetzt kommt's aber: Die Smartphones durften mehr als sie können >> sollten: Es war KEIN Problem auf facebook und Co zu gelangen, obwohl >> diese Seiten geblockt sind. Wir haben hier sowohl den URL-Filter aktiv >> als auch OpenDNS eingesetzt. Der Unifi-Controller selbst gelangt NICHT >> auf diese Seiten und wird erfolgreich geblockt -- die Smartphones aber >> nicht! Woran kann das liegen? >> (bei http:// erscheint normalerweise die IPFire-Sperre und >> bei httpS:// die OpenDNS-Sperre) >> Benutzen z.B. die Facebook-/youtube-Apps andere Ports/Protokolle als der >> Browser? Oder trifft Punkt 6.) zu? >> >> 5.) Ich habe das "disconnect-Script" (V1.7) ausprobiert -- und war damit >> zu 99% erfolgreich: Eine Userin blieb aus unerklärlichen Gründen >> weiterhin online. Der disconnect-Befehl wurde aber angeblich akzeptiert >> -- dennoch erschien sie weiterhin (auch nach mehrmaligen Versuchen) bei >> den verbundenen Usern. Rausgeflogen ist sie erst, als die Session-Time >> abgelaufen ist. Wie kann das sein?? >> >> 6.) Nach dem "disconnect" behaupteten einige Schüler, auch weiterhin >> online zu sein -- zum Beispiel im Google-PlayStore. Zusammen mit dem >> Zugriff auf eigentlich gesperrte Seiten frage ich mich, ob der >> Coovachilli vielleicht irgendwas mit IPv6-Adressen macht oder diese >> durchläßt?? In unserer Fritzbox (Verbindung zum Internet) ist IPv6 >> deaktiviert -- der IPFire dürfte das eigentlich auch nicht weiterleiten, >> oder? Daher kommt eigenlich nur noch der Coovachilli in Frage -- wird da >> evtl ein IPv6 --> v4 Tunnel oder sowas aufgemacht oder wie kann man das >> sonst erklären??? >> >> 7.) Die Unifi-APs sind genial und haben locker die ganze Klasse >> versorgt. Es sollte absichtlich viel Traffic erzeugt werden, was den >> Schülern natürlich problemlos gelungen ist... >> >> Anregungen? Ideen? Wie offen ist euer WLAN für Schulklassen? >> >> Michael >> >> >> >> >> _______________________________________________ >> linuxmuster-user mailing list >> [email protected] >> https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user >> > _______________________________________________ > linuxmuster-user mailing list > [email protected] > https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user _______________________________________________ linuxmuster-user mailing list [email protected] https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user
