Jump to content

Mal wieder eine Computer-Frage ...

ramhol

Von ramhol
in Es muss nicht immer Kirche sein

 Share

Recommended Posts

Chrysologus

Chrysologus

Geschrieben
Geschrieben

Auch hier eher kryptische Ergebnisse - zumindest für mich.

 

traceroute6 (traceroute hat er nicht - und installation via apt-get scheitert am bekannten Problem) bringt:

 traceroute: unknown host mykath.de

mtr zeigt nichts, d.h. die Anfrage scheitn nicht mal bis zum Router zu gehen, wenn ich das richtig deute. Eine änderung der DNS Server auf dem Router bringt nichts,

Ein nslookup mykath,.de liefert folgendes mich erstaunende Ergebnis:

Server:         127.0.1.1
Address:        127.0.1.1#53

Non-authoritative answer:
Name:   mykath.de
Address: 148.251.176.214

ping mykath.de hingegen liefer host unreachable.

 

Link zu diesem Kommentar
Auf anderen Seiten teilen
Baumfaeller

Baumfaeller

Geschrieben
Geschrieben (bearbeitet)

Deine DNS ist up-ge-screwed (ein halb-Deutsches Wort).

 

Kommt der Server ueberhaupt ans grosse weite Netz raus? Einfach ausprobieren:

> ping www.mykath.de

Hast Du oben schon probiert. Ging nicht. Das koennte DNS sein, oder Netz-Problem.

 

Was passiert bei

> ping 148.251.176.214

 

Oder

> cd /tmp

> wget http://74.125.239.47/index.html

Das ist die home page von www.google.de. Wenn das klappt, solltest Du eine Datei namens index.html finden, ein paar zig-KB lang.

 

> ssh harrypotter@208.201.242.19

Das sollte Dich nach dem Password fragen, du kannst jeden beliebigen Muell eingeben, und kommst nicht durch (nach dem ersten Mal mit Control-C abbrechen). Dies ist eine oeffentlich zugaengliche Maschine bei meinem ISP, auf der kein Account names harrypotter existiert, wir versuchen also nur festzustellen, ob wir an die Maschine ohne DNS drankommen.

 

Wenn dies alles nicht funktioniert (z.B. "Network unreachable" oder sowas), dann weiss Dein Server nicht, wie er an das Netz drankommt. Wahrscheinlich fehlt in seiner routing table der Eintrag fuer die default route (wie man an Rechner drankommt, die man nicht kennt). Auf meinem BSD server wuerde ich dann sagen "route add default gateway X.X.X.X", wobei X.X.X.X die IP Adresse meines Routers ist (in meinem Fall, die Adresse der kleinen DSL-Kiste, die mir die Telefon-Gesellschaft geschickt hat, in meinem Fall das extrem langweilige 192.168.1.1).

 

Wenn dies alles funktioniert, aber Du per DNS nicht dran kommst (also funktioniert "wget http://www.google.de/index.html"nicht, oder "ssh harrypotter@bolt.sonic.net" nicht), dann ist Dein Problem DNS.

 

Und das scheint oben das Problem zu sein. nslookup (welches obsolet ist!) scheint ja einigermassen zu funktionieren, aber es verwendet merkwuerdigerweise den DNS Server auf 127.0.0.1. Das sieht so aus, als wenn Dein Server sein eigener DNS Server ist. Wenn das stimmt, dann muesste in /etc/resolv.conf die Zeile "nameserver 127.0.0.1" stehen. Die Frage ist dann: warum funktioniert dein eigener DNS server manchmal? Wie ist er konfiguriert? Wenn es ein normaler Bind-Server ist, dann koenntest Du einfach "rndc reload" probieren (von der Command-line als root), damit wird der Bind-Server neu initialisiert.

 

Die andere Methode, etwas brutal: Einfach mal nicht Deinen eigenen DNS Server verwenden: Editier /etc/resolv.conf, dass es "nameserver 8.8.8.8" enthaelt (und kommentier die andere nameserver Zeile einfach mal aus). Aendert das irgendwas?

 

Good luck. You'll need it.

bearbeitet von Baumfaeller
Link zu diesem Kommentar
Auf anderen Seiten teilen
Elrond

Elrond

Geschrieben
Geschrieben

