MarcoMeter
Anmeldungsdatum: 8. Mai 2015
Beiträge: 15
|
Hallo zusammen, bei folgendem Problem bin ich ziemlich überfragt und hoffe auf etwas Unterstützung. Auf einem Serverrack an meiner Hochschule habe ich Ubuntu Server 16.04.1 64bit installiert. Während der Installation habe ich OpenSSH mitinstallieren lassen. Über die public IP des Servers greife ich über das Intranet auf den Server via SSH zu. Vom Internet aus ist der Port SSH zu, also ist dieser nur vom Intranet erreichbar (die Firewalls des Hochschulnetzwerkes wurden so konfiguriert). Nach dem ich apt-get update laufen lassen habe und Docker installiert habe ist der Server hängen geblieben. Hier eben die Befehle die ich nach der Installation unmittelbar ausgeführt habe: | sudo apt-get update
sudo apt-get install apt-transport-https ca-certificates
sudo apt-key adv --keyserver hkp://p80.pool.sks-keyservers.net:80 --recv-keys 58118E89F3A912897C070ADBF76221572C52609D
apt-cache policy docker-engine
sudo apt-get install linux-image-extra-$(uname -r) linux-image-extra-virtual
sudo apt-get install docker-engine
|
Nachdem Neustart (kurz nach dem Crash) geht der Zugriff vom Internet aus, aber nicht vom Intranet. ICMP Pakete gehen ein, aber nicht wieder raus ins Intranet. Die Fehlermeldung des Crashs besagt (siehe Screenshot): EXT4-fs (sdb1): VFS: Can't find ext4 filesystem Bei dem Serverrack handelt es sich um einen Dell PowerEgde R320. Interessant ist auch, dass genau dieses Problem bei der letzten Installation (von vor zwei Wochen) aufgetreten ist. Da war dann aber schon docker und der LAMP Stack isntalliert. Da kam der Crash während der Nutzung des nano Editors aufgetreten. Die Neuinstallation hat jedenfalls den Crash reproduziert. Von Relevanz könnte auch sein, dass das konfigurierte logische Raid1 Laufwerk nicht während der Installation angezeigt wird, sondern nur drei verfügbare physische Platten. Ubuntu habe ichd ann auf sda installiert und habe es automatisch patritionieren lassen. Gruß
Marco
- Bilder
|
MarcoMeter
(Themenstarter)
Anmeldungsdatum: 8. Mai 2015
Beiträge: 15
|
Ich habe nun zum 3. Mal Ubuntu neuinstalliert. Dieses Mal habe ich nginx zuerst installiert - keine Probleme. Bei der Dockerinstallation kam das System dann wieder zum Hängen mit den selben Folgen (kein Zugriff via Intranet, aber Internet schon). Das klingt zunächst mal wie dieses Docker Issue https://github.com/docker/docker/issues/23347 . In der ersten Installation kam es zu dem Vorfall erst Stunden später nach der Dockerinstallation. Jetzt konnte insgesamt zwei Mal während der Dockerinstallation reproduziert werden. Ich werde nun mal Docker von der Platte schubsen und die Ansätze der Kommentare des Issues verfolgen.
|
misterunknown
Ehemalige
Anmeldungsdatum: 28. Oktober 2009
Beiträge: 4403
Wohnort: Sachsen
|
Du hast überhaupt keine Informationen zum Netzwerksetup gegeben. Warum nicht? Was sagt:
$ ip a
$ ip l
$ ip r
$ iptables -nvL
Gibt es eine Hardware-Firewall, die irgendwas blockt?
|
MarcoMeter
(Themenstarter)
Anmeldungsdatum: 8. Mai 2015
Beiträge: 15
|
Docker fügt Regeln zu den iptables hinzu. Das geschieht immer dann wenn Docker gestartet wird. Ich gehe mal stark davon aus, dass diese Regeln die Antworten ins Intranet unterbinden. Wie gesagt kommt der Zugriff aus dem Internet gibt es keine Probleme. Ich habe jetzt den Kernel noch aktualisiert von 4.4.0-36-generic auf 4.6.4-040605-generic. Bei der Durchführung der Installation kommt wieder die Fehlermeldung, dass das Ext4 Filesystem nicht gefunden werden kann (siehe Screenshot). Diese Fehlermeldung kam auch während der Dockerinstallation. Kann mir vielleicht jemand dazu die Hintergründe erläutern? Ich kan mir da kein Bild von machen, ob das jetzt ein Problem ist oder nicht. In einem weiteren Screenshot habe ich die Iptables und weiteren Netzwerkkonfigurationen angehangen. Wenn die Regeln dafür verantwortlich sind, dass keine Pakete zurück ins Intranet gehen, wie kann ich dann die Regeln so modifizieren, dass wieder jeglicher Verkehr durchgelassen wird?
- Bilder
|
misterunknown
Ehemalige
Anmeldungsdatum: 28. Oktober 2009
Beiträge: 4403
Wohnort: Sachsen
|
MarcoMeter schrieb: Docker fügt Regeln zu den iptables hinzu. Das geschieht immer dann wenn Docker gestartet wird. Ich gehe mal stark davon aus, dass diese Regeln die Antworten ins Intranet unterbinden. Wie gesagt kommt der Zugriff aus dem Internet gibt es keine Probleme.
Zumindest werden keine Pakete durch die Regel betroffen, sonst würde man das sehen (pkts, bytes). Auf der anderen Seite werd ich aus den Regeln nicht wirklich schlau.
Ich habe jetzt den Kernel noch aktualisiert von 4.4.0-36-generic auf 4.6.4-040605-generic. Bei der Durchführung der Installation kommt wieder die Fehlermeldung, dass das Ext4 Filesystem nicht gefunden werden kann (siehe Screenshot). Diese Fehlermeldung kam auch während der Dockerinstallation. Kann mir vielleicht jemand dazu die Hintergründe erläutern? Ich kan mir da kein Bild von machen, ob das jetzt ein Problem ist oder nicht.
Was ist denn sda1? Dort findet er kein ext4-Dateisystem. Das ist sicherlich ein Problem.
In einem weiteren Screenshot habe ich die Iptables und weiteren Netzwerkkonfigurationen angehangen. Wenn die Regeln dafür verantwortlich sind, dass keine Pakete zurück ins Intranet gehen, wie kann ich dann die Regeln so modifizieren, dass wieder jeglicher Verkehr durchgelassen wird?
Wie gesagt: Es ist kein Traffic durch die Regeln betroffen. Hätte mich auch gewundert. Offenbar gibt es also schon vorher ein Problem, bevor die Pakete zum Server kommen. Die Default-Policy für INPUT, OUTPUT und FORWARD ist jedenfalls auf ACCEPT gesetzt.
|
MarcoMeter
(Themenstarter)
Anmeldungsdatum: 8. Mai 2015
Beiträge: 15
|
Laut fdisk -l ist sda1 die Patrition für Grub | Disk /dev/sda: 3.7 TiB, 4000787030016 bytes, 7814037168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: BBC0DA9C-BC19-4FD3-83E2-7CC5041F1D8E
Device Start End Sectors Size Type
/dev/sda1 2048 4095 2048 1M BIOS boot
/dev/sda2 4096 7797354495 7797350400 3.6T Linux filesystem
/dev/sda3 7797354496 7814035455 16680960 8G Linux swap
|
|
misterunknown
Ehemalige
Anmeldungsdatum: 28. Oktober 2009
Beiträge: 4403
Wohnort: Sachsen
|
Dann ist vermutlich das Dateisystem auf deiner Boot-Partition futsch. Das kannst du testen, indem du die Partition mal kurz aushängst und einen Filesystemcheck machst.
|
MarcoMeter
(Themenstarter)
Anmeldungsdatum: 8. Mai 2015
Beiträge: 15
|
Für den Start des docker daemons kann man konfigurieren, dass Docker die iptables nicht manipulieren darf. Ohne die von Docker definierten Chains und Rules bleiben Antworten ins Intranet aus, also kann ich die von Docker definierten Rules als Fehlerquelle ausschließen. Hier eine Referenz https://fralef.me/docker-and-iptables.html Ich versuche nun herauszufinden inwiefern die Network Bridge von Docker in diese Problematik verwickelt sein kann. Dazu vertiefe ich mich in die Dokumentation von Docker, welche Artikel zu den Netzwerkthemen bereithält. Hat vielleicht jemand ein paar Tipps, wie ich genau beobachten kann wo die Antwort verworfen wird? edit: Scheinbar gehen die Pakete verloren, bevor diese den dazugehörigen Dienst erreichen. Mittels tcpdump sehe ich, dass die Anfrage über den Port eingehen. Wenn ich dann beim nginx das access.log mir angucke, dann sehe ich dort keine neuen Einträge, wenn vom Intranet versucht wurde den Dienst zu erreichen. Also zwischen Port und Dienst gehen wohl die Anfragen verloren.
|
misterunknown
Ehemalige
Anmeldungsdatum: 28. Oktober 2009
Beiträge: 4403
Wohnort: Sachsen
|
MarcoMeter schrieb: Ich versuche nun herauszufinden inwiefern die Network Bridge von Docker in diese Problematik verwickelt sein kann. Dazu vertiefe ich mich in die Dokumentation von Docker, welche Artikel zu den Netzwerkthemen bereithält.
Was sagt denn ein traceroute ins Intranet bzw. Internet?
Hat vielleicht jemand ein paar Tipps, wie ich genau beobachten kann wo die Antwort verworfen wird?
Es gibt nur 2 Stellen, an denen das passieren kann: Auf dem System selbst oder an der vorgeschalteten Firewall. Beides lässt sich loggen.
Scheinbar gehen die Pakete verloren, bevor diese den dazugehörigen Dienst erreichen. Mittels tcpdump sehe ich, dass die Anfrage über den Port eingehen. Wenn ich dann beim nginx das access.log mir angucke, dann sehe ich dort keine neuen Einträge, wenn vom Intranet versucht wurde den Dienst zu erreichen. Also zwischen Port und Dienst gehen wohl die Anfragen verloren.
Läuft der nginx in einem Docker-Container?
|
MarcoMeter
(Themenstarter)
Anmeldungsdatum: 8. Mai 2015
Beiträge: 15
|
Im Intranet kann ich maximal nur das Gateway anpingen, da der Server sich in einem isolierten Sondernetz befindet. Die Pakete vom intranet kommen immer als Pakete von 172.17.1.1 rein. Irgendwo muss Docker diese verwerfen. nginx läuft auf dem Hostsystem. Es sind bisher keine Docker Contrainer eingebunden.
|
misterunknown
Ehemalige
Anmeldungsdatum: 28. Oktober 2009
Beiträge: 4403
Wohnort: Sachsen
|
MarcoMeter schrieb: Im Intranet kann ich maximal nur das Gateway anpingen, da der Server sich in einem isolierten Sondernetz befindet.
Es ging nicht um ping sondern um traceroute.
Die Pakete vom intranet kommen immer als Pakete von 172.17.1.1 rein. Irgendwo muss Docker diese verwerfen.
Docker kann keine Pakete verwefen. Es hat keine eigene Netzwerkverwaltung. Es arbeitet mit Interfaces und iptables im normalen System. Dort wird nichts geblockt. Dein Problem liegt also vermutlich im Gateway.
nginx läuft auf dem Hostsystem. Es sind bisher keine Docker Contrainer eingebunden.
Schon deshalb kann Docker nichts damit zu tun haben.
|
MarcoMeter
(Themenstarter)
Anmeldungsdatum: 8. Mai 2015
Beiträge: 15
|
misterunknown schrieb: Dein Problem liegt also vermutlich im Gateway.
Wenn das Problem beim Gateway liegt, warum funktioniert der Zugriff aus dem Intranet dann wieder sobald ich Docker deinstalliere und den Server neustarte?
Wie gesgat sobald Docker installiert ist kommen die Pakete aus dem Intranet bis an den Port an, aber nicht bei den Diensten, was dann eine Antwort verhindert. Verbindungen mit Initiatoren aus dem Internet gehen immer. Die Konstellation des Hochschulnetzes und von Docker scheint für mich die Problemzone zu sein. Ich versuche nochmal mit einem Kollegen von der IT alternative Netzwerkkonfigurationen zu besprechen. Ob mit oder ohne Docker, bei der traceroute zum Gateway ist nur ein hop von Nöten.
|
misterunknown
Ehemalige
Anmeldungsdatum: 28. Oktober 2009
Beiträge: 4403
Wohnort: Sachsen
|
MarcoMeter schrieb: Wenn das Problem beim Gateway liegt, warum funktioniert der Zugriff aus dem Intranet dann wieder sobald ich Docker deinstalliere und den Server neustarte?
Keine Ahnung, das eine hat mit dem anderen nichts zu tun. Wir haben ja schon herausgefunden, dass die systemeigene Firewall (iptables) nichts blockt, auch wenn Docker installiert ist. Von daher macht das keinen Sinn.
Wie gesgat sobald Docker installiert ist kommen die Pakete aus dem Intranet bis an den Port an, aber nicht bei den Diensten, was dann eine Antwort verhindert.
Das ist nicht möglich. Also im Sinne von: Es ist technisch/logisch nicht möglich, denn ein Dienst bindet den Port. Und wenn ein Paket die Firewall passiert hat, gibt es keine Instanz, die das Paket noch blocken könnte. Da stellt sich mir natürlich die Frage, wie du darauf kommst.
Verbindungen mit Initiatoren aus dem Internet gehen immer.
Das verstehe ich beispielsweise auch nicht. Das System hat nur eine private IP, das heißt Verbindungen aus dem Internet müssen auch durch das Intranet-Gateway. Das heißt Internet- und Intranetverbindungen nehmen den gleichen Weg.
Die Konstellation des Hochschulnetzes und von Docker scheint für mich die Problemzone zu sein.
❓
|
MarcoMeter
(Themenstarter)
Anmeldungsdatum: 8. Mai 2015
Beiträge: 15
|
misterunknown schrieb: MarcoMeter schrieb: Wie gesgat sobald Docker installiert ist kommen die Pakete aus dem Intranet bis an den Port an, aber nicht bei den Diensten, was dann eine Antwort verhindert.
Das ist nicht möglich. Also im Sinne von: Es ist technisch/logisch nicht möglich, denn ein Dienst bindet den Port. Und wenn ein Paket die Firewall passiert hat, gibt es keine Instanz, die das Paket noch blocken könnte. Da stellt sich mir natürlich die Frage, wie du darauf kommst.
Wenn ich mit tcpdump beispielsweise of Port 80 lausche und dort eingehende Pakete beobachte, aber beim nginx gar nicht ankommen, dann sieht das für mich so aus, dass die Pakete bis zum Port gehen und den Dienst nicht erreichen. Im access.log müsste die Anfrage registriert werden, genauso wie jene Anfragen aus dem Internet die erfolgreich gelockt werden. Ich werde möglichst bald testen ob das Problem auch besteht, wenn die Anfrage aus dem selben Sondernetz des Servers kommt. Das hängt dann auch von der Verfügbarkeit des IT-Personals ab, welche teils im Urlaub sind zurzeit. Der Zugriff auf den Serber erfolgt immer über die public IP, egal ob Internet- und Intranetverbindung. So wie ich das bisher verstanden habe geht die Verbindung aus dem Intranet zum Server nicht den Weg über das Internet, sondern wird von der Firewall der Hochschule umgeleitet.
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13933
|
MarcoMeter schrieb: Der Zugriff auf den Serber erfolgt immer über die public IP, egal ob Internet- und Intranetverbindung.
In so einem Fall muss das Gateway/Router/Firewall, Hairpin-NAT können, denn sonst funktioniert das nicht aus dem bzw. im Intranet. EDIT: Teste mal vor und nach dem Servercrash, ob der Server im Intranet mit seiner internen IP-Adresse (nicht die public) per arping (arp-Protokoll) erreichbar ist. Für tcpdump:
sudo tcpdump -c 50 -vvveni any arp
|