telnet 52.1.184.176:443
telnet: could not resolve 52.1.184.176:443/telnet: Name or service not known
telnet registry-1.docker.io:443
telnet: could not resolve registry-1.docker.io:443/telnet: Name or service not known
telnet 52.1.184.176:443
telnet: could not resolve 52.1.184.176:443/telnet: Name or service not known
telnet registry-1.docker.io:443
telnet: could not resolve registry-1.docker.io:443/telnet: Name or service not known
nslookup registry-1.docker.ioServer: 127.0.0.53Address: 127.0.0.53#53Non-authoritative answer:Name: registry-1.docker.ioAddress: 34.194.164.123Name: registry-1.docker.ioAddress: 18.215.138.58Name: registry-1.docker.ioAddress: 52.1.184.176
Ich kann aber keine dieser IP Adressen anpingen
UFW habe ich zum Spaß mal deaktiviert. Keine Änderung
Gut.
Und jetzt bitte noch ein „ping http://www.google.de“ und ein „curl -v http://www.google.de, nur so kann einfach überprüft werden ob die Namensauflösung auf deinem System klappt.
Das klappt beides. Mit 8.8.8.8 und 1.1.1.1 meinte ich die DNS Server geändert. Das hab ich mal eingetragen, bringt aber keine Änderung. Außerdem wird es ständig überschrieben. Und bei der Lösung des Problems, was jetzt dazu geführt hat den Snapshot einzuspielen, wurde wohl der ein oder andere Tipp gegeben bezgl. DNS Server ersetzen, der dem System den rest gegeben hat:(
Ja andere Pings möglich. 8.8.8.8 und 1.1.1.1 hab ich auch schon versucht
Hallo,
ich musste einen Snapshot einspielen, weil Firewall und DNS etc nicht mehr richtig funktionierten.
Wenn ich jetzt meine Docker Container neu ziehen will, erhalten ich das:
docker run
-d -p 8000:8000 -p 9000:9000 --name=portainer --restart=always -v
/var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data
portainer/portainer-ce
Get
"https://registry-1.docker.io/v2/": net/http: request canceled while
waiting for connection (Client.Timeout exceeded while awaiting headers).
Docker läuft.
Ich habe schon alle möglichen Google Tipps probiert. Nichts hat geholfen bzw. ist hier relevant (Proxy und so).
Ubuntu 20.0.4. LTS Server
Kann jemand weiterhelfen?
Danke
Ich glaub da kommen wir nicht mehr weiter, muss wohl doch der Snapshot ran
lslocks.JPGWas sagt lslocks?
Evtl. steht da ja auch der Verursacher des xtables lock drin.
Du kannst ja testweise mal ipv6 in /etc/default/ufw deaktivieren. (IPV6=no)
Keine Änderung
systemctl status ufw.service
● ufw.service - Uncomplicated firewall
Loaded: loaded (/lib/systemd/system/ufw.service; enabled; vendor preset: enabled)
Active: active (exited) since Thu 2023-04-20 10:40:17 CEST; 1min 20s ago
Docs: man:ufw(8)
Process: 380 ExecStart=/lib/ufw/ufw-init start quiet (code=exited, status=0/SUCCESS)
Main PID: 380 (code=exited, status=0/SUCCESS)
root@srv2:/home/xxx# ufw status
ERROR: problem running iptables: Another app is currently holding the xtables lock. Perhaps you want to use the -w option?
Alles anzeigenDem folgt dann noch ein: rm /etc/resolv.conf - dann kannst du die Datei mit einem Texteditor deiner Wahl wieder anlegen und mit DNS Servern befüllen.
Für Google
Codenameserver 8.8.8.8 nameserver 8.8.4.4 nameserver 2001:4860:4860::8888 nameserver 2001:4860:4860::8844
Für Cloudflare
Codenameserver 1.1.1.1 nameserver 1.0.0.1 nameserver 2606:4700:4700::1111 nameserver 2606:4700:4700::1001
Und einmal prüfen, ob das ganze einen Neustart überlebt
Das funktioniert jetzt schon mal, und bleibt auch nach einem Neustart erhalten. Pings etc gehen wieder. DNS scheint repariert...
UFW lässt sich dagegen immer noch nicht wieder aktivieren:
ufw status
ERROR: problem running ip6tables
Aber da muss ich dann morgen weitermachen. Wie gesagt, schon mal danke für heute
Trotz
Machen wir erstmal DNS. Was hast du bei resolv.conf / systemd-resolved bisher so gemacht?
Was der Kollege empfohlen hat:
Wie gesagt, ich hab das, was hier empfohlen wurde umgesetzt...
Trotzdem Danke.
Ich probier das die Tage nochmal, und wenn nix geht, dann eben Snapshot wieder drauf. Den rest wiederherstellen aus Backups dauert auch nciht länger als Fehlersuche
Sorry, aber jetzt funktioniert gar nix mehr.
Keine resolv.conf mehr, kein ufw aktivierbar.
Danke erstmal allen für die vielen Antworten. Heute kann ich mich nicht mehr weiter damit beschäftigen.
Vll ist es auch sinnvoller einen Snapshot zurückzuspielen.
Und dann kann man auch fixe Werte in der resolv.conf haben.
Generell sollte man bei Servern im Netz immer statische Werte nutzen. Das kann ziemlich aergerlich sein, wenn mal irgendein Automatismus nicht funktioniert und Du eine falsche IP bekommst oder keine, weil der DHCP weg ist..
Jetzt bin ich überfordert. Meinst du mit dem DHCP 127.0.0.53?
Deaktiviert systemd-resolved und nimmt nur die Einträge in der resolv.conf. Richtig verstanden?
In der /run/systemd/resolve/stub-resolv.conf sind die Nameserver geändert.
dig google.de nimmer auch den 1.1.1.1
ufw kann aber nciht mehr aktiviert werden, gleiche Fehlermeldung wie vorher
Hab nochmal einen reboot gemacht =>
/run/systemd/resolve/stub-resolv.conf
alle Einträge wieder automatisch geändert und 1.1.1.1 und 8.8.8.8 weg...
Und nach dem nächsten Reboot, wieder alles futsch
Also ich schwöre bei nameserver 8.8.8.8 , wie ich es schon mal getestet habe ging nix.
Gerade in eingetragen:
ufw läst sich aktivieren alles fein.
Erneute Pürfung von /etc/resolv.conf:
nameserver 127.0.0.53
options edns0 trust-ad
Das widerspricht sich aber doch ein wenig.
nein, weil ich exakt den Ausgangszustand wiederhergestellt habe.
50-cloud-init.yaml:
network:
version: 2
renderer: networkd
ethernets:
eth0:
addresses:
- 202.61.254.xy/22
- 2a03:4000:55:d7d:6805:ecff:fe41:xxxx/64
gateway4: 202.61.252.1
gateway6: fe80::1
match:
macaddress: 6a:05:ec:41:a0:xy