Please, make yourself familiar with basic knowledge about IP networking. And I mean really just the very basic knowledge.
How will you manage your server when it comes to Firewall and security settings? Be aware that your server is attacked once per second as soon as it has a public IP address. And there is no system firewall at Netcup, like other hosters do it. You have to configure everything on your own. Are you sure, you are able doing this?
All required Information is in the SCP, as well for IPv4 as for IPv6.
Ok, that's not a problem of the VPS. There are several targets showing around 2 GBit/s. That means, if there is a problem, it's a routing issue, but nothing related to the VPS.
Path MTU Discovery kann auch aufgrund einer Einschränkung eines Routers zwischen dir und dem Teams Server schief gehen. Das muss nicht an dir liegen. Dann bleibt nur MSS Clamping.
Ping ist zwar ICMP, aber ICMP ist nicht (nur) Ping.
Die entsprechenden ICMP Pakete lässt du durch? Kannst du MSS Clamping im Router einrichten?
Versteh ich nicht ein mailserver vergibt doch die IP nicht.
Es geht nicht um deinen Mailserver, sondern um die der Gegenseite: Google, Microsoft, GMX, ... Die akzeptieren keine Mails, die von Servern mit dynamischen Adressen kommen.
Ja. Netcups Webhosting bietet von Haus aus kein Python:
https://saschaszott.github.io/2021/02/14/netcup-python-webhosting.html
I've already contacted support, let's see if there's something they can do from their end.
No. As I said, everything is working like expected. It's up to you.
And consider my first post. It is a serious issue to host an own VPS! You are responsible for all damage that is caused with your machine, if someone hacks it.
Perfect. Looks good. Everything works like expected.
Do you have a clue what you are doing? SCP for console? "Debugging" network problems? Oh dear.
Please don't use a VPS which is open to the internet. It will be hacked within seconds, and it is obvious, that you don't have the knowledge to prevent it. Install a Linux Server distribution in a Virtual Machine at home and train all necessary configurations in the next months: network, firewall, applications, WAF and so on. Afterwards, if you are really know what you are doing, come back and try a VPS. And I'm serious: It takes months to learn all the necessary things, in particular hardening the server against attacks on different ways. Remember: There is one attack per second on a public IP!
Ich würde die abgehende Kommunikation auf keinen Fall über eine zusätzliche IP laufen lassen, schon aus dem Grund, weil sie über die Standard-IP des Servers geroutet wird. Von daher: Die LFT kleiner, als bei den Standard-IPs. Dann gibt es keine Probleme, und man kann die Failover-IP jederzeit wegnehmen, ohne dem Server ein Problem zu bereiten.
Root-Server: "netcup Root-Server: Starke ARM-Leistung, grenzenlose KVM-Flexibilität."
Ich verstehe im Moment überhaupt noch nicht, warum das wichtig sein sollte. Es ist doch vollkommen egal, was diese Geo Dienste über eine IP sagen, solange sie richtig geroutet wird.
Der Suchbegriff lautet NDP Proxy, oder ndppd. Im Unterschied zu H ist das mitgelieferte /64 geswitcht und nicht geroutet. Es gibt bereits zahlreiche Threads dazu. So richtig wirst du es nicht zum Laufen bekommen, es wird immer noch Paketverluste geben. Stabil läuft es nur mit einem weiteren /64.
Wie lange dauert eine solche Umstellung in der Regel bis sie komplett durch ist ?
Da es zig verschiedene Anbieter dafür gibt und man nie weiß, auf welche Quellen die sich berufen, dauert es Monate oder sogar Jahre. Wir haben Zugangsnetze einiger Internetprovider in Deutschland, die sind seit 5 Jahren in Benutzung und werden teilweise immer noch im Pazifik verortet.
Mit traceroute habe ich auch gesehen dass der letzte HOP irgendwie in AUT ist und nicht wie bei meinem "originalen" Server in DE
Traceroute gibt keine Ortsinformationen aus. Und wenn du die IP verortet hast: Siehe oben.
Genereller Hinweis: Es macht Sinn, die Adressen zu anonymisieren, aber nur soweit es für die Anonymisierung nötig ist. So sind fast alle oben stehenden Angaben wertlos. Man erkennt nicht mal, ob das nun Ausgaben vom Server oder vom Client sind.
inet6 **:**:**:**:**:**:**:**/48 scope global
/48 ist bei Netcup ungewöhnlich. Dort gibt es üblicherweise /64 Netze. Das könnte die Ursache für die Probleme sein, wenn damit die Anfragen aus dem gleichen Netz kommen (z.B. von einem anderen Netcup Rechner).
default via **:**:**:**:**:**:**:** dev ens3 proto static metric 1024 pref medium
Auch das ist für Netcup ungewöhnlich, da dort das Gateway üblicherweise auf fe80::1 liegt. Ist das vom Client?
Ich empfehle, auch die anderen Fragen zu beantworten.
Er hat sowohl IPv4- als auch IPv6-Adressen, aber IPv6-Verbindungen scheinen irgendwie blockiert zu werden.
Auch ausgehend? Stimmt das Routensetup?
Bei curl -6 -I https://example.com kommt aber diese Fehlermeldung.
Und der Client spricht auch einwandfrei IPv6, inkl. Routing?
Apache-Konfiguration: Der Webserver ist auf Port 443 für sowohl IPv4 als auch IPv6 konfiguriert.
Und das bestätigt ein Aufruf von "netstat -tuplen"?
DNS: Der AAAA-Record ist korrekt gesetzt.
Und er wird beim Client auch entsprechend aufgelöst?
Wenn das alles der Fall ist, solltest du dir mal mit tcpdump anschauen, was den Client verlässt, und was den Server erreicht. Vor allem: Schau dir auch den Rückweg an.
* max ICMP 1450 sowohl ins Internet als auch ins vLAN
Dann ist klar, dass die MTU 1500 zu groß ist.
Nöö, sollte nicht. Der Hostname löst so auf. Vielleicht ist das nicht deine Vorstellung, aber die DNS Einstellung ist im Moment so.
TTL nicht bedacht?
