Probleme mit w-LAN (coovachilli)

Marcus · 22. März 2018 um 09:54

Ein herzliches Hallo an alle.

Seit ca. 1 Woche haben Kolleginnen und Kollegen und auch ich Probleme ins W-LAN unsere Schule zu kommen: wir bekommen eine IP, also können uns ins w-LAN einwählen, jedoch bekommen wir keinen Internetzugriff. Andere Kollegen versuchen das Captive Portal von coova aufzurufen und können sich nicht einmal in das Netzwerk einwählen.
Wir haben w-lan über coovachilli aufgespannt. Beteiligt sind verschiedene Accesspoints (aerohive, Cisco, …)

Ich kann nicht ganz zurückverfolgen, ob es am Poodle-Sicher machen unseres Linuxmusterservers liegen kann.

Die Probleme schienen, so weit ich nachvollziehen kann, nach der Modifikation von apache.conf mit
> SSLProtocol All -SSLv2 -SSLv3
> BrowserMatch “MSIE [2-6]”
> nokeepalive ssl-unclean-shutdown downgrade-1.0 force-response-1.0

MSIE 7 and newer should be able to use keepalive

BrowserMatch “MSIE [17-9]” ssl-unclean-shutdown

Header always set Strict-Transport-Security “max-age=15552000; includeSubDomains” – -- –

aufzutreten. Kann mir aber hier keinen Reim drauf machen, da eigentlich die config den Apache betreffen würde, und nicht den Coova. Oder?

Ich habe den Server Poodle-sicher gemacht um die immer wieder kommende Meldung von belwue, dass unser Server nicht poodle-Sicher sei, los zu werden. Das Loswerden hat auch geklappt.

Heute und gestern habe ich direkt auch auf unsere KVM-Sever geschaut, und hier sieht es so aus:

Kann dies auch ein Grund für den fehlenden Internetzugriff über w-LAN sein?

Da ich mir gestern erhofft habe, dass ein Neustart sämtlicher Server (coova, linuxmuster, ipfire) das Problem lösen könnte, habe ich auch alle Server neu gestartet.

In der Tat laufen nun auch wieder alle, keiner ist down und die Auslastungen aller Server sind im Normbereich. Und trotzdem bekomme ich keine IP vom linuxmusterserver über den coova.

Wenn es nun direkt am Poodle-Sichermachen lag, müsste ich die apache.conf nochmals modifizieren. Wie bekomme ich jedoch den Server Poodle-Sicher, oder müssten wir dann mit der Meldung von belwue leben?

Vielen Dank für eure Mühen und herzliche Grüße
Marcus

Michael · 22. März 2018 um 10:00

Hi Marcus.
Kennst du diesen Thread bzw hast du schon mal die Befehle abgesetzt, die dort genannt werden?
Vielleicht ist es bei dir ja genauso?

Michael

Marcus · 26. März 2018 um 05:42

Hallo Michael,