Traceroute6 ist ungeeignet, weil es IPv6 sprechen will. Das Forum hat aber keine IPv6 Adresse, so dass "unkown host" richtig ist. Es gibt halt keinen AAAA Record. Ein traceroute6 auf Google sollte ein anderes Ergebnis bringen.

 

Ansonsten hat Baumfaeller schon alles gesagt. Wie sieht Deine resolv.conf aus?

Link zu diesem Kommentar
Auf anderen Seiten teilen
Chrysologus

Chrysologus

Geschrieben
Geschrieben

Die resolv.conf:

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 127.0.1.1
search lan

 

Link zu diesem Kommentar
Auf anderen Seiten teilen
Chrysologus

Chrysologus

Geschrieben
Geschrieben

ping geht nicht über meinen Router hinaus.

 

 

 


Oder

> cd /tmp

> wget http://74.125.239.47/index.html

Das ist die home page von www.google.de. Wenn das klappt, solltest Du eine Datei namens index.html finden, ein paar zig-KB lang.

 

Klappt nicht.

 

Immerhin führt die Veränderung der resolv.conf zu einem veränderten Verhalten: bei meiner alten resolv.conf kann er die IP-Adresse auflösen, das ping geht aber nicht durch. Wenn ich den DNS von google händisch eintrage, dann kann er nicht einmal die IP finden.

Link zu diesem Kommentar
Auf anderen Seiten teilen
Elrond

Elrond

Geschrieben
Geschrieben

Kannst Du die "geht nicht"s in diesem Posting mal mit konkreten Fehlermeldungen unterfuettern? Was sagt ping genau, was sagt der Resolver?

 

Was ist das fuer ein System? Ein NAS, eine selbst installierte Linux Buechse? Was sagt iptables -nL als Ausgabe?

Link zu diesem Kommentar
Auf anderen Seiten teilen
Baumfaeller

Baumfaeller

Geschrieben
Geschrieben

Zwei Dinge.

 

Erstens, Dein resolv.conf enthaelt ein paar Dinge die merkwuerdig oder ungewoehnlich sind: 127.0.1.1 und search lan.

 

Die erste Zeile sagt: Du hast einen DNS Server laufen, der unter der Addresse 127.0.1.1 erreichbar ist. Diese Addresses ist ungewoehnlich, sie ist normalerweise "localhost", also nichts weiter als der eigene Host. Aber dafuer wird normalerweise 127.0.0.1 verwendet, nicht 127.0.1.1. Habe ich gerade mit FreeBSD und RedHat nachgesehen. Nun ja, vielleicht ist Ubuntu seltsam, und verwendet eine andere Addresse fuer localhost.

 

Probier mal auf Deinem Rechner: "ping 127.0.1.1". Das muss funktionieren, sonst ist irgendwas ganz im Argen.

 

Zweitens: Funktioniert Dein DNS Server auf dem localhost? Das ist etwas schwierig auszuprobieren. Es ist wahrscheinlich ein "caching nameserver", der einfach DNS Information von draussen bezieht, sie dann lokal kurzfristig speichert, und weitergibt. Hast Du auf dem Server irgendwelche DNS Namen konfiguriert? Zum Beispiel "internal.chryso.com", oder so was? Wenn ja, dann probier mal: "dig @127.0.0.1 internal.chryso.com". Du solltest eine Antwort kriegen, die mehr oder minder so aussieht (natuerlich mit anderen Zahlen):

dig @127.0.0.1 house.treelogger.example.com

 

; <<>> DiG 9.8.1-P1 <<>> @127.0.0.1 house.treelogger.example.com

; (1 server found)

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51838

;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0

 

;; QUESTION SECTION:

;house.treelogger.example.com. IN A

 

;; ANSWER SECTION:

house.treelogger.example.com. 21600 IN A 192.168.0.1

 

;; AUTHORITY SECTION:

lr.treelogger.example.com. 21600 IN NS house.treelogger.example.com.

 

;; Query time: 2 msec

;; SERVER: 127.0.0.1#53(127.0.0.1)

;; WHEN: Mon Nov 10 21:41:47 2014

;; MSG SIZE rcvd: 72

Das gleich geht auch mit "host internal.chryso.com 127.0.1.1", oder "nslookup", enter, "server 127.0.1.1", enter, "internal.chryso.com".

 

