Der Link macht es nicht besser. Der Link im Zusammenhang mit deiner Frage zeigt, dass du nicht im Entferntesten verstanden hast, worum es überhaupt geht. Deine Frage hat absolut NICHTS mit diesem Link zu tun, ist dafür auch überhaupt nicht notwendig und löst garantiert nicht das Problem, dass im Link adressiert wird.
Posts by frank_m
-
-
Habe mich schon informiert, aber nicht viel gefunden zu dem Thema.
Dann hast du schlecht gesucht, denn es gibt kaum ein Thema, über das man mehr Informationen findet.
Weil ich aufgrund von ratelimit die IPv6 Adresse ändern muss durch Tunnebroker
Du brauchst ja gar keinen Tunnelbroker, da du ja natives IPv6 hast. Also kannst du auch in kein Ratelimit laufen. Vielleicht solltest du dein Problem mal präzise beschreiben, denn so ist es Unfug.
-
Wie mache ich das, dass mein Server auf alle möglichen Ipv6 Adressen ansprechbar ist?
Warum um Himmels Willen sollte man das wollen? Ja, es gibt Anwendungsfälle, da macht eine 2. oder 3. IP Sinn, wenn man Ports mehrfach verwenden will. Aber ungefähr da hört es auf. Warum sollte man einen Server auf 264 Adressen lauschen lassen, was dann auch die Chance auf einen erfolgreichen Angriff um Faktor 264 erhöht?
Irgendwo hier in einem anderen Thread hast du den Hinweis bekommen, dich in die IP Grundlagen einzuarbeiten. Es wird allerhöchste Zeit dafür. Du bastelst da echt an einer Zeitbombe, das zeigt jede deiner Fragen. Dringender gut gemeinter Rat: Setze dir eine VM zu Hause auf und spiele daran herum. Da kannst du all deine Fragen genau so gut beantworten, aber viel weniger Schaden anrichten.
-
Tja, die Liste der potenziellen Fehlerursachen ist lang, und leider gibst du überhaupt keine Hinweise, woran es liegen könnte.
- IP-Konfiguration
- Firewall
- Serverkonfiguration (Apache, FTP, SSH, ...)
Was schon mal auffällt, dass du offenbar versuchst, das Prefix zu pingen. Hat der Server wirklich nur Nullen als HostID?
Also beschreibe doch mal für alle drei der genannten Punkte, was du getan hast, um die IPv6 Verbindung zu ermöglichen.
-
Bei der Installation hat er mir ja direkt eine Netzwerkverbindung ens3 und eine Linux Bridge vmbr0 angelegt.
Ja, und das sind hoffentlich auch zwei getrennte Interfaces und ens3 wurde nicht in vmbr0 integriert. ens3 ist das WAN Interface, während vmbr0 die interne Bridge für alle Container und das Host-System ist. Betrachte vmbr0 als ein internes LAN auf dem VPS, und ens3 als das Interface nach draußen. Bei dir zu Hause ist ens3 quasi der DSL Anschluss, während vmbr0 der Switch ist, der all deine Heimgeräte miteinander verbindet.
Und was ist zwischen DSL und Switch? Genau, ein Router. Die Rolle muss auch dein VPS übernehmen. Also IP-Forwarding, Routing, NAT und Firewall. Das wirst du von Hand einrichten müssen - ggf. in der Proxmox GUI, aber letztlich musst du es selber machen.
Wenn ich einen neuen Container erstelle, kann ich nur den vmbr0 auswählen. Welche IP und welches Gateway muss ich denn dann dort eingeben?
Du musst für vmbr0 ein internes Netz vergeben. Das kannst du dir im Grunde selber aussuchen aus dem Bereich der RFC1918 Adressen.
Grundsätzlich MUSST du dich mit den IP-Grundlagen befassen. Dazu gehört vor allem auch die Absicherung deines Systems für Angriffe von außen. Immer dran denken, dein System hängt vollkommen schutzlos im Internet, und es wird ca. 1 Angriff pro Sekunde darauf ausgeführt - auch jetzt schon.
Also ToDos:
1. Firewall einrichten. Sichere als Erstes dein System gegen Zugriffe von außen ab. Mach erst mal alles zu und öffne dann nur die Dienste, die du zwingend brauchst. Zugriff auf die Proxmox Oberfläche nur aus einem VPN heraus oder über einen SSH Tunnel. Ich würde im ersten Schritt den SSH Port auf irgendwas weit weg von Port 22 verlegen, Zertifikatsbasierte Anmeldung aktivieren und dann alle anderen Ports dicht machen. Zugriff erfolgt ab sofort nur noch über SSH mit passendem Zertifikat und über NICHTS anderes mehr.
2. Schau dir Grundlagen IP-Routing für IPv4 und IPv6 an. Dazu gehören vollwertiges Routen (besonders für IPv6) und NAT für IPv4. Portfreigaben und Portweiterleitungen gehören dazu (und müssen dann auch in der Firewall berücksichtigt werden).
Tutorials als Video oder in Schriftform gibt es reichlich. "iptables", "nftables" oder "ufw" sind die Suchbegriffe für Punkt 1, dazu kommt SSH Portforwarding. "iproute2" ist der Suchbegriff für Punkt 2. Wichtig: Tippe nicht einfach irgendeine Beispielkonfiguration aus einem Tutorial ab, denn die ist garantiert falsch. Du musst VERSTEHEN, was da abgeht, und dann die Konfiguration an dein System anpassen. Das gilt für beide Punkte.
-
Wer seinen eigenen Router hat, braucht keine zusätzliche Firewall.
Kommt drauf an. Für IPv4 stimme ich da zu. Für IPv4 wird im Kundenrouter üblicherweise NAT gemacht, was implizit mit einer eingehenden Firewall gleichgesetzt wird. Für IPv6 sieht das natürlich anders aus.
Die Frage ist, ob man den Begriff "Firewall" mit einer zusätzlichen Instanz außerhalb des Routers gleichsetzt. Häufig übernimmt ja eine Instanz das Routing und die Firewall, wie es ja auch die genannten pfSense etc. machen. Ich denke, man braucht eine Firewall, aber die kann im Router integriert sein. Es müssen nicht zwei separate Einheiten sein. Aber so völlig schutzlos würde ich meinen Anschluss auch nicht hinter einem Mobilfunkmodem betreiben - zumindest an einer Stelle will ICH konfigurieren können, was in mein Netz rein und raus geht.
-
Laut Microsoft Lizenzbedingungen muss die Lizenz die Anzahl der Cores des Host Systems abdecken, und nicht die des virtuellen Servers. Das heißt 64 Cores und nicht 16.
-
War es nicht so, dass die Windows Lizenz genug Cores für den Host abdecken musste, und dass die Anzahl der Cores in der VM dabei egal ist? Sprich, du brauchst eine Lizenz für 64 Cores und nicht für 16?
Windows Lizenzen für VPS ohne Unterstützung vom Hoster zu beziehen, ist sehr schwierig. Da würde ich eine andere Lösung suchen.
-
Genau. Wir vertrauen einfach mal darauf, dass es keinen Fehler in der Konfiguration gibt und auch die anderen Kunden im gleichen Netz den Anschluss nicht erreichen können. Von außen ist vielleicht nicht möglich, aber von innen? Über einige 10.000 potenzielle Teilnehmer reden wir da auch.
Unwahrscheinlich? Das kommt nicht vor? Tja, da wurden wir schon eines Besseren belehrt.
https://www.heise.de/newsticker/meldung/Wenn-der-Nachbar-heimlich-mitsurft-153559.html
Ob nun Mobilfunk oder DSL ist in dem Fall egal. Wenn der Provider nicht aufpasst, dann können sich die Endkundenanschlüsse gegenseitig erreichen. Klar, das ist eine Störung, aber in dem Fall ist man dankbar für eine Firewall.
-
-
Hast du versucht, einen Snapshot in den ISO Ordner zu kopieren? Das wird nicht klappen.
-
Sind Snapshots gespeichert?
-
Wieso fliegen meine Steckdosen ständig aus dem WLAN? 1-2 mal täglich..
Sowas sind häufig Probleme mit dem Energiesparmodus. AP und Client können sich nicht auf ein Energiesparintervall einigen, und irgendwann kriegen die Clients das Groupkey Update nicht mehr mit - Exit.
Welcher WLAN Router dafür der beste ist, kannst nur du selber herausfinden. Solcherlei Kompatibilitätsprobleme können in allen denkbaren Gerätekombinationen auftreten.
-
Also new ubuntu need to have it as a KVM file to allow me to move from a root server to another when it comes.
Sorry, I didn't get this. Do you want to have a snapshot?
Ubuntu 22 is available as Image and as ISO installation. So no problem to make a clean install.
-
Es sind Netzwerkprobleme, das mit dem DNS war Quatsch, sorry. Die Pakete von B->A gehen erst auf dem letzten Hop verloren.
Damit ist es ein Netzwerkproblem, und zwar in unmittelbarer Nähe von Server A, möglicherweise sogar auf dem Host von A.
-
Das die eingetragenen Nameserver Probleme machen könnte ja doch maximal bei den Pings von A zu B sein (ich pinge ja hostnames, keine Ip-Adressen) aber wenn B zu A pingt sollte es ja egal sein ob A eine funktionierende Namensauflösung hat oder?
Doch, damit sind DNS Probleme plötzlich wieder ganz oben auf der Liste. Wer kann auch ahnen, dass du solche Tests mit Hostnamen machst? Es ist zwar egal, ob A eine funktionierende DNS Konfiguration hat, aber die Auflösung von B kann auch scheitern.
-
Nach der Beschreibung bin ich auch skeptisch, dass es DNS Probleme sind. Warum treten die auf bei einem Ping auf eine IP Adresse?
Wo treten die mtr Verluste auf? Das ist die entscheidende Frage. Wenn es innerhalb des Netcup Netzes ist, dann müssen sie tätig werden. Das kann man aber nur am Trace sehen. Wenn du von uns Hilfe willst, soll du die Traces posten.
-
Zum OPNsense Server habe ich IPV6 /64 Netzwerk erhalten.
Ist das das mitgelieferte /64 Netz, dass praktisch alle Server hier haben? Dann warten einige Herausforderungen auf dich.
Zunächst brauchst du einen NDP Proxy, da das Netz nicht geroutet wird. Wie das unter BSD geht, weiß ich nicht. Unter Linux gibt es den ndppd.
Darüber hinaus gibt es bei Netcup aber immer noch das Problem, dass es sporadisch zu Paketverlusten kommt. Dafür gibt es bis heute keine Lösung. Man kann durch regelmäßige Datenpakete versuchen, die NDP Tabellen in den umliegenden Servern aktuell zu halten, aber es reduziert das Problem nur und löst es nicht.
Da bleibt nur ein zusätzliches geroutetes IPv6 Netz. Oder sowas wie ein HE Tunnelbroker. Die funktionieren üblicherweise problemlos (wobei es bei HE zuweilen auch zu UDP Paketverlusten kommt).
-
Zudem unterstellst Du Tailscale ständig, "bei Fehlern wegen der Netzwerkwahl Daten zu leaken". Als Softwareentwickler kannst Du Dir ja gerne https://github.com/tailscale/tailscale (ist open source) ansehen und uns Fehler aufzeigen
Kurz als Nachtrag dazu: Der Fehler, alle Kunden mit einer unique Adresse aus einem großen Pool zu versorgen, ist ein Fehler im Design, nicht in der Implementierung. Ein Codereview hilft da nicht.
-
Die beiden Posts sind eben solche Allgemeinsätze ohne wirklich Nennung des Problems mit dem 100 Netz oder wie man es, Deiner Meinung nach, hätte besser machen sollen (einer Lösung) oder welche Netzwerkbereiche mit welcher Begründung man statt dessen hätte verwenden sollen.
Wenn wir jetzt auch noch Grundlagen IP-Networking durchgehen müssen, wird es sehr lange dauern. Es geht ums Prinzip, die technischen Details kann man sich herleiten. Wenn du aus der Beschreibung nicht aufs Problem zurückschließen kannst oder es nicht abstrahiert bekommst, kann ich dir auch nicht helfen. Und die Verbesserung hab ich auch bereits beschrieben, ich spare mir den erneuten Hinweis aufs Lesen der Beiträge.
Die IP Ebene ist doch bei verschlüsselten Wireguard Tunneln nahezu egal.
Nein, eine funktionierende IP-Konfiguration und Routen braucht man auch da noch. Und da ist eben die Frage, ob man dafür was tun muss, oder ob es sich von allein ergibt.
Ansonsten vergeht mir so langsam die Lust, immer und immer wieder den gleichen Sachverhalt zu erklären. Ich weiß nicht, ob du es nicht verstehen kannst oder nicht willst, ist mir aber auch egal. Wichtig ist, das andere für das Problem sensibilisiert wurden und das in ihre Bewertung einfließen lassen können.
