Toll.
Das nenne ich mal kompetente Hilfe. Und ich konnte dabei noch was lernen. Ich bedanke mich für Deine Mühe, Christian.
Gruß, Curio
Toll.
Das nenne ich mal kompetente Hilfe. Und ich konnte dabei noch was lernen. Ich bedanke mich für Deine Mühe, Christian.
Gruß, Curio
Ja, das ist es. Vielen Dank für Deine Hilfe, Christian.
Wie bist Du drauf gekommen? Durch Probieren? Ich habe nirgends eine brauchbare verbindliche Anleitung gefunden, wie man eine Regel für mehrere Ports erstellt. Alles nur sehr widersprüchlicher Kram.
Gruß Curio
Wow, das ging ja schnell, killerbees19.
Hatte ich vergessen zu erwähnen. Exakt diese Variante von Dir habe ich auch getestet. Mit dem selben Ergebnis. Diese Firewall-Regel wurde ebenso als Fehler abgelehnt.
Gruß, Curio
Hallo Gemeinde,
Ich betreibe einen KVM-Server mit Debian 8.4 und i-MSCP v1.2.17 als Webserver. Jetzt habe ich ein Problem mit dem Öffnen eines zusätzlichen https-Ports in iptables. i-MSCP benutzt in seinen neueren Versionen standardmäßig den Port 4443 für seine verschlüsselten Admin-Logins.
Ich benutze ein Firewall-Script mit folgender Funktion für https:
function service_https {
$IPT -A INPUT -p TCP -i eth0 --sport 1024: --dport 443 -m state --state NEW -j ACCEPT
$IPT6 -A INPUT -p TCP -i eth0 --sport 1024: --dport 443 -m state --state NEW -j ACCEPT
Einfügen wollte ich den zusätzlichen Port folgendermaßen:
function service_https {
$IPT -A INPUT -p TCP -i eth0 --sport 1024: --dport 443,4443 -m state --state NEW -j ACCEPT
$IPT6 -A INPUT -p TCP -i eth0 --sport 1024: --dport 443,4443 -m state --state NEW -j ACCEPT
Erhalte aber bei Einschalten der Firewall einen Fehler für https.
Habe ich irgend was verpasst? Ich dachte immer, mehrere Ports (außer Port-Ranges) werden durch kommaseparierte Listen realisiert.?
Ich habe es nun erst mal so geregelt, dass ich für jeden Port eine extra Rule erzeugt habe - nicht besonders elegant aber es funktioniert:
function service_https {
$IPT -A INPUT -p TCP -i eth0 --sport 1024: --dport 443 -m state --state NEW -j ACCEPT
$IPT -A INPUT -p TCP -i eth0 --sport 1024: --dport 4443 -m state --state NEW -j ACCEPT
$IPT6 -A INPUT -p TCP -i eth0 --sport 1024: --dport 443 -m state --state NEW -j ACCEPT
$IPT6 -A INPUT -p TCP -i eth0 --sport 1024: --dport 4443 -m state --state NEW -j ACCEPT
Aber es würde mich interessieren, worin mein Fehler in der ersten Variante liegt. Wäre schön, wenn mir hier jemand auf die Sprünge helfen könnte.
Gruß, Curio
@ A
Vielen Dank noch mal für Deine kompetente Hilfe, die DNS-Abfrage per dig und den Hinweis auf ftp2. Hat mich auf die richtige Spur gebracht.
@ twiddem
Toller Tip mit HTTPredir. Hab' ich gleich in meiner sources.list eingetragen und funktioniert bestens. Keine Fehlermeldungen mehr bei "aptitude update" über IPv6. Herzlichen Dank.
Grüße, Curio
So. Ich hatte einen Schreibfehler in der /etc/Network/Interfaces. Der ist nun korrigiert.
Die Verzögerung beim "aptitude update" ist tatsächlich verschwunden.
# ping6 -I 2a03:******::* -c 3 security.debian.org
PING security.debian.org(lobos.debian.org) from 2a03:******::* : 56 data bytes
64 bytes from lobos.debian.org: icmp_seq=1 ttl=61 time=4.01 ms
64 bytes from lobos.debian.org: icmp_seq=2 ttl=61 time=4.61 ms
64 bytes from lobos.debian.org: icmp_seq=3 ttl=61 time=3.97 ms
--- security.debian.org ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 3.972/4.200/4.612/0.296 ms
Vielen Dank erst mal bis dahin für Deine weiterführende Hilfe, A.
Allerdings wenn ich "aptitude update" per ipv6 aufrufe, erhalte ich einige Fehler beim Aufruf der Repositories:
# aptitude update
Treffer http://security.debian.org jessie/updates InRelease
Feh http://ftp.de.debian.org jessie InRelease
Feh http://ftp.de.debian.org stable-updates InRelease
Feh http://ftp.de.debian.org jessie Release.gpg
»ftp.de.debian.org« konnte nicht aufgelöst werden.
Feh http://ftp.de.debian.org stable-updates Release.gpg
»ftp.de.debian.org« konnte nicht aufgelöst werden.
Treffer http://security.debian.org jessie/updates/main Sources
Treffer http://security.debian.org jessie/updates/contrib Sources
Treffer http://security.debian.org jessie/updates/non-free Sources
Treffer http://security.debian.org jessie/updates/main amd64 Packages
Treffer http://security.debian.org jessie/updates/contrib amd64 Packages
Treffer http://security.debian.org jessie/updates/non-free amd64 Packages
Treffer http://security.debian.org jessie/updates/contrib Translation-en
Treffer http://security.debian.org jessie/updates/main Translation-en
Treffer http://security.debian.org jessie/updates/non-free Translation-en
W: Herunterladen von http://ftp.de.debian.org/debian/dists/jessie/InRelease fehlgeschlagen:
W: Herunterladen von http://ftp.de.debian.org/debian/dists/stable-updates/InRelease fehlgeschlagen:
W: Herunterladen von http://ftp.de.debian.org/debian/dists/jessie/Release.gpg fehlgeschlagen: »ftp.de.debian.org« konnte nicht aufgelöst werden.
W: Herunterladen von http://ftp.de.debian.org/debian/dists/stable-updates/Release.gpg fehlgeschlagen: »ftp.de.debian.org« konnte nicht aufgelöst werden.
W: Einige Indexdateien konnten nicht heruntergeladen werden. Sie wurden ignoriert oder alte an ihrer Stelle benutzt.
Alles anzeigen
Heißt das nun, dass nur die Security Repositories von Debian per ipv6 erreichbar sind und der Rest nicht?
Curio
Hier habe ich offensichtlich einen Fehler in der IPv6-Konfiguration. Ich kann keine iPv6 Adressen anpingen.
Ich habe es auch gleich mal mit Anpingen der ipv6.google.com versucht - mit gleichem Ergebnis.
Ich muss also erst noch mal meine IPv6 Konfiguration überprüfen.
Curio
Nein, wie im ersten Posting beschrieben habe ich noch keine Firewall eingerichtet.
Curio
Hallo Gemeinde,
Ich habe einen neuen KVM-Server mit Debian 8.4 aufgesetzt und mit IPv4 und IPv6 im Dual Stack konfiguriert. Eine Firewall ist bisher noch nicht eingerichtet.
Nun bemerke ich, dass beim aptitude update der Prozess bei "100% [Verbindung mit security.debian.org (2001:a78:5:1:216:35ff:fe7f:6ceb)]" einige Minuten verzögert, dann jedoch ohne Fehlermehldung durchläuft. Das Ergebnis meiner Netzrecherche ergab, dass es sich dabei um ein Problem handelt, dass auftritt, wenn man über IPv6 auf die Debian Security Repositories zugreift. Entsprechende Tests auf meinem Server bestätigen den Zusammenhang mit IPv6.
In den Netzquellen wird stets empfohlen, IPv6 für die Zugriffe auf die Debian Repositories auszuschließen. So weit so gut.
Doch ich habe nirgends etwas zu den Hintergründen gehört. Sind die Debian Repositories ein Problem mit IPv6, liegt ein Bug in Debian vor oder liegt das Problem in meiner Serverkonfiguration?
Kann mir hier jemand mit Hintergrundinfos auf die Sprünge helfen?
Vielen Dank schon mal im Voraus für Eure Mühe.
Curio
Hallo Freunde,
Ich betreibe einen Webserver (KVM) mit Debian Wheezy v7.10, Apache v2.2.22 (php-fpm) und i-MSCP v1.2.17.
Nun möchte ich eine Domain permanent auf https umleiten. Die entsprechenden Einstellungen im i-MSCP wurden korrekt durchgeführt und das entsprechende letsencrypt-Zertifikat problemlos eingefügt. Die Redirect-Rules habe ich auf Grund eines entsprechenden Posts aus dem i-MSCP-Forum nicht in einer .htaccess-Datei abgelegt sondern in der entsprechenden vHost-Config Datei der Domain (/etc/apache2/sites-available/meinedomain.de.conf):
RewriteEngine on
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}[R=301,L]
Die Weiterleitung von http://domain.de und http://www.domain.de auf https://domain.de funktioniert tadellos.
Jetzt zu meiner Frage. Leider klappt dies beim direkten Zugriff auf Unterseiten nicht. Gebe ich in die Browser-Adresszeile z.B. domain.de/Impressum ein, erfolgt kein Redirect, sondern ich bleibe bei http://domain.de/impressum.
Muss ich meine Redirect-Regeln hier noch anpassen?
Gruß, Curio
Hallo community,
Mein Server: KVM-Server, Debian 7.9 Wheezy, PHP v5.5.30, MySQL v5.5.46, Apache v2.2.22, wird als Web- und Mailserver genutzt. Admin-Panel = i-MSCP v1.2.11
Ich habe offensichtlich ein Problem mit dem dhcpd. Im Syslog finde ich folgende Einträge:
Jan 28 08:16:42 srv dhclient: DHCPREQUEST on eth0 to 46.38.225.12 port 67
Jan 28 08:16:42 srv dhclient: send_packet: Operation not permitted
Hier scheinen meine Firewalleinstellungen nicht korrekt zu sein, denn jedes mal, wenn ich kurz die Firewall deaktiviere, kann sich der dhclient problemlos verbinden.
Jetzt habe ich 3 Fragen.
Gruß, Curio
Vielen Dank für Eure Antworten.
Die Frage, ob man auf dem KVM-Gastsystem den NTP-Dienst installieren sollte oder nicht wird offensichtlich ziemlich kontrovers diskutiert. Es kann wohl keine Lösung so pauschal angeboten werden, da diese von vielen Faktoren abhängt (z.B. Distribution des Host- und Gastsystems, CPU, läuft auf dem Host ntp, usw.). Ich verweise in diesem Zusammenhang auch auf diesen Thread: [KVM] "eigene Uhrzeit" (RTC) ?
Ich habe für mich nun erst einmal die gleiche Lösung gewählt. Ich verwende auf meinem KVM-Server nun auch den ntp-Dienst und habe erst mal eine perfekte Systemzeit. Vorher, ohne ntp, war die Zeit um mehr als 2 Stunden verschoben.
Vom Netcup-Service wurde ich bei diesem Thema komplett im Stich gelassen. Selbst wenn dies eine komplizierte Materie ist, mit vielen Unbekannten, dann wäre es doch angebracht, die Kunden über die Problematik aufzuklären, die eventuelle ntp-Konfiguration des Hostsystem offenzulegen und Empfehlungen/Orientierung für die Zeitsynchronisation der Gastsysteme zu geben. Das Wiki würde sich dafür anbieten.
Gruß, Curio
Hallo Leute,
Ich betreibe einen Root-Server M v2 mit Debian Wheezy und i-MSCP als Admin-Panel als Webserver.
Der Befehl date auf der Konsole zeigt, dass die Serverzeit ca. 5:48 h nachgeht. Ich habe dies versucht entsprechend des Netcup-Wiki Beitrags Uhrzeit einstellen – netcup Wiki zu korrigieren. Die Korrektur läuft ohne Fehler durch, jedoch zeigt sie im Ergebnis wiederum die alte falsche Zeit an. Als Zeitzone ist per tzdata Europa/Berlin eingestellt (übrigens auch in der php.ini).
Einen eigenen ntp-Dienst habe ich nicht eingerichtet, da ich der Meinung war, dass der KVM-Server seine Zeit vom Hostsystem bezieht.
Der netcup-Support hat mich hier aufs Forum verwiesen und wollte mir bei dieser Fragestellung nicht helfen. Worin kann das Problem liegen? Gibt es eine Lösung?
MfG, Curio
Hallo,
Vielen Dank für den Hinweis, Felix. Ich habe nun DHCP beibehalten. DNS funktioniert problemfrei mit den Nameservern von Netcup.
Gruß, Curio
Da habe ich mich völlig verlaufen.
Du hast natürlich recht. Vielen Dank für Deinen Hinweis, killerbees19.
Das Thema hat sich damit erledigt.
MfG, Curio
Hallo Leute,
Ich betreibe einen Root-Server M v2 mit einem Debian Wheezy v7.7 minimal mit dem Admin-Panel i-MSCP.
Meine Domains verwalte ich über INWX.
Ich nutze keinen eigenen DNS-Server auf meinem Root-Server und möchte nur die Nameserver von INWX in die /etc/resolv.conf eintragen. Allerdings ist diese Datei dynamisch und wird stets wieder mit den Einträgen von Netcup überschrieben. Auf dem System läuft das Paket resolvconf. Nun zu meinen Fragen.
MfG, Curio