Du bist nicht angemeldet.

Eine Antwort schreiben

Schreibe deinen Beitrag und versende ihn
Beitragsoptionen
Deine Antwort

Zurück

Themen-Übersicht (Neuester Beitrag zuerst)

chepaz
01.11.2019 18:28:16

tl;dr: Dein DNS ist kaputt.

Irgendwo in der Nähe von

Hinter der 10.0.0.20 verbirgt sich mein dd-wrt-Router, der wiederrum mit einer UnityMedia-Combibox verbunden ist.

BigMan200
01.11.2019 17:35:42
wirr schrieb:

Konntest du deine Vermutung nicht verifizieren? Hier nochmals die Schritte, die chepaz empfiehlt:

$ drill archlinux.org
$ drill -x 138.201.81.199
$ drill archlinux.org @8.8.8.8
$ drill -x 138.201.81.199 @8.8.8.8

Wenn die zweiten zwei Befehl funktioniert, aber die ersten beiden nicht, dann hat der Nameserver unter 10.0.0.20 ein Problem und du musst entweder diesen debuggen oder die Empfehlung von k.osmo berücksichtigen.

Also, zunächst mal getestet, ob mein Problem noch da ist, und versucht folgende Websites aufzurufen:
https://www.archlinux.org/news/ca-certificates-update/
http://www.cpan.org/
https://bbs.archlinux.org/viewtopic.php?id=237522

Bei allen dreien steht im Firefox-Browser: "Seite wurde nicht gefunden".

Dann obige "drill" Befehle ausgeführt.

 $ drill archlinux.org
;; ->>HEADER<<- opcode: QUERY, rcode: SERVFAIL, id: 47728
;; flags: qr rd ra ; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 
;; QUESTION SECTION:
;; archlinux.org.	IN	A

;; ANSWER SECTION:

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 1097 msec
;; SERVER: 127.0.0.53
;; WHEN: Fri Nov  1 16:32:11 2019
;; MSG SIZE  rcvd: 31
$ drill -x 138.201.81.199
;; ->>HEADER<<- opcode: QUERY, rcode: NXDOMAIN, id: 26350
;; flags: qr rd ra ; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 
;; QUESTION SECTION:
;; 199.81.201.138.in-addr.arpa.	IN	PTR

;; ANSWER SECTION:

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 997 msec
;; SERVER: 127.0.0.53
;; WHEN: Fri Nov  1 16:32:42 2019
;; MSG SIZE  rcvd: 45
$ drill archlinux.org @8.8.8.8
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 64951
;; flags: qr rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 
;; QUESTION SECTION:
;; archlinux.org.	IN	A

;; ANSWER SECTION:
archlinux.org.	1348	IN	A	138.201.81.199

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 19 msec
;; SERVER: 8.8.8.8
;; WHEN: Fri Nov  1 16:34:43 2019
;; MSG SIZE  rcvd: 47
$ drill -x 138.201.81.199 @8.8.8.8
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 32045
;; flags: qr rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 
;; QUESTION SECTION:
;; 199.81.201.138.in-addr.arpa.	IN	PTR

;; ANSWER SECTION:
199.81.201.138.in-addr.arpa.	16932	IN	PTR	apollo.archlinux.org.

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 18 msec
;; SERVER: 8.8.8.8
;; WHEN: Fri Nov  1 16:33:29 2019
;; MSG SIZE  rcvd: 79
wirr
01.11.2019 17:13:26

Konntest du deine Vermutung nicht verifizieren? Hier nochmals die Schritte, die chepaz empfiehlt:

$ drill archlinux.org
$ drill -x 138.201.81.199
$ drill archlinux.org @8.8.8.8
$ drill -x 138.201.81.199 @8.8.8.8

Wenn die zweiten zwei Befehl funktioniert, aber die ersten beiden nicht, dann hat der Nameserver unter 10.0.0.20 ein Problem und du musst entweder diesen debuggen oder die Empfehlung von k.osmo berücksichtigen.

BigMan200
01.11.2019 16:48:57
stefanhusmann schrieb:

Im Eingangspost wird trizen erwähnt, ja, aber aus dem Rest des Threads geht hervor, dass es sich um ein ganz anderes Problem gehandelt hat.

Und wenn es sich bei dir durch Anpassung der Systemzeit erledigt hat (schön), ist es nochmal ein anderes Problem, und hat wieder nichts mit trizen zu tun.

Der Schwerpunkt liegt NICHT auf Trizen!

Oben ist ja auch geschildert, dass bestimmte Websites sich über einen Browser nicht öffnen lassen. Es gibt lediglich die VERMUTUNG, dass der Trizen Error und das Website-Problem die selbe Ursache haben (da beide etwas mit URL Zugriff zu tun haben - anscheinend zumindest.)

