Beiträge von terence

Can you post the output of the following commands?
ip -6 addr
ip -6 route
ip -6 neigh

Zitat von Paul

Ich versuche auch auf extra Tools oder komplizierte Setups zu verzichten, kein VPN, keine dynamischen Firewall Regeln, keine Cronjobs, die Zugriffe verwalten (Keep it simple ;-)).

+1
Daher werde ich wohl auch den Jumpserver in Rente schicken, den ich noch für einige VPS verwende.
Dann habe ich einen Server (und einen Single-Point-Of-Failure) weniger um den ich mich kümmern muss. Und die Konfiguration der VLANs entfällt auch. Jeder Server hat dann seine eigene dedizierte IPv6-Adresse für SSH (siehe meinen obigen Post).

Es ist aber mittlerweile ja so, daß auch IPv6-Adressen gescannt werden, weshalb man u. a. keine leicht zu erratenen Adressen verwenden sollte. So gibt es beispielsweise auf https://ipv6hitlist.github.io/ eine Liste mit aktuell rund 32 Millionen gefundenen IPv6-Adressen. Diese enthält 6587 Adressen mit dem netcup-Präfix 2a0a:4cc0::/32 und 115337 Adressen mit 2a03:4000::/32.

Für die SSH-Anmeldung verwende ich einen Public Key und zusätzlich ein Passwort (AuthenticationMethods publickey,password).
Der Benutzer, mit dem ich mich anmelde, hat keine Berechtigung, Befehle als root via doas (sudo) auszuführen. Dazu wechsle ich in einen Admin-Account.

Yeah, it's not working here, yet.
So did you successfully configure the interface and the gateway?
And does the telnet command from your initial post work when you execute it on the server?
Can you reach the internet via IPv6 from the server (does ping 2620:fe::9 work for example)?

Beim GitHub-Link bekomme ich 404. Ist das Repository noch nicht public?

Gibt es in /etc/sysctl.conf Einträge mit …disable_ipv6 = 1?

Zitat von Becker

Damit habe ich den SSH Zugriff a) auf nur IPv6 limitiert und b) nur auf die Netzwerke wo ich mich grundsätzlich aufhalte

Genauso mache ich es auch. Aktuell logge ich mich nur von Zuhause aus ein, weshalb ich mein /64-Präfix als einzige Quelle zulasse. Das Präfix habe ich in der netcup-Firewall eingetragen - so kommt erst gar nichts anderes beim Server an. Trotzdem macht es Sinn, das auch in der Server-Firewall zusätzlich zu konfigurieren, falls die netcup-FW mal nicht greift (weil z. B. testweise deaktiviert).

Für SSH verwende ich eine zufallsgenerierte IPv6-Adresse, die ausschließlich für SSH benutzt wird. Die preferred lifetime der Adresse steht auf 0, so dass sie als deprecated gilt und somit auch nicht für ausgehende Verbindungen genutzt werden sollte (die valid lifetime ist unendlich). Auf anderen IP-Adressen lauscht sshd nicht.

P.S.: Damit die SSH-Adresse nicht für ausgehende IPv6-Verbindungen genutzt wird, muss es natürlich mindestens eine andere IPv6-Adresse geben, die dafür verwendet werden kann.

Zitat von NaN

Optional

Ja, danke für die Ergänzung! Ich würde sie aber trotzdem eintragen. Dann hat man einen Fallback, falls die IPv4-Pendants mal nicht erreichbar sein sollten.

Ja, Du musst die Netzwerkkonfiguration um IPv6 erweitern. Also die o. g. IPv6-Adresse dem Interface zuweisen (mit Präfixlänge 64), das IPv6-Gateway einrichten (meistens fe80::1, ich hatte aber auch schon eine andere Adresse) und IPv6-DNS-Server ergänzen. Die genaue Adresse des Gateways findest Du im SCP auf dem Netzwerkreiter ganz unten. Als DNS-Server kannst Du z. B. die netcup-Server 2a03:4000:0:1::e1e6 und 2a03:4000:8000::fce6 benutzen.

Nach den Anpassungen solltest Du auch testen, ob die Einstellungen einen Reboot überstehen.

Zitat von jdeisenberg

openSUSE Leap version 15.6

Version 15.6 wird offenbar (seit 30.04.2026) nicht mehr unterstützt, weshalb Du auf eine neuere Version gehen solltest. Siehe https://de.opensuse.org/Produktlebensdauer

Zitat von Spoils5461

Hast du es aus dem postfix und dem unbound Container heraus probiert?

Ich habe kein mailcow. Das ist eine „normale“ unbound-Instanz, die direkt auf dem VPS läuft.

Zitat von SiebenG

Mein Monitoring zeigt seit dem 28.7. ab 22 Uhr bis jetzt deutlich erhöhte ipv6 ping Zeiten an

In meinem Monitoring (von Berlin und Düsseldorf aus) kann ich nichts dergleichen sehen.

Ich kann den SRVFAIL übrigens mit meinem unbound erwartungsgemäß nachstellen, wenn ich tcp-upstream: yes einstelle und sehe dann im unbound-Log Fehlermeldungen wie diese (mit den o. g. Log-Einstellungen):

error: SERVFAIL <microsoft-com.mail.protection.outlook.com. A IN>: all servers for this domain failed, at zone mail.protection.outlook.com. upstream server timeout

