Hallo,
KB19 ... Vielen Dank für das Stichwort. 
Wieder was dazu gelernt.
tuxmaster ... Ich habe deine Vorschläge umgesetzt. Du hast natürlich vollkommen Recht damit, dass es sinnvoll ist den Port zu verschieben um zumindest das Grundrauschen ein wenig zu reduzieren. Des weiteren habe ich IPv6 nun deaktivieren können. Ich werde diesen Zustand auch vorerst so belassen, da ich mich erst in das Thema IPv6 einarbeiten möchte bevor ich auf einem Produktivsystem damit arbeite. (Einlesen... Testserver im lokalen Netzwerk... etc...)
Skulduggery ... Ich habe den Master with Virtualization gewählt. Zuvor habe ich bewussten den netcup Support um Informationen bzgl. meines Vorhabens kontaktiert. Dieser hat mir bestätigt, dass eine Virtualisierung auf den Servern möglich ist.
Nachdem ich nun IPv6 deaktiviert und die sehr sinnvollen Vorschläge umgesetzt habe sieht meine iptables Ausgabe wie folgt aus:
Chain INPUT (policy DROP 91 packets, 7868 bytes)
pkts bytes target prot opt in out source destination
32 2384 f2b-SSH tcp -- any any anywhere anywhere tcp dpt:12345 #Mein neuer SSH Port
1 40 ACCEPT icmp -- any any anywhere anywhere icmp echo-request
2 168 ACCEPT icmp -- any any anywhere anywhere icmp echo-reply
0 0 ACCEPT tcp -- any any anywhere anywhere tcp dpt:5656
155 42393 ACCEPT udp -- any any anywhere anywhere udp spt:domain
0 0 ACCEPT tcp -- any any anywhere anywhere tcp spt:domain
1513 115K ACCEPT tcp -- any any anywhere anywhere tcp dpt:12345 #Mein neuer SSH Port
0 0 ACCEPT all -- any any anywhere anywhere ctstate RELATED,ESTABLISHED
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 18 packets, 1848 bytes)
pkts bytes target prot opt in out source destination
Chain SOLUSVM_TRAFFIC_IN (0 references)
pkts bytes target prot opt in out source destination
Chain SOLUSVM_TRAFFIC_OUT (0 references)
pkts bytes target prot opt in out source destination
Chain f2b-SSH (1 references)
pkts bytes target prot opt in out source destination
32 2384 RETURN all -- any any anywhere anywhere
Alles anzeigen
Leider habe ich weiterhin das Problem mit yum, dass selbiges die Spiegelserver nicht erreichen kann... folgende Ausgabe erhalte ich bei Eingabe von "yum update"
...
Could not get metalink https://mirrors.fedoraproject.org/metalink?repo=epel-6&arch=x86_64 error was
14: PYCURL ERROR 7 - "Failed to connect to 2607:f188::dead:beef:cafe:fed1: Das Netzwerk ist nicht erreichbar"
* base: ftp.halifax.rwth-aachen.de
* epel: mirror.imt-systems.com
* extras: centosmirror.netcup.net
* soluslabs: repo-france-rbx.solusvm.com
* updates: centosmirror.netcup.net
...
http://ftp.hosteurope.de/mirror/centos.org/6.6/updates/x86_64/repodata/repomd.xml: [Errno 14] PYCURL ERROR 7 - "Failed to connect to 2a01:488:10:1::50ed:888a: Das Netzwerk ist nicht erreichbar"
Versuche anderen Spiegel-Server.
Löse Abhängigkeiten auf
--> Führe Transaktionsprüfung aus
---> Package ncftp.x86_64 2:3.2.2-1.el5 will be aktualisiert
---> Package ncftp.x86_64 2:3.2.4-1.el6 will be an update
---> Package php-mcrypt.x86_64 0:5.3.2-3.el6 will be aktualisiert
---> Package php-mcrypt.x86_64 0:5.3.3-3.el6 will be an update
--> Abhängigkeitsauflösung beendet
Abhängigkeiten aufgelöst
=======================================================================================
Paket Arch Version Repository Grösse
========================================================================================
Aktualisieren:
ncftp x86_64 2:3.2.4-1.el6 epel 319 k
php-mcrypt x86_64 5.3.3-3.el6 epel 19 k
Vorgangsübersicht
================================================
Upgrade 2 Package(s)
Gesamte Downloadgrösse: 337 k
Ist dies in Ordnung? [j/N] :n
Beende nach Befehl des Benutzers
Alles anzeigen
Wenn ich die CHAIN Policy von DROP auf ACCEPT stelle und somit faktisch die Firewall deaktiviere läuft YUM ohne Fehler:
Geladene Plugins: fastestmirror
Einrichten des Aktualisierungsprozess
Determining fastest mirrors
epel/metalink | 24 kB 00:00
* base: mirror.informatik.hs-fulda.de
* epel: mirrors.n-ix.net
* extras: centosmirror.netcup.net
* soluslabs: repo-france-rbx.solusvm.com
* updates: centosmirror.netcup.net
base | 3.7 kB 00:00
base/primary_db | 4.6 MB 00:00
epel | 4.4 kB 00:00
epel/primary_db | 6.7 MB 00:00
extras | 3.4 kB 00:00
extras/primary_db | 31 kB 00:00
openvz-kernel-rhel6 | 2.8 kB 00:00
openvz-kernel-rhel6/primary_db | 9.2 kB 00:00
openvz-utils | 2.5 kB 00:00
openvz-utils/primary_db | 27 kB 00:00
soluslabs | 951 B 00:00
soluslabs/primary | 12 kB 00:00
soluslabs 42/42
updates | 3.4 kB 00:00
updates/primary_db | 4.4 MB 00:00
Löse Abhängigkeiten auf
--> Führe Transaktionsprüfung aus
---> Package ncftp.x86_64 2:3.2.2-1.el5 will be aktualisiert
---> Package ncftp.x86_64 2:3.2.4-1.el6 will be an update
---> Package php-mcrypt.x86_64 0:5.3.2-3.el6 will be aktualisiert
---> Package php-mcrypt.x86_64 0:5.3.3-3.el6 will be an update
---> Package solusvm-lighttpd.x86_64 0:1.4.35-3.onapp.el6 will be aktualisiert
---> Package solusvm-lighttpd.x86_64 0:1.4.36-1.onapp.el6 will be an update
---> Package solusvm-lighttpd-fastcgi.x86_64 0:1.4.35-3.onapp.el6 will be aktualisiert
---> Package solusvm-lighttpd-fastcgi.x86_64 0:1.4.36-1.onapp.el6 will be an update
--> Abhängigkeitsauflösung beendet
Abhängigkeiten aufgelöst
=====================================================================================
Paket Arch Version Repository Grösse
=====================================================================================
Aktualisieren:
ncftp x86_64 2:3.2.4-1.el6 epel 319 k
php-mcrypt x86_64 5.3.3-3.el6 epel 19 k
solusvm-lighttpd x86_64 1.4.36-1.onapp.el6 soluslabs 229 k
solusvm-lighttpd-fastcgi x86_64 1.4.36-1.onapp.el6 soluslabs 24 k
Vorgangsübersicht
====================================================
Upgrade 4 Package(s)
Gesamte Downloadgrösse: 590 k
Ist dies in Ordnung? [j/N] :n
Beende nach Befehl des Benutzers
Alles anzeigen
Woran liegt das? Ich finde den Fehler leider nicht. Fehlen eventuell noch Regeln in iptables?
Schon jetzt danke für Antworten!
Liebe Grüße
Frederic