stefanhusmann
30.10.2019 13:36:06

Im Eingangspost wird trizen erwähnt, ja, aber aus dem Rest des Threads geht hervor, dass es sich um ein ganz anderes Problem gehandelt hat.

Und wenn es sich bei dir durch Anpassung der Systemzeit erledigt hat (schön), ist es nochmal ein anderes Problem, und hat wieder nichts mit trizen zu tun.

Olli
30.10.2019 01:33:52

Aber genau dieses Problem mit trizen spricht BigMan200 in seinem Eingangspost doch an.

Bei mir hat sich das Problem übrigens erledigt, vielleicht hilft dir das ja auch weiter:
Systemzeit und Datum hat nicht gestimmt. Ist mir auch erst aufgefallen, als ich Firefox auf diesem Laptop zum ersten Fall benutzt hab.
Nachdem ich Datum und Zeit korrigiert hab, läuft alles ohne Probleme.

stefanhusmann
26.10.2019 12:17:56

Olli, mach bitte einen eigenen Thead auf. Der OP hat ein Problem mit DNS, nicht mit trizen.

Olli
26.10.2019 03:15:05

Ich hab bei mir das gleiche Problem mit trizen.
Auf meinem eigenen Rechner, den ich vor 2 Jahren installiert hab, funktioniert alles ohne Probleme.
Auf dem Laptop eines Kollegen, den ich gestern neu installiert habe, kann ich keine Programme mit trizen installieren, da bekomm ich die gleichen Meldungen wie BigMan200.
Und bevor jetzt die Frage kommt, wieso man da mit trizen rumspielt ...qelectrotech gibt es leider nur im AUR

Am Router kann es eigentlich nicht liegen, beide Rechner hängen am selben.

k.osmo
20.10.2019 20:00:57

Vermutlich solltest Du deinen DD-WRT-Router gegen einen tauschen, der zuverlässig IPv6 kann, solange Du einen Vodafone/Unitymedia-Kabelanschluss nutzt.

Torsten (Freitag, 20.04.2018 um 21:36 Uhr) schrieb:

Wenn du einen IPv6-Anschluss hast, gibt es schlicht keine Portweiterleitung mehr, da musst du entsprechende IPv6-Freigaben im Router einrichten. UM kann nicht mehr jedem Kunden einen IPv4-Anschluss schalten, da schlicht keine IPv4-Adressen mehr erhältlich sind. Um aber jedem Kunden den Zugriff auf IPv4-Dienste und -Inhalte möglich zu machen, wurde die "Brückentechnologie" DS lite geschaltet. Nur sind damit (weil es keine öffentlich erreichbare IPv4-Adresse an deinem Anschluss gibt) keine Portweiterleitungen möglich, denn dein Anschluss ist komplett per IPv6 angebunden. Der IPv4-Verkehr wird per IPv6 über einen Tunnel an das AFTR geleitet und dort quasi wieder in IPv4 "übersetzt", genauso geht das zurück.

Und selbst wenn der Bridge-Mode für die ConnectBox kommt, kannst du trotzdem an einem IPv6-Anschluss auch am eigenen Router keine Ports weiterleiten. Und wenn dein Router dann kein DS lite kann, hast du nichtmal Zugriff auf alles, was IPv4 only spricht!

community.unitymedia.de/categories/hardware/question/petition-connect-box-bridge-bzw-reiner-modem-modus-ohne-routerfunktion?page=14

Torsten (Samstag, 28.04.2018 um 13:19 Uhr) schrieb:

DS lite wird rein über den Router gemanaged, wenn man also keine Ahnung davon hat, wie der Router zu konfigurieren ist, so ist das das Problem des Kunden. Das wäre übrigens beim Bridge Mode der Connect Box genauso, nur um direkt allen Wind aus den Segeln zu nehmen! Ein Kabelmodem stellt lediglich eine Verbindung zum CMTS her, nicht mehr und nicht weniger. Kann der Router dann kein DS lite, so gibt es halt keine IPv4-Verbindungen an diesem Anschluss.

community.unitymedia.de/categories/hardware/question/petition-connect-box-bridge-bzw-reiner-modem-modus-ohne-routerfunktion?page=15

Specimen (Thu Sep 01, 2016) schrieb:

Such support is not an hardware limitation, it's a software choice. DD-WRT devs have decided not to include any IPv6 (and any of the transitioning technologies such as Dual Stack) support in routers with just 4 MB of flash.

