Posts by abcd

Quote from tab

Ich kann jedenfalls sagen, dass mein Server mit der IP 152.53.134.xxx ganz sicher nicht in Wien stehen kann.

Das Netz sollte Nürnberg sein. Kommt zumindest von der Zeit auch hin:

152.53.128.0/20
descr:           Location: DE, Nuernberg

 1  gw01.netcup.net (46.38.225.2) [AS197540]  0.365 ms
 2  94.16.25.154 (94.16.25.154) [AS47147]  1.638 ms
 3  ae0-0.bbr02.anx84.nue.de.anexia-it.net (144.208.208.138) [AS42473/AS47147]  1.061 ms
 4  144.208.208.243 (144.208.208.243) [AS42473/AS47147]  1.017 ms
 5  X (152.53.134.X) [AS42473/AS197540]  0.746 ms

Quote from User_unknow

Würde mich interessieren, was ihr über diesen IP-Range herausfindet, bzw. wo diese beheimatet sind

Das von dir genannte Subnetz ist in mehrere Subnetze mit jeweils anderen Standorten aufgeteilt. Z.b. ist 152.53.12.0 - 152.53.15.255 in Nürnberg oder 152.53.36.0 - 152.53.39.255 für MNZ (USA).

Um welches Subnetz geht es dir denn genau?

Quote from Blue_Gamer48

die ip ist seit 26.11.24 bei mir und in Nürnberg

Du kannst ja auch dem Anbieter der GeoIP-Datenbank schreiben und ein Update für deine IPs anfordern. Bei vielen kostenfreien GeoIP DBs dauert das schon einige Monate bis die von alleine alle Änderungen enthalten und dann nochmal bis alle auf die neue Datenbankversion aktualisiert haben.

Brauchst du denn unbedingt das da Nürnberg steht?

.htaccess Änderungen werden bei jeder Anfrage neu ausgewertet und benötigen deshalb keinen Reload/Restart des Webservers.

Quote from Virinum

Hat jemand mal eine IP oder ein Subnetz von netcup aus Amerika für mich? Gehören die zu AS197540?

Mein Server hat eine IP aus dem Bereich 152.53.36.0 - 152.53.39.255 welcher scheinbar dem AS214996 zugeordnet ist

Quote from schimmiii

Das System ist ein Debian 12 und sollte mit der Failover-IP eigentlich so sein, dass die Requests auf den Hauptserver (netcup) dann auf das Backup-System umgeleitet werden, wenn der Hauptserver nicht erreichbar ist

Das hier liest sich für mich so, als wäre das "Backup System" nicht bei Netcup. Damit die Netcup Failover IPs funktionieren müssen beide Server bei Netcup am gleichen Standort stehen und beide Server so konfiguriert sein das beide diese IP kennen.

Netcup routet die Anfragen dann zum Server der im SCP eingestellt ist. Einen "Hauptserver" der alles weiterleitet existiert so nicht.

Quote from H6G

die landen aber jeweils in Paris? egal von welchem Router.

Paris scheint jedoch richtig zu sein, zumindest steht das auch in der Beschreibung der Route:

route6:          2a00:11c0:2::/48
descr:           ANEXIA Internetdienstleistungs GmbH
descr:           FR-75011 Paris

Überrascht mich nicht, dass die Statusseite in einem anderen DC als Netcup steht. Das rote H behandelt das ähnlich. Da stehen die System-Monitoring Server, Secondary NS und die Statusseite bei einem Konkurrenten aus Nürnberg.

Ansonsten könntest du deine Nutzer ja bei einem Totalausfall nicht mehr Informieren

Quote from KB19

Kann mal jemand prüfen, ob netcup-status.de über IPv6 erreichbar ist? Oder liegt's an meiner Verbindung?

curl -6Iv https://www.netcup-status.de/