Andererseits: Wenn Du keine internen Name konfiguriert hast, dann kannst Du Deinen Nameserver nur fragen, ob er externe Namen kennt, z.B. mit "dig @127.0.1.1 www.mykath.de", und wir wissen wie das ausgeht: Es ist genau wie "ping www.mykath.de", und das sagt wahrscheinlich "unknown host".

 

Das zweite was unueblich ist: "search lan". Das bedeutet, dass wenn Du einen nackten Hostname verwendest (z.B. "ping internal"), DNS automatisch auch unter "internal.lan" sucht. Warum? Wenn jemand "internal.lan" erreichen will, kann er den Namen ja auch eintippen. Und weil ".lan" keine normale Domain ist, wird das ganze sowieso nur intern funktionieren. Aber: Wenn Dein Nameserver dafuer konfiguriert ist, auf ".lan" irgendeinen Namen zu haben (z.B. "internal.lan"), dann waere das perfekt, um den Server auszuprobieren.

 

Immerhin führt die Veränderung der resolv.conf zu einem veränderten Verhalten: bei meiner alten resolv.conf kann er die IP-Adresse auflösen, das ping geht aber nicht durch. Wenn ich den DNS von google händisch eintrage, dann kann er nicht einmal die IP finden.

Und das macht gar keinen Sinn. Warum funktioniert Dein DNS, aber nicht ping? Entweder verstehe ich nicht, was "geht nicht durch" und "finden" bedeutet, oder Du hast eine sehr merkwuerde Firewall in Deinen Server eingebaut.

 

Poste mal die genauen Fehlermeldungen.

Link zu diesem Kommentar
Auf anderen Seiten teilen
Baumfaeller

Baumfaeller

Geschrieben
Geschrieben (bearbeitet)

Was ist das fuer ein System? Ein NAS, eine selbst installierte Linux Buechse?

Chryso sagte im Chat, es sei eine Ubuntu Maschine. Weiss aber die Version nicht mehr.

 

Was sagt iptables -nL als Ausgabe?

Das ist eine sehr gute Frage. Verwendet Ubuntu iptables oder ipfw? Ich nehme an, wir werden es bald wissen. bearbeitet von Baumfaeller
Link zu diesem Kommentar
Auf anderen Seiten teilen
Chrysologus

Chrysologus

Geschrieben
Geschrieben

Es ist ein mehr oder minder StandardRechner, auf dem ein Ubuntu 14.04 Trusty Tahr läuft.

 

Die Meldungen:

ping google.de
PING google.de (173.194.44.88) 56(84) bytes of data.
From SVR-LAPPEN (192.168.1.240) icmp_seq=1 Destination Host Unreachable
From SVR-LAPPEN (192.168.1.240) icmp_seq=2 Destination Host Unreachable
From SVR-LAPPEN (192.168.1.240) icmp_seq=3 Destination Host Unreachable
6 packets transmitted, 0 received, +3 errors, 100% packet loss, time 5031ms
pipe 3

Wenn ich in der relov.conf wie von baumfaeller vorgeschlagen als DNS 8.8.8.8 eintrage, passiert das:

~# ping google.de
ping: unknown host google.de

iptables hat er, ipfw kenn er nicht. Das Ergebnis:

root@SVR-LAPPEN:~# iptables -nL
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

ping 127.0.1.1 liefert das. was man erwarten sollte, er antwortet.

 

Ich habe in der Tat einige DNS Namen konfiguriert, und zwar die Namen der Rechner im Heimnetzwerk. So passiert folgendes:

root@SVR-LAPPEN:~# nslookup abaelard
Server:         127.0.1.1
Address:        127.0.1.1#53

Name:   abaelard.lan
Address: 192.168.1.101

Ich kann abaelard auch anpingen, aber wenn ich dig @192.0.0.1 abaelard eingebe, dann geschieht nichts.



Link zu diesem Kommentar
Auf anderen Seiten teilen
Chrysologus

Chrysologus

Geschrieben
Geschrieben

Gerne.

root@SVR-LAPPEN:~# ifconfig
br0       Link encap:Ethernet  Hardware Adresse 66:06:79:5f:40:74  
          inet Adresse:192.168.1.240  Bcast:192.168.1.255  Maske:255.255.255.0
          inet6-Adresse: fe80::6406:79ff:fe5f:4074/64 Gültigkeitsbereich:Verbindung
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metrik:1
          RX-Pakete:12668772030 Fehler:0 Verloren:10522 Überläufe:0 Fenster:0
          TX-Pakete:6491333073 Fehler:0 Verloren:0 Überläufe:0 Träger:0
          Kollisionen:0 Sendewarteschlangenlänge:0
          RX-Bytes:19190103988772 (19.1 TB)  TX-Bytes:437793645775 (437.7 GB)

