Beiträge von ruut

  • Server nimmt IPv6 nicht an, aber IPv4 läuft – Was läuft hier schief?

    Hallo,

    hier die Infos. Danke wieder voraus. :)

    IPv6 Ziele anpingen funktioniert.

    # ping6 google.com

    PING google.com (2a00:1450:4001:831::200e) 56 data bytes

    64 bytes from fra24s12-in-x0e.1e100.net (2a00:1450:4001:831::200e): icmp_seq=1 ttl=120 time=0.627 ms

    64 bytes from fra24s12-in-x0e.1e100.net (2a00:1450:4001:831::200e): icmp_seq=2 ttl=120 time=0.700 ms

    64 bytes from fra24s12-in-x0e.1e100.net (2a00:1450:4001:831::200e): icmp_seq=3 ttl=120 time=0.677 ms

    ^C

    --- google.com ping statistics ---

    3 packets transmitted, 3 received, 0% packet loss, time 2012ms

    rtt min/avg/max/mdev = 0.627/0.668/0.700/0.030 ms

    # Netzwerk | Adressen sind maskiert

    # ip a


    1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000

    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

    inet 127.0.0.1/8 scope host lo

    valid_lft forever preferred_lft forever

    inet6 ::1/128 scope host noprefixroute

    valid_lft forever preferred_lft forever

    2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000

    link/ether **:**:**:**:**:** brd **:**:**:**:**:**

    altname enp0s3

    inet **.**.**.**/24 metric 100 brd **.**.**.** scope global dynamic ens3

    valid_lft 21531712sec preferred_lft 21531712sec

    inet6 **:**:**:**:**:**:**:**/48 scope global

    valid_lft forever preferred_lft forever

    inet6 fe80::***:**:****:****/64 scope link

    valid_lft forever preferred_lft forever

    # Routing

    # ip -6 route

    2***:****:*::/48 dev ens3 proto kernel metric 256 pref medium

    fe80::/64 dev ens3 proto kernel metric 256 pref medium

    default via **:**:**:**:**:**:**:** dev ens3 proto static metric 1024 pref medium

  • Server nimmt IPv6 nicht an, aber IPv4 läuft – Was läuft hier schief?

    Liebes Forum, :)

    ich habe da ein Problem mit meiner Webseite. Der Server akzeptiert Verbindungen über IPv4 ohne Probleme, aber wenn ich versuche, über IPv6 drauf zu kommen, bekomme ich die Fehlermeldung:

    curl: (7) Failed to connect to example.com port 443 after 12 ms: Couldn't connect to server


    Was ich bisher geprüft habe:

    • Der Server läuft mit Debian GNU/Linux und Apache.
    • Er hat sowohl IPv4- als auch IPv6-Adressen, aber IPv6-Verbindungen scheinen irgendwie blockiert zu werden.
    • Wenn ich mit curl -4 -I https://example.com eine Anfrage mache, bekomme ich die Antwort mit HTTP/2 200 zurück.
    • Bei curl -6 -I https://example.com kommt aber diese Fehlermeldung.

    Ich habe schon Folgendes gecheckt:

    1. Apache-Konfiguration: Der Webserver ist auf Port 443 für sowohl IPv4 als auch IPv6 konfiguriert.
    2. Firewall: Keine Regeln, die IPv6-Verbindungen blockieren (weder auf dem Server noch im Netzwerk).
    3. DNS: Der AAAA-Record ist korrekt gesetzt.

    Hat jemand von euch eine Idee, warum IPv6 nicht funktioniert oder was ich noch nachschauen könnte?

    Wäre super, wenn ihr helfen könntet! :)

  • Wordpress - Gehackt..?

    in der wp-config war eine IP eingetragen DB-Name/User und Passwort

    Code
    define( 'DB_HOST', 'xxx.xxx.xxx.xx' );

    Ich hab alles testweise auf einer anderen Maschine installiert.

    Ist aber nur die WP Fehlermeldung gekommen - Datenbank Fehler - keine Verbindung ect..

    Wordpress/PlugIns und das System, alles auf dem neuesten Stand.

  • Wordpress - Gehackt..?

    Hallo,

    die wp-config die dort angelegt war hat eindeutig eine Remote Verbindung zu einem Server in den USA.

    Ich vermute dass eine Wordpress Sicherheitslücke genutzt wurde.

    Clamscan hat auf jeden Fall nichts verdächtiges gemeldet.

    Ich vermute wegen der fehlenden Berechtigung konnte er meine wp-config nicht überschreiben (im document root war neben dem kompletten wordpress verzeichnis mit Installation auch eine wp-config-sample ) bzw. war es ihm auch nicht möglich aufgrund der Apache Konfiguration auf seine wp-login zuzugreifen.

    Auf jeden Fall waren alle Wordpress Installationen (8) auf dem Server betroffen.

    Es ist also alles eindeutig. Sicherheitshalber hat Dokument Root noch 550 bekommen.

    Ich werde die Sache jetzt erstmal beobachten.