(Wenn ich das richtig sehe, war das 2018 und 2020 auch schon mal kaputt. NC#2018123010000557)

Grad mal von einem PataDacket-Dedi getestet. Timeout...

Quote from Marcel2508

Wenn du Cloudflare nur für eine Sub-Domain benutzen möchtest und nicht für deine TLD (also z.B. cdn.domain.de), dann kannst du auch 2 NS DNS einträge in der "Normalen Ansicht" anlegen.

Also als Host trägst du z.B. "cdn" ein. Als Typ "NS" und als Destination jeweils deine Addressen von Cloudflare

Was dann aber auch einen Cloudflare Enterprise Account benötigt: https://developers.cloudflare.…e-setups/subdomain-setup/

Hast du evtl den PTR nur für deine IPv4 gesetzt oder hast du IPv6 deaktiviert?

Quote from engine

Achso. Steht denn der neue Standort nun schon fest? Ich hab jetzt leider nicht die Zeit die letzten Seiten durchzulesen. Dachte das war nur eine Umfrage.

Naja da steht ja nur was wir uns wünschen und da er nächste Woche live geht sollte er hoffentlich schon lange feststehen. Kann dir ja mal wenn du willst via DM schicken was ich schon herausfinden konnte.

Quote from engine

Solange der Server in der EU steht und der Anbieter aus der EU ist, ist doch jedes Land in der EU in Ordnung? Bin jetzt aber kein Datenschutzbeauftragter...

Das meine ich ja, solang der Server in der EU steht, ist es mir egal wo. Aber da der neue Standort ja kein EU-Mitglied ist, steht der Server also auch nicht in der EU und es würde ihm nicht passen. (Kann ich jetzt schon sagen D:)

Wird der neue Standort dann eigentlich auch unter "Keine Präferenz" automatisch ausgewählt werden können?

Innerhalb der EU ist mir das eigentlich egal, wenn ich mal Wien oder Nürnberg bekomme (oder dann einen anderen europäischen Standort), aber bei diesem Standort würde ich schon gerne vorher wissen, ob mein Server dort stehen könnte oder nicht bevor er mir ausgeliefert wird (Und das ist nicht nur aufgrund der höheren Latenz zu Nürnberg)

Edit: Also versteht mich nicht falsch, ich denke das ist ein super Standort und nen schönes neues Rechenzentrum, jedoch ist es immer eine Qual unseren Datenschutzbeauftragten zu überzeugen einen Server in diesem Land anzuschaffen und dann auch nutzen zu dürfen... Auch wenn es nur interne Testsysteme sind...

Also wenn du ein WIldcard Zertifikat nutzen willst, musst du nur "*.example.com" bei NPM im SSL Zertifikat eingeben. Im DNS musst du eigentlich nichts anders machen.

Ganz stark vereinfacht ist die Domain ja nur ein Alias für eine IP. Wenn du die Domain auf eine interne Adresse auflösen lässt, kann zwar jeder sehen das "meinservice.example.com" auf "10.1.1.1" läuft aber nicht darauf zugreifen. Geräte aus deinem Netzwerk die eh schon auf 10.1.1.1 zugreifen können, können jedoch über die Domain auf den Service zugreifen.

Also trägst du z.b. bei Netcup im DNS nen neuen A Record ein mit "meinservice" und "10.1.1.1" und sobald ein Gerät aus deinem Netzwerk auf meinservice.example.com geht landet er intern auf 10.1.1.1.

Wenn du auch nicht willst, dass andere die Domain außerhalb auflösen können kannst du es ja wie nebula76 machen und die Subdomains im lokalen DNS Resolver eintragen. Dann können nur Geräte die Subdomain auflösen, die in deinem Netzwerk sind und deine FB als Nameserver nutzen.

Ich hab grad auch noch diese Anleitung gefunden: https://notthebe.ee/blog/easy-ssl-in-homelab-dns01/

Da wird sowas sogar mit NPM und LetsEncrypt eingerichtet.

Also ansich müsstest du nur im NPM-Webinterface ein neues Zertifikat erstellen und das Häkchen bei "Use DNS Challenge" setzen & deinen DNS Provider auswählen.

Jetzt musst du dich nur noch entscheiden, ob du lieber ein Zertifikat pro Dienst, mehrere Dienste pro Zertifikat oder ein Wildcard SSL Zertifikat nutzen willst.

Wenn du nicht willst, dass andere herausfinden wie deine Dienste so heißen oder welche Dienste du so hast würde es sich anbieten ein Wildcard Zertifikat zu nutzen "*.example.com". Dann sehen andere auf z.b. https://crt.sh/ nur *.example.com und nicht "meingeheimerservice.example.com".

Wildcards kommen halt mit dem Vor/Nachteil, dass du das gleiche Zertifikat für alle Dienste in einem Level nutzen kannst.
Auf Servern im Internet würde ich das nicht unbedingt mehr machen.

Sobald das Zertifikat ausgestellt wurde, gehst du zu deinem Proxy Host und trägst das Zertifikat im "SSL" Tab ein.

Das wars eigentlich schon.


pasted-from-clipboard.png

Moin,

ansich kannst du für deine Domain einfach weitere Records mit der internen IP einrichten. Dafür musst du nichts freigeben und nur Leute aus deinem Netzwerk können damit was anfangen.

Damit du nicht immer den Port angeben musst würde es sich ggf. empfehlen einen zentralen Loadbalancer z.b. Traefik (da du schon Docker nutzt?) oder z.B. NGINX einzurichten und dann alle Subdomains auf die interne IP von diesem Server zeigen zu lassen.

Wenn du eine öffentlich verfügbare Domain, die dir gehört nutzen willst, kannst du sogar über LetsEncrypt mittels DNS Auth ein echtes SSL-Zertifikat für deine internen Dienste holen.

Alternativ würde sich anbieten, dass du eine eigene selbstsignierte Root-Zertifizierungsstelle erstellst (da gibt es auch ziemlich viele OpenSource Tools mit (Web)-GUI) und die selbsterstellten Zertifikate für deine Dienste darüber signierst. Dann musst du nur das Root Zertifikat als "vertrauenswürdige Stammzertifizierungsstelle" auf all deine Geräte ausliefern und nicht jedes Zertifikat, um die Warnungen zu unterdrücken.

Moin,

unabhängig davon benötigt man bei React/Vue/Angular NodeJS nicht unbedingt auf dem Webspace.
Es langt, wenn man es einmalig z.b. im CI oder auf dem eigenen Rechner baut und dann den generierten `dist/`-Ordner auf dem Webspace bereitstellt.

Der Ordner enthält dann alles, was benötigt wird, um die Anwendung bereitzustellen. Jenachdem ob man ein Clientside-Routing nutzt muss natürlich noch eine entsprechende .htaccess angelegt werden, aber ein Template dafür sollte ja schnell im Netz zu finden sein.

Vielen Dank für eure schnellen Antworten.
Das hatte ich schon befürchtet, dass es nicht für die VPS gilt und nicht mehr ganz für die neueren Kisten gedacht ist.

Für mich würde das sowieso gerade keine Option sein, da ich aktuell nur VPS als "Spielkisten" zum Experimentieren bei Netcup hab die nicht so kritisch sind das die 99,9% bräuchten (mal schauen, was der Dezember noch so bringt ).

Ich hatte mich nur gewundert, dass meine VPS in der "Root-Server" Kategorie im UCP und im Shop unter der Kategorie "Server" angezeigt werden und ob es sich deshalb schon jetzt für mich lohnen würde dieses Produkt bei Sonderangeboten für ggf. spätere RS mitzunehmen (Das hat sich ja jetzt geklärt).

Moin,

Ich bin vorhin über die Produktbeschreibung der Erweiterung "Root-Server Service Level A+" gestolpert. Dort wird davon gesprochen, dass es für alle Root-Server in einem Kundenaccount gilt. So weit so gut... Nur erschließt es sich mir nicht ganz, was bei der Erweiterung alles als "Root-Server" gilt, da auch meine VPS im UCP die Kategorie "Root-Server" besitzen.

pasted-from-clipboard.png

Geht es da tatsächlich nur um die Server die "Root-Server" im Namen haben? Wenn ja, finde ich die Kategorie der VPS im UCP etwas blöd gewählt.