eth0      Link encap:Ethernet  Hardware Adresse f4:6d:04:94:51:74  
          inet Adresse:192.168.1.240  Bcast:192.168.1.255  Maske:255.255.255.0
          inet6-Adresse: fe80::f66d:4ff:fe94:5174/64 Gültigkeitsbereich:Verbindung
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metrik:1
          RX-Pakete:12864140343 Fehler:0 Verloren:0 Überläufe:0 Fenster:0
          TX-Pakete:6491374889 Fehler:0 Verloren:0 Überläufe:0 Träger:0
          Kollisionen:0 Sendewarteschlangenlänge:1000
          RX-Bytes:19380374519640 (19.3 TB)  TX-Bytes:437798951679 (437.7 GB)

lo        Link encap:Lokale Schleife  
          inet Adresse:127.0.0.1  Maske:255.0.0.0
          inet6-Adresse: ::1/128 Gültigkeitsbereich:Maschine
          UP LOOPBACK RUNNING  MTU:65536  Metrik:1
          RX-Pakete:553733 Fehler:0 Verloren:0 Überläufe:0 Fenster:0
          TX-Pakete:553733 Fehler:0 Verloren:0 Überläufe:0 Träger:0
          Kollisionen:0 Sendewarteschlangenlänge:0
          RX-Bytes:118066573 (118.0 MB)  TX-Bytes:118066573 (118.0 MB)

