iperf3 Tests hast du zu deinem Server ja schon gemacht. Auf Client Seite kannst du durch ein einfaches "-u" UDP Tests durchführen. Bedenke, dass du dabei eine Geschwindigkeit mit angeben musst, sonst findet der Test nur mit 1 MBit/s statt. Ich würde mit 100 MBit/s anfangen und mich dann nach oben unten vortasten, bis die Paketfehlerrate in der Schlussstatistik bei maximal 2% ist. Das ist dann die etwa zu erwartende UDP Datenrate zwischen deinen Systemen.
iperf3 -c <server> -u -b 100M
Da Wireguard mit UDP und nicht mit TCP arbeitet, werden die Congestion Control Algorithmen gar nichts ändern.
Du musst mit UDP testen, ob es Paketverluste gibt, ob sie von der Paketgröße oder der Paketfrequenz abhängen, usw. Alles andere bringt dich nicht weiter. Immer dran denken: UDP. Nicht TCP. Die klassischen Tipps für Internetzugänge oder langsame Downloads gehen am Ziel vorbei.
Da ich hinter einem CGNAT hänge kann ich es leider nicht einfach so freigeben/nutzen, da mir eine eindeutige öffentliche IPv4 fehlt.
Warum nicht per IPv6?
Auf Seite des Root Servers läuft caddy und dient als reverse proxy der entsprechenden Wireguard IP+Port.
Warum das? Warum keine direkte Portfreigabe?
IPerf zeigt hier das identische verhalten sowie Paketverlust.
Paketverluste wären eine sehr zuverlässige Erklärung für dein Problem. Hast du iperf mit UDP oder mit TCP getestet? Was für einen Internetanschluss hast du und gibt es UDP Paketverluste auch zu anderen Zielen? Es gibt ja einige öffentliche iperf Server im Netz, gegen die man testen kann.
Every time I install Ubuntu on my Netcup server I’m unable to log in via SSH using the root account because PermitRootLogin is set to false by default in the SSH config.
That's interesting. If you're using an Ubuntu ISO image for the installation, PermitRootLogin won't be set to 'false'. Or, if you're using a Netcup image, you can upload a certificate for logging in during installation. In both cases, you can log in as root afterwards.
Vielleicht verstehe ich völlig falsch, was ein Forum ist, aber ich hatte den Eindruck, dass es um eine konkrete Problemstellung geht und nicht um hypothetische Anbieter mit hypothetischen Kunden, die ohne rudimentäre IP-Kenntnisse Server mit 32 Adressen buchen.
Das makabere ist ja, dass es bei IPv4 funktioniert und bei IPv6 nicht, weil man bei IPv4 nur eine Adresse bekommt und bei IPv6 ein ganzes Subnetz. Der größte Vorteil von IPv6 und die größte Einschränkung von IPv4 wird genutzt, um zu begründen, dass man IPv6 nicht braucht. Wäre es nicht so traurig, könnte man drüber lachen.
Ich habe nicht generell von IPv6 abgeraten
Das liest sich in #5 noch anders, noch dazu gewürzt mit Falschinformationen. Alternative Fakten, oder wie nennt man sowas heutzutage?
Und ich habe (begründet!) erklärt, dass das keine nennenswerten Nachteile bringt,
Und wir haben dir begründet erklärt, warum das Unsinn ist.
Meine Bereitschaft, hier noch jemandem zu helfen, ist mittlerweile Null.
Das ist definitiv die gute Nachricht dieses Threads. Ende gut, alles gut.
Dreimal darfst du raten, ob Japaner IPv4-Hosts erreichen können oder nicht, und wie die korrekte Bezeichnung dafür ist, wenn jemand behauptet, sie könnten das nicht.
Dann fahr hin und probiere es aus. Wenn du mir traces vorlegst, die deine Behauptung beweisen, fange ich an, dir zu glauben.
Schau dir mal diese Seite an: https://radar.cloudflare.com/de-de/reports/ipv6
Das ist Request-Traffic von Cloudflare. So sieht die Welt wirklich aus. Browser bevorzugen IPv6, wenn es funktioniert. Wenn da IPv4 verwendet wird, hat das also Gründe. Noch eine andere Karte, IPv6-capable laut APNIC: https://stats.labs.apnic.net/ipv6
Bei Google sind es 50%, generell ist der Anteil der IPv6 Nutzer in Deutschland bei 72%, in Frankreich bei 75%. (Quelle: https://www.eco.de/event/ipv6-in-…den-zoegernden/, https://www.google.com/intl/de/ipv6/s…y-ipv6-adoption). Keine Ahnung, was Cloudflare da falsch macht.
Insgesamt sind diese Statistiken die besten Argumente, IPv6 zu unterstützen, aber nicht, es wegzulassen.
Leider ist Argumentation nur Perlen vor die Säue.
Sagt ausgerechnet der, der reihenweise Argumente einfach ignoriert und nicht drauf eingeht. Wenn es wirklich so schlimm ist, dann wiederlege sie doch mal.
IPv4 only - Problem auf Anhieb gelöst.
Falsch. Symptome beseitigt. Nicht Problem gelöst. Und wie das so ist, wenn man Symptome anstatt Ursachen bekämpft: Das kommt wieder.
Amazon sieht das anders.
Oha. Vielleicht besser mal recherchieren, bevor man solche unausgegorenen Behauptungen in die Welt setzt?
PS C:\Users\frank> nslookup www.amazon.com
Server: pi.hole
Nicht autorisierende Antwort:
Name: d3ag4hukkh62yn.cloudfront.net
Addresses: 2600:9000:2057:5800:7:49a5:5fd4:b121
2600:9000:2057:6600:7:49a5:5fd4:b121
2600:9000:2057:8200:7:49a5:5fd4:b121
2600:9000:2057:9800:7:49a5:5fd4:b121
2600:9000:2057:5e00:7:49a5:5fd4:b121
2600:9000:2057:4400:7:49a5:5fd4:b121
2600:9000:2057:e400:7:49a5:5fd4:b121
2600:9000:2057:4800:7:49a5:5fd4:b121
99.86.8.42
Aliases: www.amazon.com
tp.47cf2c8c9-frontier.amazon.com
PS C:\Users\frank> nslookup www.amazon.de
Server: pi.hole
Nicht autorisierende Antwort:
Name: djvbdz1obemzo.cloudfront.net
Addresses: 2600:9000:27e6:ae00:e:13a1:b915:1361
2600:9000:27e6:1e00:e:13a1:b915:1361
2600:9000:27e6:1800:e:13a1:b915:1361
2600:9000:27e6:b600:e:13a1:b915:1361
2600:9000:27e6:3200:e:13a1:b915:1361
2600:9000:27e6:5000:e:13a1:b915:1361
2600:9000:27e6:e200:e:13a1:b915:1361
2600:9000:27e6:2200:e:13a1:b915:1361
3.167.224.170
Aliases: www.amazon.de
tp.abe2c2f23-frontier.amazon.deGithub sieht das anders.
Github steht kurz vor der Aktivierung von IPv6, nachdem sie von den IPv6-only Nutzern seit Monaten gebügelt werden.
https://github.com/orgs/community/discussions/10539
https://www.reddit.com/r/ipv6/comments/1ajb7a5/github_is_working_on_ipv6_support/
Deine Insel wird kleiner. Sehr schnell.
Umgekehrt hat ein IPv4-only Dienst praktisch keinen Nachteil.
Die Aussage ist bei DS-Lite und CG-NAT an den meisten deutschen Internetanschlüssen ... ich finde keine Worte, die nicht beleidigend sind. Bei der Gelegenheit, es ist beeindruckend, wie du relevante Argumente einfach ignorierst.
Das hat einen einfachen Grund: Wer IPv4-only Hosts nicht anständig erreichen kann, ist nach allen vernünftigen Maßstäben nicht im Internet.
Was nützt es einem, die Hosts zu erreichen, wenn aufgrund kranker Architekturen die Dienste anschließend nicht laufen? Und glaub mir: Da machen fehlerhafte IPv4 Setups ERHEBLICH häufiger Ärger, als IPv6 Setups. Schau in die typischen Foren, Computerbase und ähnliche. Wenn sich dort jemand beklagt, dass er gewisse Internetseiten nicht erreichen kann, dann, weil IPv4 nicht funktioniert. IPv6 geht problemlos, aber der dusselige Serverbetreiber kann ja nur IPv4 - und dann merkt man es halt, wenn der AFTR mal wieder überlastet ist.
Und deshalb macht man IPv6 ohne Wenn und Aber. Diskussion beendet.
Es gibt nur eine verschwindend kleine Anzahl von armen Irren, die einen IPv6-only Host ohne die Möglichkeit betreiben, IPv4-only Hosts zu erreichen,
Du machst den Fehler und denkst, Europa oder die USA seien diesbezüglich der Mittelpunkt der Welt. 6 Milliarden Internetnutzer surfen ohne IPv4. Und niemand der von dir genannten Cloud-Riesen verzichtet auf IPv6, nur weil er (noch) IPv4 im Angebot hat. Übrigens auch bei AWS inzwischen das Standard-Protokoll, IPv4 gibt es nur noch mit besonderer Konfiguration.
Ich war kürzlich in Japan in einem Hotel, da gab es nur noch IPv6. Beim Gastgeber des Meetings gabs die perfekte WLAN Infrastruktur für Gäste - leider auch IPv6-only. In der Ecke stand ein alter Netgear WLAN Router mit 150 MBit/s Wifi-4, der konnte IPv4 - extra für diejenigen, die mit IPv6 nicht zurechtkamen. Da tummelten sich dann 20 Europäer und Amis und teilten sich die 60 MBit/s Brutto, die das Ding hergab. Und im IPv6-WLAN hatte man 400 MBit/s netto nach Hause.
Das Schlimme ist, dass es wirklich eine kleine Anzahl von Irren gibt, die Dinge wie DNS64 und NAT64 betreiben. Wenn ich nur an so einfache Dienste wie VoIP oder Wireguard denke, was das für einen zusätzlichen Aufwand bedeutet, dann stellen sich mir die Nackenhaare auf. Das kostet ERHEBLICH mehr Zeit und Geld, als die verbliebenen Server IPv6-tauglich zu machen, und das JEDEN Tag und JEDE Stunde. Zeit, Geld, Fachkräfte, Energie und damit CO2 Ausstoß. DAS ist die wahre Konsequenz der IPv6 Verdrossenheit.
Aber wir habens ja, sind der Nabel der Welt. Erfreue dich an deiner IPv4 Adresse und schau dabei zu, wie wir weiter als Technologienation abgehängt werden.
Sagt jemand, der den Rest des Beitrags erfolgreich ignoriert. 
Ja, nee, is klar. Solange die einzige Begründung dafür, IPv6 nicht einführen zu wollen, die ist, IPv6 nicht einführen zu wollen, könnt ihr euch eure Rechtfertigungen so lange basteln, wie es euch lieb ist. Bricht nur bei der ersten näheren Betrachtung wie ein Kartenhaus zusammen, denn einen sinnvollen Grund dafür, es wegzulassen, gibt es nicht, und Gründe dafür, es einzuführen, massenhaft.
DNS ist das geringste Problem, da DNSv6 Server auch IPv4 Adressen auflösen. Rettet dich aber nicht mit einer IPv6-only SIM im Handy.
Wer einen IPv6-only Server oder VMs nutzt, hat ziemlich sicher auch einen Server mit IPv4 Adresse und leitet Verbindungen zu IPv4 darüber
Nein, da ist der Wunsch Vater des Gedankens.
Die Mobilfunkanbieter, die IPv6-only Anschlüsse anbieten, machen das mit DNS64+NAT64, weil alles andere völlig unpraktikabel wäre.
Deshalb hatte ich CG-NAT und DS-Lite direkt mit aufgeführt. Wer will sowas? Anzahl der verfügbaren Ports stark eingeschränkt, häufigste Ursache für Performance-Probleme, keine Serverports, ... man muss schon die ein oder andere Kröte schlucken. Und warum? Weil es immer wieder Ignoraten gibt, die kein IPv6 einführen (Ähnlichkeiten mit Anwesenden sind rein zufällig).
Aber auch das funktioniert nicht mehr immer, vor allem nicht bei den Reise-SIM Anbietern. Von Fernost will ich da gar nicht reden, da reicht ein Blick ins benachbarte Ausland.
Wie du dazu stehst, ist aber egal. Du entscheidest es nicht, und dass Congstar, das rote H und zahlreiche europäische Anbieter sowas anbieten, steht auch fest - ganz zu schweigen von den Reise-SIM Anbietern.
Auch wenn du es nicht magst, auf IPv6 verzichten kann man nicht mehr.
Zwar ohne IPv6, was man ja lt. eurer Aussage verschmerzen kann.
Das sehe ich anders. Es gibt inzwischen mehrere IPv6-only Angebote, sei es bei anderen Server-Anbietern, im Mobilfunk oder auch beim Internetzugang. Nicht zuletzt sind IPv4 Zugänge häufig nur eingeschränkt nutzbar (DS-Lite, CG-NAT). Ein einem vernünftigen IPv6 Setup führt heute kein Weg vorbei, sonst sperrt man sich direkt von einem Teil der Zugänge aus.
Kann es dann wieder sein, das die IPv6 dann wieder auf das zugewiesene Hosting geht?
Wenn du die richtige IP einträgst, natürlich nicht.
Daran kann der Fehler nicht liegen, das ich die Domain einen Webhosting zu gewissen habe und die IPv4& auf den VPD umgeroutet habe?
Die Domain löst die IPs auf, die du eingetragen hast.
Ich wage stark zu bezweifeln, dass sowas wie DHCP irgendeinen sittlichen Mehrwert für einen Server hat. Das kann man vielleicht aktivieren, damit man im Notfall ein Rescue Image starten kann, ohne die Konfiguration händisch anzupassen. Für den Regelbetrieb ist ein zustandbehaftetes Protokoll wie DHCP für die Adressverteilung ein absolutes NoGo!
First I would try the rescue system, mount die filesystem and open a port in the firewall. Afterwards, SSH should work again. It seems, the IP blocker is too strict.
But you can reach your server via Apache? Then it is up to you to ensure SSH is working. Network connection is obviously working.
Ich habe es auf verschiedenen Systemen ausprobiert, Step by Step, Aber immer den gleichen Fehler bekommen --> Tls: failed to verify certificate: x509 bei der Installation von Pangolin.
Das ist schon eher ein greifbares Problem. Hat nur leider absolut gar nichts mit deiner obigen Fragestellung zu tun.
Dachte gestern noch der Fehler liegt am Port, aber so wie es aussieht, habe ich Probleme mit SSL certificates (https) via LetsEncrypt
.
Die Frage ist, was die Fehlermeldung auslöst. Es kann durchaus ein Problem mit Ports sein, wenn du z.B. auf den falschen Server zugreifst.
Problem ist, wenn ich Nginx eine Subdomaine, das SSL Certificates holen will, bekomme ich eine Fehlermeldung, das er nicht verbinden kann, Port 80 ist aber geöffnet.
Der Satz löst eine Millionen Fragen in meinem Kopf aus. Je nachdem, wie du das aufgesetzt hast und wo die beteiligten Komponenten sitzen, kannst du da sehr viel falsch machen.
Benutze jetzt mal Ubuntu, muss mich aber ein wenig umgewöhnen (arch). Melde mich am abend nochmal, wenn das Problem dort auch auftritt.
Das hört sich nicht so an, als ob das Einfluss haben kann. Ich hab zum zweiten Mal die Befürchtung, dass du ein Problem lösen willst, das du gar nicht hast.
Bin da schon einige Tage dran
Da kann ja was nicht stimmen. Wenn du Pangolin auf mehreren Systemen installiert hast, hast du ja auch mehrfach den Port verfügbar. Den kann dir Unify auf diesen Zielsystemen also gar nicht belegen.
Kann mir jemand helfen, wo ich überall den Wiregard Port ändern muss.
Warum willst du das? Unify hört sich für mich nach Router an. Da du behauptest, Unify würde dir den Port belegen, klingt das so, als liefen diese Systeme hinter der Unify. Wahrscheinlich sollen sie nun von außen über den Unify Router erreicht werden. Ist das richtig? Dann hilft dir das Ändern der Ports in Pangolin nicht weiter.
Beschreibe bitte ausführlich und präzise, wie dein Setup aussieht und was du eigentlich vorhast. Im Moment wird kein Schuh draus, oder anders ausgedrückt: Offenbar suchst du eine Lösung, für die du kein Problem hast.