https://forum.dd-wrt.com/phpBB2/viewtop … 38#1045238

Nachtrag: Zwei Beiträge weiter wird OpenWRT empfohlen.

chepaz
20.10.2019 11:14:21
BigMan200 schrieb:

Zu dem Hinweis, dass es ein DNS-Problem sein könnte. Wie kann ich das prüfen?

ping, nslookup, dig... jedes Tool das dir in irgend einer Form den Namen auflöst kannst du nehmen. Am besten in beide Richtungen prüfen, also Name-->IP und IP-->Name. DNS-Server mal umsetzen auf einen öffentlichen oder z.B. dig mitgeben.
Ich halte das auch für ein DNS Problem bei dir.

BigMan200
20.10.2019 09:20:07

Heute liefert:

 $ nmap -P0 -p443 aur.archlinux.org
Starting Nmap 7.80 ( https://nmap.org ) at 2019-10-20 09:04 CEST
Nmap scan report for aur.archlinux.org (5.9.250.164)
Host is up (0.23s latency).
rDNS record for 5.9.250.164: luna.archlinux.org

PORT    STATE SERVICE
443/tcp open  https

Nmap done: 1 IP address (1 host up) scanned in 0.31 seconds

Aber dennoch kann ich nicht obige Beispielwebsites öffnen (Firefox-Meldung: "Server nicht gefunden.")

Zu dem Hinweis, dass es ein DNS-Problem sein könnte. Wie kann ich das prüfen?
Hier mal Einträge von denen ich denke, diese könnten relevant sein:

$cat /etc/resolv.conf
nameserver 10.0.0.20
options edns0
 $cat /etc/systemd/resolved.conf
[Resolve]
DNS=10.0.0.20

Hinter der 10.0.0.20 verbirgt sich mein dd-wrt-Router, der wiederrum mit einer UnityMedia-Combibox verbunden ist.

BigMan200
19.10.2019 18:05:04
stefanhusmann schrieb:

Das Problem scheint ja mit dem https-Zugriff zu tun zu habe und nicht mit trizen. Auch im Browser geht ja nicht alles. Hast du irgendeine Firewall am Start?

nmap -P0 -p443 aur.archlinux.org

Okay, heute ist mal wieder so ein Tag wo es nicht funktionert:

$ nmap -P0 -p443 aur.archlinux.org
Starting Nmap 7.80 ( https://nmap.org ) at 2019-10-19 17:59 CEST
Failed to resolve "aur.archlinux.org".
WARNING: No targets were specified, so 0 hosts scanned.
Nmap done: 0 IP addresses (0 hosts up) scanned in 1.24 seconds

Bzgl. Firewall: da musste ich mal an meinen dd-wrt-Routern schauen. An einem ist SPI eingeschaltet. Aber auch nachdem ich dieses auf deaktiv gesetzt hatte, hat es nicht geklappt.

stefanhusmann
13.10.2019 02:10:55

Das Problem scheint ja mit dem https-Zugriff zu tun zu habe und nicht mit trizen. Auch im Browser geht ja nicht alles. Hast du irgendeine Firewall am Start?

nmap -P0 -p443 aur.archlinux.org

hcjl
12.10.2019 21:03:24

Poste dich bitte auch mal Deine pacman.conf. Und was fummelst Du die ganze Zeit mit trizen rum. Verwende zunächst pacman.

BigMan200
12.10.2019 16:43:07
ahB3Yei8 schrieb:

Welchen Mirror benutzt du denn? Nicht dass du dich an einen verbindest der zur Zeit hängt https://www.archlinux.org/mirrors/status/#outofsync
Und von wann sind die Zertifikate? Aktuell ist https://www.archlinux.de/packages/core/ … rtificates

Den Link https://www.archlinux.org/mirrors/status/#outofsync kann ich nicht öffnen --> ein weiterer Link also, der bei mir nicht geht.
Bezüglich der Zertifikate:

$ trizen -Ss ca-certificates
:: Unable to GET https://aur.archlinux.org/rpc.php?v=5&type=search&arg=ca-certificates ==> 500 Can't connect to aur.archlinux.org:443 (Der Name oder der Dienst ist nicht bekannt)
core/ca-certificates 20181109-1 [Installiert]
    Common CA certificates (default providers)
core/ca-certificates-mozilla 3.46.1-1 [Installiert]
    Mozilla's set of trusted CA certificates
core/ca-certificates-utils 20181109-1 [Installiert]
    Common CA certificates (utilities)

--> Basierend auf dem Link https://www.archlinux.de/packages/core/ … rtificates sieht das aber aktuell aus.

Fußzeile des Forums

Powered by FluxBB