dig meldet bei mir dann auch einen Timeout - ich bekomme also keine Antwort wie es bei Dir der Fall war. Aber Query time: 4000 msec bei Dir deutet m. E. auch auf einen Timeout hin. Vielleicht sind die timeout-Einstellungen von unbound bei uns unterschiedlich, so daß Dein unbound nach 4 Sekunden abbricht und SRVFAIL zurückmeldet. Bei mir versucht er es länger und dig bricht dann wohl selbst ab.

Soweit so gut. Mir ist allerdings (immer noch) nicht klar, warum der Aufruf mit Deinem unbound-Container funktioniert hat, obwohl laut Beitrag #23 ja offensichlich auch unbound als Resolver verwendet wurde (SERVER: 127.0.0.11#53(127.0.0.11) (UDP)). Das hätte doch genauso fehlschlagen müssen. Da wäre es dann mal interessant, die Logs zu sehen... Wenn Du also noch mal Lust hast, das auszuprobieren, würde mich das Ergebnis interessieren. Wenn nicht, ist es aber auch nicht schlimm.

Ach ja... wie ist das mit NTP? Hast Du das in der netcup-Firewall konfiguriert, so daß Du keine Probleme mit der Systemzeit bekommst?

Schön, daß es nun funktioniert!
Da ich den folgenden Text schon geschrieben hatte, poste ich ihn trotzdem noch - vielleicht ist er ja für andere hilfreich.


Du könntest noch in das Log von unbound schauen, wenn Du das noch nicht getan hast.

Dazu macht es vermutlich Sinn, die unbound.conf anzupassen, damit weitere Infos protokolliert werden:

        log-queries: yes
        log-replies: yes
        log-tag-queryreply: yes

Und diese Option klingt für Dein Problem auch vielversprechend:

     log-servfail: <yes or no>
            Print log lines that say why queries return SERVFAIL to clients.
            This is separate from the verbosity debug logs, much smaller, and
            printed at the error level, not the info level of debug info from
            verbosity.

            Default: no

Angesichts der aktuellen Speichersituation wäre es andersrum doch auch viel sinnvoller, oder?

„Hey, brauchst Du wirklich so einen fetten Server? Wir haben auch picos - damit sparst Du x Euro!“

Zitat von abo

Seit wann wird man beim Legen eines Produkts in den Warenkorb so aufdringlich zu einem Upgrade gedrängt? Das war doch nicht schon immer so, oder?

Nee, das ist neu. Finde ich (auch) nervig. Das hat sich netcup wohl von IhOhNos abgeschaut.

Zitat von Spoils5461

Mich verlässt der Mut.

Na, nicht zu schnell aufgeben! Man wächst und lernt mit den Herausforderungen! Ich habe heute z. B. gelernt, daß man bei unbound für einzelne Domains forward-zone einrichten kann - das war mir vorher nicht bewusst.
Gönn' Dir eine Pause und dann schaust Du Dir das in ein paar Tagen noch einmal an.

P.S.: Die angehängte Datei sieht mir nicht nach der unbound.conf aus.

P.P.S.: Vielleicht magst Du Becker884 aus dem mc-Forum noch mitgeben, daß die Firewall sehr wohl funktioniert, wenn sie richtig konfiguriert wird. Man muss sich aber halt ein wenig damit befassen. Dabei helfen können die Hilfe und ggf. der Spickzettel von gunnarh. Bei Fragen und/oder Problemen kann man einen Beitrag im Firewall-Forum erstellen.

Den FORMERR bekomme ich auch. Mit +noedns bekomme ich NOERROR.

dig @ns1-proddns.glbdns.o365filtering.com AAAA microsoft-com.mail.protection.outlook.com +noedns

Da das ja zu gehen scheint, kann Dein VPS also den Name Server erreichen. Der zweite geht dann ja sicher auch? ns2-proddns.glbdns.o365filtering.com
Theoretisch könnte es noch sein, dass unbound versucht, den Name Server ausschließlich via IPv6 zu erreichen. Da dieser aber nur eine IPv4-Adresse hat, würde das fehlschlagen. Hast Du schon einmal versucht, mit tcpdump den Traffic zu analysieren?

Du hattest im mc-Forum folgendes geschrieben:

Zitat

Andere Domänen wie hotmail.com, outlook.com, microsoft.com … funktionieren ohne Probleme. Es muss irgendiwe mit mail.protection.outlook.com einen Zusammenhang geben.

microsoft.com verwendet aber offenbar auch mail.protection.outlook.com:

$ host microsoft.com
microsoft.com has address 150.171.109.101
microsoft.com has IPv6 address 2603:1061:14:64::1
microsoft.com mail is handled by 10 microsoft-com.mail.protection.outlook.com.

Funktioniert denn der folgende Aufruf ohne forward-zone?

/opt/mailcow-dockerized# docker compose exec postfix-mailcow dig AAAA microsoft-com.mail.protection.outlook.com

Der Aufruf dig AAAA mail.protection.outlook.com funktioniert auf meinem VPS auch - mit und ohne unbound. Mailcow ist da nicht drauf. Die IPv4-Adresse meines Servers beginnt mit 202.61.

Was kommt denn raus, wenn Du direkt auf dem VPS die folgenden Aufrufe machst? Dabei wird der jeweils verantwortliche Name Server verwendet.

dig @ns1-05.azure-dns.com A outlook.com

dig @ns1-proddns.glbdns.o365filtering.com A mail.protection.outlook.com

Ich kann das selbst gerade nicht testen, aber wenn ich nachher daheim bin, probiere ich es mal auf meinem VPS aus und kann dann auch mal meine unbound-Instanz darauf loslassen.