Ich habe beide Server unter dem neu angelegten User ts3 gestartet mit dem beiligenden Startscript.
Dann stimmt da was nicht. Der neue Server sieht eher so aus wie manuell gestartet. Laufen da vielleicht mehrere Prozesse parallel?
Beiträge von frank_m
-
-
Die Server werden offensichtlich unterschiedlich gestartet. Läuft der eine in einem anderen Nutzerkontext oder einem anderen Environment? Hast du dir den Traffic der Server mal mit tcpdump angesehen?
-
Die freien Sektoren des Filesystems sind auch alle auf Null?
-
Die %4 ist die Interface-ID in Windows, da die fe80::1 als link-lokale Adresse ja theoretisch auf jedem Interface gefunden werden kann.
-
Mein mx Eintrag lauscht auf "@", nicht auf eine Domain. Wenn du eine Domain einträgst, achte darauf, ob ggf. ein abschließender Punkt eingegeben werden muss.
Die rDNS Einträge stimmen? Weil alles andere schließt du per spf ja aus. Die Kette muss konsistent sein.
-
Zum Port-Forwarding habe ich folgende iptables Regel hinzugefügt:
-I PREROUTING -s 1.2.3.4/32 -p tcp -m tcp --dport 3306 -j DNAT --to-destination 172.22.1.99:3306
Die Source IP (1.2.3.4) habe ich zensiert.
1.2.3.4 ist dabei deine öffentliche IP? Dann muss dort "-d" hin, nicht "-s". Außerdem muss "-t nat" in die Regel. Das kann aber ggf. auch durchs Framework erledigt werden.
Entsprechend habe ich eine weitere Regel in die FORWARD Tabelle (DOCKER-USER) hinzugefügt:
-I DOCKER-USER -p tcp -m tcp --dport 3306 -j ACCEPT
In der Regel würde ich auch noch die Zieladresse (-d 172.22.1.99) mit angeben.
-
Die Fritzbox kann netcup DNS Einträge nicht direkt aktualisieren, du brauchst eine Zwischeninstanz. Das kann ein Webservice wie ownDynDns sein, oder du benutzt einen anderen ddns Dienst und arbeitest mit CNAMEs.
Im Wiki finden sich Beispielprojekte für die netcup DNS Schnittstelle (z.B. ownDynDns, aber auch andere). Ob da was für den ddclient dabei ist, weiß ich nicht. Für die Fritzbox wird sich da nichts finden.
-
Sihe mein Beitrag #3.
Oh ja, sorry, das hatte ich übersehen. Aber so in etwa hatte ich mir das vorgestellt. Zunächst ein System zu installieren vor dem Übertragen der Daten, hätte ich nicht erwartet, aber das geht natürlich und erspart später den Kampf mit dem Bootloader.
-
PV klingt nach Paravirtualisierung. Da hast du keinen eigenen Kernel im Image.
Nebenbemerkung: Vor einem Jahr habe ich für einen Bekannten einen Xen-Container [...] hier zu Netcup erfolgreich umgezogen.
Wie genau? Wahrscheinlich nicht durch einfaches Einspielen eines Images? Das war eher ein file-basierter Ansatz, oder?
-
Am liebsten ist mir alles was ich rein per ssh und Konsole konfigurieren kann und es danach auch noch funktioniert am liebsten.
Endlich normale Menschen! Mir geht dieser ganze Clicki-Bunti Kram auch auf die Nerven. Von mir aus könnte auch das Infotainment System in meinem Auto eine bash als Eingabemedium haben.
-
Nicht ganz. Du erzeugst nur auf deinem Wireguard Server die .key und .pub und ergänzt deine Wireguard-Conf auf dem Server.
Ich tue mich bei Wireguard schwer mit den Begriffen Server und Client. Im Grunde kommunizieren da zwei oder mehr gleichberechtigte Partner miteinander, und jeder öffnet einen Server Port, auf dem die jeweiligen Partner als Client zugreifen.
Deshalb ist es auch egal, wo die Keys erzeugt werden, solange am Ende jeder Knoten seinen (und nur seinen!) Private Key hat und alle anderen Knoten den zugehörigen Public Key.
Das würde dann beudeuten, dass jeder der Rechner zwar selbst ein Wireguard-Server ist aber eine Liste von *.pub der restlichen Rechner hat auf die er zugreifen darf/kann/soll.
Exakt so ist es richtig.
Natürlich wird man häufig auf Konstellationen treffen, in denen es einen zentralen Knoten gibt, auf den alle zugreifen, und der dann die Daten verteilt. Der heißt dann häufig Server, aber schon Cisco nannte seine VPN Server "Concentrator", und der Begriff passt deutlich besser.
Aber man kann mit Wireguard auch wundervolle dezentrale Netze bauen, in denen die jeweiligen Peers direkt miteinander reden. Kann aus Performance-Sicht vielleicht sogar vorteilhaft sein, wenn der Hop über den Concentrator entfällt. Schwierig wird es, wenn keiner der beiden Nodes eine öffentliche IP hat, dann ist eine zentrale Instanz, die von überall erreichbar ist, natürlich wertvoll.
Wenn ich die UFW-Firewall vewende und nicht iptables?
Willst du wirklich NAT verwenden? Das solltest du anhand deiner Anwendungsfälle noch mal kritisch prüfen. Das braucht man längst nicht so oft, wie es die gängigen Tutorials erwarten lassen. Eigentlich gibt es nur einen Grund dafür, nämlich Internetzugriff über VPN. In allen anderen Fällen ist es eher kontraproduktiv.
-
Warum? Sie ist bei GMail im Spamordner gelandet! Also liegt das Problem nicht bei mir,
Stell dir vor, du stehst vor Gericht und erzählst dem Richter die Nummer. Du merkst es selber, oder?
Wenn muss Netcup auch dafür Sorge tragen, dass solche wichtigen Informationen auch wirklich beim Empfänger ankommen!
In dem Moment, wo die Mail an deinen Mailserver übergeben wurde, ist das der Fall. Für deine SPAM Regeln können sie nichts. Du hast ja bestimmt einen gmail Business Account bei so wichtigen Geschäften, da kannst du das ja selber einstellen, z.B. durch das Hinzufügen von Adressen deiner Geschäftspartner zur Whitelist.
Ich würde dir raten, das Thema zu den Akten zu legen. Du machst es nur schlimmer.
-
Du bekommst eine Abuse Meldung von einem Server mit tausenden Kunden und schaffst es nicht, innerhalb von 24 Stunden eine Stellungnahme abzugeben? Du musst es ja nicht selber machen, dann übergebe es halt an einen Mitarbeiter.
... Freitagabend dann mein Server gesperrt wird, ich dann sofort Stellung genommen habe,
Ach, da ging es "sofort"? Hmm.
Jetzt ist mein Produktionsserver, mit tausenden Kunden übers Wochenende nicht erreichbar, ich verliere Geld und Vertrauen der Kunden, nur weil solche wichtigen Ding am Wochenende nicht bearbeitet werden.
Jetzt ist es plötzlich wichtig.
Ich kann den Ärger verstehen, aber hier muss man echt fragen, wo der Fehler gemacht wurde. Du verpennst es während der regulären Arbeitswoche, und erwartest nun, dass andere am Wochenende dein Problem wieder grade biegen? Das hättest du vermeiden können.
Ich würde mich auch fragen, wo die Abuse Meldung herkommt. Auch wenn sie falsch ist, gibt es eine Ursache.
-
Wenn mir jemand die Installation verschlüsselt hat, dann will ich die alten Backups und nicht die aktuellen.
-
Ich dachte ich brauche IPv4 (und eben auch IPv&) forwarding um die Pakete über der WireGuard-Schnittstelle weiterzuleiten?
Ich dachte, du hattest bereits einen Wireguard Server, der für IPv4 funktioniert und nun auch für IPv6 laufen soll. Wenn du den in der gewohnten Weise weiterbenutzen willst, musst du im Grunde nur IPv6 als Server-Adresse aktivieren. Im Tunnel kann alles bleiben, wie es ist, und auch Forwarding Rules brauchst du keine neuen.
-
Speziell auf WireGuard gesehen muss ich eine IPv6 dann nur „normal“ auf dem Server einrichten und das forwarding für IPv6 aktiveren – das wars?
Um nur den Server zu aktiveren, braucht es kein Forwarding. Oder läuft der Server nicht nativ, sondern in einem Container oder einer VM? Dann kann es sein, dass man Forwarding braucht.
Innerhalb des Tunnels kann man ja wieder mit IPv4 arbeiten. Darauf hat die externe Verbindung keinen Einfluss, und dafür braucht man auch kein Forwarding.
-
Kommt drauf an, ob du auch eine IPv4 Adresse hast, und zwar vor allem auch auf der Gegenseite.
Wireguard arbeitet ja (eigentlich) verbindungslos über UDP, sprich, beide Seiten müssen einen UDP Server zur Verfügung stellen. Gut, es gibt sowas wie Keep-Alive, um NAT Tabellen am Leben zu halten, aber prinzipiell gilt das oben gesagte. Vorteilhaft ist es auf jeden Fall, wenn beide Seiten erreichbar sind. An vielen Heimnetz-Anschlüssen mit Kabelinternet oder Glasfaser bekommt man keine öffentliche IPv4 mehr, sondern DS-Lite oder CGNAT Anschlüsse, und dort hat man nur eine öffentliche IPv6 Adresse. Wenn dort dein Wireguard-Client sitzt, dann wäre ein IPv6 Zugang ein echter Vorteil, denn beide Partner könnten sich gegenseitig erreichen, ohne dass man extra Klimmzüge machen muss.
Generell steigen die IPv6 only Angebote, Congstar bietet z.B. Mobilfunktarife an, die keine IPv4 Adresse mehr haben. Da wäre dann ein IPv6 Server sogar zwingend erforderlich.
Ich würde heute nicht mehr drauf verzichten. Mittelfristig wird es Pflicht, und es ist kein Hexenwerk.
-
Pull hat in meinen Augen den Vorteil, dass im worst case bei einer Kompromittierung des Servers, nicht auch noch die Backups in Mitleidenschaft gezogen werden können
Genau das ist der Grund. Pull und nichts anderes.
-
ich weiß gerade nicht was du mit der Original IP meinst
Der Server hat im Auslieferungszustand eine IPv6 Adresse, die sich aus deinem Prefix und der EUI-64 Interface ID des Servers zusammensetzt. Die ist z.B. auch das Routing Ziel für zusätzliche IPv6 Netze und damit die "Standard-Adresse" in der netcup Welt für diesen Server. Die solltest du auf jeden Fall testen.
Aber ich kann ihm natürlich Docker noch eine IP zuweisen, hört sich am besten an.
Denk an die Verbindungsunterbrechungen aufgrund von NDP, wenn du dem Docker Container eine Adresse aus deinem mitgelieferten /64 zuweist.
Sie wollten nur wissen ob ich das Rettungssystem starten kann und dann noch ob ich eine IPv6 dort konfigurieren kann. Dort hat es funktioniert. Danach war das Thema für sie erledigt.
Ich glaube auch nicht, dass das ein Problem der Infrastruktur ist. Wenn die Adresse und die Routen richtig eingerichtet sind (also passt das Prefix?), dann kommt natürlich als erstes die Firewall ins Spiel, denn die ist im Rescue Image nicht aktiv.
-
Was passiert mit der Original-IP vom Server? Also mit der Standard-Konfiguration nach der Installation des Images? Was ist mit der Firewall?
Willst du NAT für IPv6 machen? Würde ich nicht empfehlen. Verpasse dem Docker Container besser eine öffentliche IPv6, vorzugsweise aus einem zusätzlichen /64 um der Problematik des geswitchten ersten /64 aus dem Lieferumfang aus dem Weg zu gehen.
Falls doch NAT: hast du die entsprechenden Firewall Regeln eingeführt?