ich hab mal in /etc/network/if-up.d geschaut. Wir besitzen hier keine ethtool-Datei. Muss ich die anlegen, oder kann ich irgendetwas im coova nachinstallieren`

Grüße und schöne Ostern,

Marcus

Michael · 26. März 2018 um 07:44

Hi.
ethtool ist ein Programm. Einfach mit apt-get nachinstallieren.
Michael

baumhof · 26. März 2018 um 07:46

Hallo Marcus,

Ich kann nicht ganz zurückverfolgen, ob es am Poodle-Sicher machen
unseres Linuxmusterservers liegen kann.

… ich sehe da überhaupt keinen Zusammenhang.
Das eine ist ein Problem von den APs über den Coova durch den IPFire ins
INternet.
Da steht der Server überhaupt nicht im Weg.
Einzige Einflussnahme wäre, dass er bei der Authentifizierung quatsch
macht: aber auch das hat nichts mit poodle zu tun.

Heute und gestern habe ich direkt auch auf unsere KVM-Sever geschaut,
und hier sieht es so aus:

IMG_0058
https://ask.linuxmuster.net/uploads/default/original/2X/0/028a398c1e8bdf19b91159f8acfa8a920971797a.jpg

Kann dies auch ein Grund für den fehlenden Internetzugriff über w-LAN sein?

nein: die Fehlermeldung hab ich seit Jahren: einfach ignorieren.

Da ich mir gestern erhofft habe, dass ein Neustart sämtlicher Server
(coova, linuxmuster, ipfire) das Problem lösen könnte, habe ich auch
alle Server neu gestartet.

In der Tat laufen nun auch wieder alle, keiner ist down und die
Auslastungen aller Server sind im Normbereich. Und trotzdem bekomme ich
keine IP vom linuxmusterserver über den coova.

… was auch gut ist: der linuxmuster server soll dem Coova ja gar keine
IP geben: er ist ja schließlich nicht im selben Netz: oder steht dein
Coova in Grün?

Zu den IPs die Vergeben werden und von wem:

Grünes Netzwerk vom server
blaues Netzwerk vom IPFire
violettes Netzwerk vom coova

Dabei ist Blau nur zwischen Coova und IPFire und das violette ist
zwischenCoova und den APs.

Meine Frage ist nun als erstmal: was meinst du mit dem Satz:
„Und trotzdem bekomme ich keine IP vom linuxmusterserver über den coova.“

dass du keine IP im violetten Netz bekommst?
Dann läuft der integrierte DHCP auf dem coova nicht.

Besitzt den der coova selbst die (blaue) richtige IP?
Bei mir ist das 172.16.16.3

ifconfig
auf dem coova bringt da Erhellung.

LG

Holger

Marcus · 26. März 2018 um 09:39

Hallo Holger,

danke fürs Mitdenken.

… was auch gut ist: der linuxmuster server soll dem Coova ja gar keine
IP geben: er ist ja schließlich nicht im selben Netz: oder steht dein
Coova in Grün?

Das weiß ich nicht, da ich den Coova nicht eingerichtet habe. Aber ich denke, mein Vorgänger hat das schon richtig eingerichtet.

Ich kann nicht ganz zurückverfolgen, ob es am Poodle-Sicher machen
unseres Linuxmusterservers liegen kann.

… ich sehe da überhaupt keinen Zusammenhang.
Das eine ist ein Problem von den APs über den Coova durch den IPFire ins
INternet.
Da steht der Server überhaupt nicht im Weg.
Einzige Einflussnahme wäre, dass er bei der Authentifizierung quatsch
macht: aber auch das hat nichts mit poodle zu tun.

Das hat sich auch erledigt, da ich den kvm-Server demnächst poodle-Dicht machen muss. BelWü war nachdem ich linuxmuster dicht gemacht habe, immer noch nicht still. Die Verfolgung der von BelWü erkannten poodle-undichten Domain ergab dass der kvm-Server dicht gemacht werden muss. Werd ich in den Ferien an einem Tag machen.

Heute und gestern habe ich direkt auch auf unsere KVM-Sever geschaut,
und hier sieht es so aus:

IMG_0058
https://ask.linuxmuster.net/uploads/default/original/2X/0/028a398c1e8bdf19b91159f8acfa8a920971797a.jpg

Kann dies auch ein Grund für den fehlenden Internetzugriff über w-LAN sein?

nein: die Fehlermeldung hab ich seit Jahren: einfach ignorieren.

Das beruhigt mich ein wenig.

Zu den IPs die Vergeben werden und von wem:

Grünes Netzwerk vom server
blaues Netzwerk vom IPFire
violettes Netzwerk vom coova

Dabei ist Blau nur zwischen Coova und IPFire und das violette ist
zwischenCoova und den APs.

Bei uns scheint es ein wenig komplizierter: Wir haben wohl virtuell sowohl blaues als auch grünes Netz auf den APs da wir schulinterne Laptops über w-LAN direkt ins grüne Netz lassen. Frag mich aber bitte nicht nach der Switch-Konfiguration. Das hat bei uns MCT und mein Vorgänger gemacht.

Meine Frage ist nun als erstmal: was meinst du mit dem Satz:
“Und trotzdem bekomme ich keine IP vom linuxmusterserver über den coova.”

dass du keine IP im violetten Netz bekommst?
Dann läuft der integrierte DHCP auf dem coova nicht.

Besitzt den der coova selbst die (blaue) richtige IP?
Bei mir ist das 172.16.16.3

Die IP-Zuweisung scheint vollkommen OK zu sein:

2 DNS-Server mit 172.16.16.254

Bei der Gelegenheit hab ich das Sessiontimout auf 90 min. gestellt, so dass eine Doppelstunde im Netzwerk geblieben werden kann. Hab noch ein paar Mac-IDs eingetragen, die durchgeschleust werden sollen und habe den chilli nochmals neu gestartet.

Da ich nicht an der Schule bin, kann ich nun nicht überprüfen, ob der coova-restart geholfen hat. Ich hab dann noch einen Klon vom Coova auf KVM gemacht, werde wenn ich wieder an der Schule bin, noch die configs der VMS wegsichern und dann das Ubuntu unter dem coova auf das neuste via do-release-upgrade upgraden.

Danach hoffe ich, dass das w-LAN-Problem sich erledigt hat.

Grüße

Marcus

baumhof · 26. März 2018 um 11:30

Hallo Marcus,

Das hat sich auch erledigt, da ich den kvm-Server demnächst poodle-Dicht
machen muss. BelWü war nachdem ich linuxmuster dicht gemacht habe, immer
noch nicht still. Die Verfolgung der von BelWü erkannten
poodle-undichten Domain ergab dass der kvm-Server dicht gemacht werden
muss. Werd ich in den Ferien an einem Tag machen.

… bitte?
Auf deinem KVM Host läuft ein Webserver und der ist von außen erreichbar?
Das ist doch ein Scherz, oder?
Oder kennt jemand eine Bank die ihren Tresor auf dem Gehsteig stehen haben?

Da ich nicht an der Schule bin, kann ich nun nicht überprüfen, ob der
coova-restart geholfen hat. Ich hab dann noch einen Klon vom Coova auf
KVM gemacht, werde wenn ich wieder an der Schule bin, noch die configs
der VMS wegsichern und dann das Ubuntu unter dem coova auf das neuste
via do-release-upgrade upgraden.

Danach hoffe ich, dass das w-LAN-Problem sich erledigt hat.

… danach geht der coova mit Sicherheit nicht mehr…

Such mal im Forum nach coova
Da findest du Treads die beschreiben, wie man das Upgrade auf 14.04
macht, damit der coova danach noch läuft.

LG

Holger

Marcus · 26. März 2018 um 11:58

Hallo Holger,

… bitte?
Auf deinem KVM Host läuft ein Webserver und der ist von außen erreichbar?
Das ist doch ein Scherz, oder?
Oder kennt jemand eine Bank die ihren Tresor auf dem Gehsteig stehen haben?

anders kann ich mir die Meldung nicht erklären. Aber eins macht mich stutzig: den kvm-Host kann ich von außen nicht erreichen, jedoch meldet mir belwue, das irgendein server nicht poodle-dicht ist. Gehe ich dann auf die Adresse folgt folgendes:

Ich dachte, dass wäre unser kvm. Jedoch sieht es so aus, als würde es unser supermicro-Server sein, der von außen erreichbar ist. Wie krieg ich den poodle-Dicht?

Da ich nicht an der Schule bin, kann ich nun nicht überprüfen, ob der
coova-restart geholfen hat. Ich hab dann noch einen Klon vom Coova auf
KVM gemacht, werde wenn ich wieder an der Schule bin, noch die configs
der VMS wegsichern und dann das Ubuntu unter dem coova auf das neuste
via do-release-upgrade upgraden.

Danach hoffe ich, dass das w-LAN-Problem sich erledigt hat.

… danach geht der coova mit Sicherheit nicht mehr…

Das Vorgehen steht direkt in folgendem Thread: https://ask.linuxmuster.net/t/wie-mit-coova-verfahren/768/10

Gibts hier Erfahrungen, dass es nicht geht? Letzter Eintrag des Threads war wohl erfolgreiches Update auf 14.04 und der coova ging.

Grüße

Marcus

baumhof · 26. März 2018 um 12:39

Hallo Marcus,

… bitte?
Auf deinem KVM Host läuft ein Webserver und der ist von außen
erreichbar?
Das ist doch ein Scherz, oder?
Oder kennt jemand eine Bank die ihren Tresor auf dem Gehsteig stehen
haben?
anders kann ich mir die Meldung nicht erklären. Aber eins macht mich
stutzig: den kvm-Host kann ich von außen nicht erreichen, jedoch meldet
mir belwue, das irgendein server nicht poodle-dicht ist. Gehe ich dann
auf die Adresse folgt folgendes:

Ich dachte, dass wäre unser kvm. Jedoch sieht es so aus, als würde es
unser supermicro-Server sein, der von außen erreichbar ist. Wie krieg
ich den poodle-Dicht?

… das ist ja noch schlimmer: euer Servermanagement ist von außen
erreichbar …

Du solltest bei BelWü anrufen, dass die Port 80 und 443 für die IP des
Basboardmanagements des Servers abstellen im Cisco… aber pronto.

Euer KVM ist schon aus dem Internet erreichbar: aber eben nur über POrt
22 mit ssh und (hoffentlich) nur mit ssh keys.

    Da ich nicht an der Schule bin, kann ich nun nicht überprüfen,
    ob der
    coova-restart geholfen hat. Ich hab dann noch einen Klon vom
    Coova auf
    KVM gemacht, werde wenn ich wieder an der Schule bin, noch die
    configs
    der VMS wegsichern und dann das Ubuntu unter dem coova auf das
    neuste
    via do-release-upgrade upgraden.

    Danach hoffe ich, dass das w-LAN-Problem sich erledigt hat.

… danach geht der coova mit Sicherheit nicht mehr…
Das Vorgehen steht direkt in folgendem Thread:
Wie mit coova verfahren ? - #10 von Alex

Gibts hier Erfahrungen, dass es nicht geht? Letzter Eintrag des Threads
war wohl erfolgreiches Update auf 14.04 und der coova ging.

… OK, das hab ich wohl vergessen, dass Tobias geschrieben hat, dass das
auch so inzwischen geht.
Mach halt vorher ein Backup des Coova und probier es dann.

LG

Holger

alois · 26. März 2018 um 14:05

Hallo Marcus,

Das ist Euer Server. Ihr habt die IPMI-Schnittstelle nach außen geführt. Das kannst Du durch Abziehen des RJ45-Steckers dieser Schnittstelle abstellen.

Wenn Du den Server erreichen willst, warum nicht indem Du die Schnittstelle ins grüne Netz hängst. Dann verbindest Du Dich mit OpenVPN und kannst durch Aufruf der IPMI-Adresse den Server erreichen.

Gruß

Alois

Marcus · 27. März 2018 um 10:43

Hallo Holger, hallo Alois,

Die IPMI-Schnittstelle ist erstmal nicht mehr von außen erreichbar. Hab mit BelWü telefoniert und die haben die Internet-Ports geschlossen. Vielen Dank für Deine weitreichende Analyse, Holger.

Vielen Dank für Deinen Hinweis. Wenn ich unsere Switch-Programmierung bei der nächsten Gelegenheit verstanden habe (MCT möchte dies mir endlich zeigen), und linuxmuster von außen über VPN für meine Kolleginnen und Kollegen zugänglich gemacht habe, dann werd ich das auf jeden Fall machen. Man weiß ja nie, wenn man das IPMI mal braucht.

Vielen lieben Dank für Eure Hinweise. Mich erstaunt nur, dass das IPM schon mind. 2 Jahre offen war, und keiner das bemerkt bzw. geschlossen hat.

Aber dafür bin ich ja dann gekommen .

alois · 27. März 2018 um 12:52

Hallo Marcus,

ich habe das bei uns etwas anders gelöst.

Bei mir hängt die IPMI-Schnittstelle am internen Netz einer Fritzbox. Diese Fritzbox kann ich per Fritz Fernzugang erreichen. Ist der Zugang aufgebaut, kann ich die IP-Adresse der IPMI-Schnittstelle von Hand eingeben und den Server damit erreichen.

Der Nachteil beim Verfahren mit OpenVPN liegt darin, dass wenn der Server Down ist, dann erreicht man die IPMI-Schnittstelle nicht mehr.

Gruß

Alois

zefanja · 27. März 2018 um 13:13

Man kann OpenVPN ja auch auf einem anderen Server / Firewall (ähnlich deinem Fernzugang) laufen lassen.

vG Stephan

baumhof · 27. März 2018 um 13:20

Hallo Marcus,

Wenn Du den Server erreichen willst, warum nicht indem Du die
Schnittstelle ins grüne Netz hängst. Dann verbindest Du Dich mit
OpenVPN und kannst durch Aufruf der IPMI-Adresse den Server erreichen.
Vielen Dank für Deinen Hinweis. Wenn ich unsere Switch-Programmierung
bei der nächsten Gelegenheit verstanden habe (MCT möchte dies mir
endlich zeigen), und linuxmuster von außen über VPN für meine
Kolleginnen und Kollegen zugänglich gemacht habe, dann werd ich das auf
jeden Fall machen. Man weiß ja nie, wenn man das IPMI mal braucht.

VPN ist zu kompliziert für Kollegen:
ich verwende nextcloud
Wenn du das nicht hast/willst, dann zeig den KOllegen einfach horde3.
Da klickt man auf „Konto“ und dann auf „Dateimanager“ und kann ins Home
schauen und auch Daten bewegen (hoch/runter laden)

LG

HOlger

alois · 27. März 2018 um 13:44

Hallo Holger,

da liegt ein Missverständnis vor.

Ich meinte, wenn Marcus die IPMI-Schnittstelle erreichen will, dann wäre das eine Lösung ohne sie ins WWW zu hängen.

Gruß

Alois

baumhof · 27. März 2018 um 17:43

Hallo Alois,

da liegt ein Missverständnis vor.

nein

Ich meinte, wenn Marcus die IPMI-Schnittstelle erreichen will, dann wäre
das eine Lösung ohne sie ins WWW zu hängen.

er schrieb explizit: VPN für Kolleginnen und Kollegen…

LG

Holger