Is the address configured correctly on the interface? Does the telnet client accept IPv6 addresses in that format? Often they have to be put in brackets [] or can't be given directly as an argument.
BTW: Telnet is a horrible security leak! You should never Never NEVER NEVER!!! expose a telnet server to the internet. Please make yourself familiar at least with the absolute basic knowledge about hosting a server. You obviously don't have a clue what you are doing.
Ist ja nicht mein fehler gewesen sondern das Plugin hatte eine schwachstelle.
NATÜRLICH ist das deine Schuld. Denn ist deine Verantwortung als Administrator, deine Webseite auf dem aktuellen Stand zu halten und Sicherheitslücken umgehend zu schließen - wie auch immer. Wenn es kein Update gibt, musst du das entsprechende Plugin deaktivieren. Wenn du dem nicht nachkommen kannst - aus Zeitgründen oder warum auch immer - dann solltest du keine Webseite betreiben.
Und es bestätigt, dass es geholfen hätte, einfach mal in Ruhe die Verzeichnisse und ihre Rechte anzusehen, wie es hier mehrfach gefordert wurde. Dann wäre man dem Problem und der Lösung sicherlich schnell auf die Spur gekommen, und das Herumhacken auf dem Support wäre nicht nötig gewesen.
Meine Ziele:
Die Wiederherstellung meiner administrativen Handlungsfähigkeit.
Einen vollständigen Full-Wipe (Reset) des Accounts, da eine manuelle Bereinigung unter diesen Umständen technisch unmöglich und unsicher ist.
Ich vermute, das kann man auch Support erreichen. Allerdings diskutieren wir hier immer noch quasi ohne belastbare Information, wie es bei dir auf dem System aussieht und welche Versuche du wie unternommen hast. Von daher wird es schwer.
Gabs nicht im WCP die Möglichkeit, das Webhosting komplett zurückzusetzen?
Ich glaube, hier wird das eigentliche Risiko unterschätzt: Wenn ich als rechtmäßiger User keine Ownership mehr über meine Verzeichnisse habe und chmod fehlschlägt, ist dieser Account auf Systemebene (Root/Kernel) kompromittiert.
Nicht unbedingt.
Wie kommst du denn auf das System, wenn die id_rsa manipuliert wurde? Welchem Nutzer ist die id_rsa zugeordnet, und welche Rechte hat sie (600)? Vielleicht wären ein paar Screenshots hilfreich, um sich mal ein Bild zu machen, wie es überhaupt bei dir aussieht. Welche Prozesse laufen im System?
Im Moment hört sich das alles sehr undurchsichtig an.
Kann man eigentlich nicht viel falsch machen. Ich nutze auch Office365 auf meinen Domains, und da sieht der funktionierende Eintrag so aus:
Achte darauf, dass der Eintrag gültig ist, bedenke die 10 Minuten Verzögerung bei Netcup und die TTL für die Änderung der Werte in den Caches der diversen Nameserver.
Die Frage ist, warum es besser ist, einen Proxy auf 10.121.1.1 lauschen zu lassen, anstatt den Server direkt?
Sind die Ports rein oder raus freigegeben? Und hinter den Ports lauscht auch jeweils ein passender Server?
Halte uns bitte auf dem Laufenden. Da interessiert mich, wie du es am Ende löst.
Horcht der Anwendungs-Server auf dem VPS auf alle Adressen, also z.B. auf http://0.0.0.0:9000, dann kann ich mit curl http://10.121.1.1:9000 problemlos über Wireguard auf die Anwendung zugreifen.
Natürlich. Und genau da ist auch das Problem, wenn du den Server nur auf 127.0.0.1 lauschen lässt. Denn dein Client schickt ja keine Pakete mit der Ziel-Adresse 127.0.0.1, sondern mit Zieladresse 10.121.1.1. Da lauscht aber kein Server. Der Aufruf funktioniert, weil das lauschen auf 0.0.0.0 dazu führt, dass auf allen Interfaces gelauscht wird - auch auf 10.121.1.1.
Du hast also zwei Möglichkeiten: Entweder eine Portweiterleitung mit NAT (NAT muss sein, da 127.0.0.1 auf deinem Client nicht ins VPN geroutet wird), oder du lässt den Server auch auf 10.121.1.1 lauschen (0.0.0.0 ist nicht erforderlich). Im zweiteren Fall musst du vermutlich dafür sorgen, dass der Server erst gestartet wird, wenn der Tunnel schon existiert.
Ich halte die Konfiguration aus verschiedenen Gründen für nicht sonderlich zielführend.
Zum einen hast du die Grundlagen der Fritzbox Doku nicht beachtet. Die Box macht Proxyarp, die IP der Box sollte aus ihren Subnetz kommen und es sollte kein Transportnetz benutzt werden.
Im Server machst du NAT und gibst die Defaultroute für die Fritzbox an. Dein Server wird ab sofort seinen gesamten Internet-Datenverkehr über die Fritzbox abwickeln, nicht nur die des Smartphones, auch seinen eigenen! War das wirklich das Ziel deiner VPN Versuche, dass ein V-Server seinen gesamten Internetverkehr durch dein Heimnetz leitet? Seine Updates und alles Weitere?
Durch die NAT Regeln ist der Rückweg aus deinem Heimnetz auf dem Server und seine VPN Clients nicht möglich. Das mag bei einem einzelnen Smartphone als VPN Client in Ordnung sein, aber wenn weitere Clients hinzukommen, ist das kontraproduktiv. Vollwertiges Routing ist in dem Fall eher zu empfehlen, und NAT würde ich auf die Fälle einschränken, wo das Smartphone den Internetzugang über VPN bekommen soll.
Du machst gar nichts falsch. Das ist so. Wurde auch schon mehrfach hier im Forum diskutiert.
Einer der Gründe, so schnell wie möglich zu einer funktionierenden SSH-Verbindung zu kommen.
danke für deine Antwort. Beachte meinen ersten Beitrag in diesem Thread. Mein Hauptziel ist es ja mit dem Smartphone von unterwegs unabhänig von IPv6 und IPv4 auf das Netzwerk zu Hause zugreifen zu können. Also genau das "Road Warrior Client" Szenario.
Ja, wie gesagt, kein Problem. Halte dich für die Verbindung zwischen VPS und Fritzbox an die AVM Anleitung. Die sieht ja bereits ein lokales Netz für den Router der anderen Seite vor, dass ist in deinem Fall das Netz der Roadwarrior Clients. Für eine zweite Fritzbox fügst du einfach deren Netz als Allowed IP hinzu. Die Clients kannst du gemäß jeder gängigen Wireguard-Anleitung konfigurieren. Bedenke dabei auch die Allowed IPs aus dem Fritzbox Netz. Das wars schon.
Der Ton gefällt mir nicht, ich bin deshalb hier raus.
Wenn du meinst, bitte. Ich will nur verhindern, dass sich über solche Threads wieder irgendwelche Mythen im Internet festsetzen, die technisch einfach nur hanebüchen sind. Am Ende lesen es andere und glauben es vielleicht auch noch.
Denn es gibt bei Wireguard auf technischer Ebene keine Zuordnung von Server oder Client, Initiator oder Responder. Diese Rollen können nur durch externe Einflüsse festgelegt werden, und nicht durch die Wireguard-Technologie an sich. Und das bedeutet auch, sie haben keinerlei Einfluss auf die grundlegende Konfiguration, z.B. bei den IP-Adressen. Das Einzige, was eine wichtig werden könnte, sind die keep-alive Pakete, die nötig werden, damit ein Client hinter einem NAT Router erreichbar bleibt.
Ich müsste dann die IP-Adresse des Wireguard Transfernetzes auf das IP-Band der Fritz!Box (192.168.0.xxx) ändern, oder?
Du brauchst gar kein Transfernetz bei einer LAN-2-LAN Verbindung. Das bräuchtest du erst, wenn Road Warrior Clients hinzukommen. Und dann auch nur für die, in den Fritzbox taucht es dann nur als allowed IP auf.
Dann frage ich mich, wie das funktionieren soll, wenn ich wirklich eine zweite Fritz!Box reinhängen möchte.
Genauso. Wie gesagt: LAN-2-LAN Verbindungen brauchen kein Transfernetz.
Wenn die Fritzbox das Laden einer korrekten VPN-Konfig verweigert, dann gibt es häufig einen Konflikt mit einer anderen existierenden VPN-Konfiguration. Ggf. hilft es, alle (!) existierenden VPN Konfigurationen für Wireguard und IPSec zu löschen. Reicht das nicht, muss man einen Reset auf Werkseinstellungen durchführen.
Sollte das nicht dauerhaft stabil sein, dann würde ich zuerst das hier überprüfen:
Source Port(s): <Port-Wireguard>
Wie gesagt, nur weil eine App einen Port eingehend öffnet, bedeutet das nicht, dass sie auch ausgehend alles darauf sendet.
Icb kenne die netcup Firewall noch nicht so genau, aber meines Erachtens sind in den Regeln mehrere Dinge falsch.
Inbound:
Destination(s) (IPs / Netzwerke): *
Hier sollte eine konkrete Zieladresse stehen. Auch wenn man Netzwerke angeben kann: Der Server lauscht ja nur auf einer IP, oder?
Outbound:
Source(s) (IPs / Netzwerke): 64831
Das ist Unsinn: eine Portnummer bei der IP-Adresse. Hier sollte wieder die konkrete Adresse des Servers rein.
Source Port(s): *
Bevor du auf die Idee kommst, hier den offenen UDP-Port von Wireguard einzutragen: Nur weil der Port eingehend offen ist, heißt das noch lange nicht, dass auch die ausgehenden Pakete von diesem Port kommen. Von daher ist "*" vermutlich richtig.
Um es noch einmal sehr deutlich zu sagen: Technisch gibt es bei Wireguard weder Server noch Client, weder Initiator noch Responder. Die Rollen sind NICHT fest verteilt, jede Seite kann bei Bedarf jede Rolle übernehmen. Natürlich könnt ihr durch euer Setup Konstellationen erzeugen, dass es einen zentralen Knoten gibt, der alle Clients (Netze und Road-Warrior) miteinander verbindet. Es ist auch denkbar, dass es eine Seite das erste Paket senden MUSS, weil die Gegenseite die Adresse nicht kennt.
Das ist aber eher ein Problem, als ein Feature, denn bedenkt: Das betrifft nicht nur den initialen Verbindungs-Aufbau, sondern auch laufende Verbindungen. Der zustandslose Charakter der Wireguard Verbindung kann nach verhältnismäßig kurzer Zeit dazu führen, dass ein mobiles Endgerät den Tunnel zum "Server" verliert, besonders, wenn das mobile Endgerät wirklich mobil ist (spätestens, wenn sich die abgehende IP-Adresse im NAT ändert). Solche Dinge muss man beim Design eines Wireguard Netzes auf dem Schirm haben. Und da macht es wenig Sinn, in den althergebrachten Rollen von Server zu Client zu denken, wenn die reale Technologie diese Rollen so nicht abbildet.
Das stimmt so nicht ganz: Es gibt zwar nicht den klassischen Server und Client, aber einen Initiator.
Nein. Wenn eine Seite ein Paket für die andere Seite hat, schickt sie es rüber. Dabei ist egal, was vorher war, wann das letzte Paket geschickt wurde, usw. Ggf. muss dann noch ein Schlüsselaustausch gemacht werden, wenn die letzten Schlüssen abgelaufen sind.
Wenn aufgrund von NAT oder ähnlichen Mechanismen eine Seite der Verbindung nicht erreichbar ist, dann hat man das Problem, dass die Gegenseite kein Paket schicken kann, bevor sie nicht vom NAT-Partner ein Paket empfangen hat. Dafür gibt es dann auch die Keep-Alive Pakete. Aber das ist unabhängig vom Verbindungsstatus, Server oder Client Rollen.
Ein weiteres Problem sind sich ändernde IP-Adressen während einer laufenden Verbindung. Wireguard aktualisiert nämlich keine Adressen von Kommunikationspartnern zur Laufzeit. Da muss man mit externen Scripten nachhelfen, wenn man das Problem hat.
Naja, es kommt darauf an wer den Verbindungsaufbau initialisieren soll.
Zum einen: Bei wireguard initiiert niemand den Verbindungsaufbau. Es gibt in dem Sinne keinen Client und keinen Server, sondern eine Punkt-zu-Punkt-Verbindung zweier gleichberechtigter Partner, die sich zustandslos UDP Pakete zuschicken.
Zum Anderen: Für die IP Einstellung ist es vollkommen egal, wer die Verbindung initiiert. Damit das Routing arbeitet, müssen die in jedem Fall stimmen, sonst fließen gar keine Pakete, weder in die eine, noch in die andere Richtung.
Edit: Die Fritz!Box verweigert das Laden des Konfigfiles wenn in der Interface Section irgendeine IP-Adresse aus ihrem Adressbereich angegeben ist.
Die Konfig mit der IP der Fritzbox muss ja auch nicht in die Fritzbox, sondern in den anderen Router (also den VPS).