tap0      Link encap:Ethernet  Hardware Adresse 76:a5:89:33:82:14  
          inet6-Adresse: fe80::74a5:89ff:fe33:8214/64 Gültigkeitsbereich:Verbindung
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metrik:1
          RX-Pakete:0 Fehler:0 Verloren:0 Überläufe:0 Fenster:0
          TX-Pakete:639961 Fehler:0 Verloren:0 Überläufe:0 Träger:0
          Kollisionen:0 Sendewarteschlangenlänge:100
          RX-Bytes:0 (0.0   TX-Bytes:140055973 (140.0 MB)

tap1      Link encap:Ethernet  Hardware Adresse 8a:ef:00:91:d8:06  
          UP BROADCAST PROMISC MULTICAST  MTU:1500  Metrik:1
          RX-Pakete:0 Fehler:0 Verloren:0 Überläufe:0 Fenster:0
          TX-Pakete:0 Fehler:0 Verloren:0 Überläufe:0 Träger:0
          Kollisionen:0 Sendewarteschlangenlänge:100
          RX-Bytes:0 (0.0   TX-Bytes:0 (0.0 

tap2      Link encap:Ethernet  Hardware Adresse 66:06:79:5f:40:74  
          UP BROADCAST PROMISC MULTICAST  MTU:1500  Metrik:1
          RX-Pakete:0 Fehler:0 Verloren:0 Überläufe:0 Fenster:0
          TX-Pakete:0 Fehler:0 Verloren:0 Überläufe:0 Träger:0
          Kollisionen:0 Sendewarteschlangenlänge:100
          RX-Bytes:0 (0.0   TX-Bytes:0 (0.0 
root@SVR-LAPPEN:~# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP group default qlen 1000
    link/ether f4:6d:04:94:51:74 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.240/24 brd 192.168.1.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::f66d:4ff:fe94:5174/64 scope link
       valid_lft forever preferred_lft forever
3: tap0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP group default qlen 100
    link/ether 76:a5:89:33:82:14 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::74a5:89ff:fe33:8214/64 scope link
       valid_lft forever preferred_lft forever
4: tap1: <NO-CARRIER,BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc pfifo_fast master br0 state DOWN group default qlen 100
    link/ether 8a:ef:00:91:d8:06 brd ff:ff:ff:ff:ff:ff
5: tap2: <NO-CARRIER,BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc pfifo_fast master br0 state DOWN group default qlen 100
    link/ether 66:06:79:5f:40:74 brd ff:ff:ff:ff:ff:ff
6: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether 66:06:79:5f:40:74 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.240/24 brd 192.168.1.255 scope global br0
       valid_lft forever preferred_lft forever
    inet6 fe80::6406:79ff:fe5f:4074/64 scope link
       valid_lft forever preferred_lft forever

root@SVR-LAPPEN:~# route -n
Kernel-IP-Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 eth0
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 br0
192.168.1.0     0.0.0.0         255.255.255.0   U     1      0        0 eth0
Link zu diesem Kommentar
Auf anderen Seiten teilen
Elrond

Elrond

Geschrieben
Geschrieben (bearbeitet)

WTF?

 

Was machen die drei Tap Devices, was sagt brctl show, was sagt arp -na, warum hast Du zwei Routen ins gleiche Netz, warum hat die Bridge und das eth0 die gleiche IP (das ist in 12 von 10 Faellen schlecht)

 

Auch spannend: laut ifconfig hoert Dein lo auf 127.0.0.1, wo kommt also 127.0.1.1 her?

bearbeitet von Elrond
Link zu diesem Kommentar
Auf anderen Seiten teilen
Chrysologus

Chrysologus

Geschrieben
Geschrieben

Ich hoffe, das WTF deutet an, dass wir dem Problem näher zu kommen scheinen. Ein Tap sollte ein Relikt eines Versuches sein, eine Verbindung zu meinem Büro aufzubauen, aber der liegt schon eine Weile zurück. Die übrigen Fragen vermag ich nicht zu beantworten.

root@SVR-LAPPEN:~# arp -na
? (192.168.1.120) auf 00:15:99:96:21:ff [ether] auf br0
? (192.168.1.104) auf c8:f7:33:5e:83:6e [ether] auf br0
? (192.168.1.1) auf 64:70:02:8e:ed:84 [ether] auf br0
? (192.168.1.1) auf <unvollständig> auf eth0
? (192.168.1.101) auf <unvollständig> auf br0
? (192.168.1.111) auf b8:ee:65:65:38:5b [ether] auf br0
? (192.168.1.105) auf 6c:ad:f8:20:8d:af [ether] auf br0
? (192.168.1.102) auf <unvollständig> auf br0
? (192.168.1.109) auf <unvollständig> auf br0
? (192.168.1.103) auf bc:ae:c5:3c:c9:ea [ether] auf br0
? (192.168.1.130) auf <unvollständig> auf br0
? (192.168.1.100) auf 00:23:54:dd:31:39 [ether] auf br0


root@SVR-LAPPEN:~# brctl show
bridge name     bridge id               STP enabled     interfaces
br0             8000.6606795f4074       no              eth0
                                                        tap0
                                                        tap1
                                                        tap2
Link zu diesem Kommentar
Auf anderen Seiten teilen
Chrysologus

Chrysologus

Geschrieben
Geschrieben

Wenn es was nützt - hier die /etc/network/interfaces

# interfaces(5) file used by ifup(8) and ifdown(8)
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet dhcp
#  address 192.168.1.240
#  netmask 255.255.255.0
#  gateway 192.168.1.1
  post-up /etc/init.d/apache2 restart

 

Link zu diesem Kommentar
Auf anderen Seiten teilen
Elrond

Elrond

Geschrieben
Geschrieben (bearbeitet)

Das ist ziemlich verkonfiguriert. Die Bridge hat die gleiche IP wie das eth0, das sogar Mitglied der Bridge selbst ist.

 

Wo hast Du die TAP Devices und die Bridge angelegt? Openvpn?

bearbeitet von Elrond
Link zu diesem Kommentar
Auf anderen Seiten teilen
Chrysologus

Chrysologus

Geschrieben
Geschrieben

Ich habe es gelöst - dank an alle für die Hilfe. Ich versuche mal eine Erklärung, der man ansehen wird, dasss ich nicht vom Fach bin: Der Fehler war nicht auf dem Server, sondern auf dem Router. Ich habe den etwas unorthodox konfiguriert, um den Datenverkehr meiner Damen zeitlich einschränken zu können. Mit dem Nebeneffekt, dass der Router zwar intern die Anfragen von und an eth0 weiterleitete, aber nicht nach außen ließ. Nun habe ich ihm gesagt, er solle auf br0 hören, und nun geht es. (Technischer gesprochen: di IP Adresse des Routers ist nicht mehr mit der MAC Adresse von eth0, sondern der von br0 verbunden.)

Link zu diesem Kommentar
Auf anderen Seiten teilen

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
 Share
Gehe zur Themenübersicht
×
×
  • Neu erstellen...