MPW schrieb:
in der Datei interfaces die dns-nameservers 127.0.0.1 für beide externen Schnittstellen aktiviert
in /etc/dhcp/dhclient.conf prepend domain-name-servers 8.8.8.8 eingefügt. (Was genau macht diese Zeile eigentlich?)
prepend = voranstellen übersetzt. Hier, denke ich, vor alle anderen DNS-Einträge pflanzen. Mangels Erfahrung in der Manipulation der DHCP-Client Konfigurations Datei, würde ich das mal so übersetzen.
OK, Du hast 4 Schnittstellen im Computer, von denen 2 eine feste IP zu den Netzwerken oder einen Bridge bilden und zwei weitere, die eine öffentliche IP besitzen und DHCP verstehen müssen. Mal ganz abgesehen davon, Du wirst nicht beide Leitungen gleichzeitig nutzen können, um damit die Geschwindigkeit, mit der Du Up- und Downloads machen kannst. So wie im realen Leben, kannst Du auch nur durch eine Tür ins Freie gehen und nicht durch zwei gleichzeitig. Genau so wenig wie ein Zug zwei Tunnel gleichzeitig befahren kann. Hängt damit zusammen, dass wenn Du etwas absendest der empfangende und zurück sendende Host, seine Pakete genau dahin zurück sendet, woher er die Anfrage erhalten hat. Und das kann nicht mal diese oder die andere Tür sein. Ist technisch unmöglich.
Das Problem lichtet sich nun weiter. Wenn Du am sprichwörtlichen Server sitzt als Dein Arbeitsplatz, wird Deine DNS-Abfrage unter normalen Umständen direkt ins Internet versandt, während die Clients im Netzwerk eine der beiden internen IP-Adressen benutzen, an die der DNS-Server gebunden ist.
Du kannst jetzt Abhilfe schaffen, indem Du eine kleine iptables Regel einbaust in der Du "sagst", alles was an DNS Abfragen von localhost kommt, also Deine Abfragen, sende zum internen DNS, also einer IP-Adresse auf deinem PC-Router-Arbeitsplatz.
mpw@Server0:~$ sudo cat /etc/resolvconf/resolv.conf.d/head
# 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.0.1
nameserver 134.102.20.20
nameserver 131.234.137.23
nameserver 8.8.8.8
nameserver 8.8.4.4
Hier muss ich ebenfalls passen, da ich das Programm/Bibliothek "resolvconf" noch nie benötigt habe und auch die Beschreibung, für meine Begriffe, etwas rätselhaft ausfällt. Ich müsste mir das Programm mal installieren, um zu sehen was das Ding tut.
und nach einem sudo /etc/init.d/networking restart sieht die /etc/resolv.conf nun so aus:
mpw@Server0:~$ sudo cat /etc/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.0.1
nameserver 134.102.20.20
nameserver 131.234.137.23
nameserver 8.8.8.8
nameserver 8.8.4.4
nameserver 127.0.0.1
search fh-muenster.de
Das hier macht mich jetzt etwas stutzig. Offenbar willst Du die DNS-Auflösung der Uni nutzen, um (vermutlich) im Intranet auf diverse Dienste zugreifen zu können. Zumindest Dienste die im öffentlichen Netzwerk nicht per DNS zu finden sind.
Zur Übersicht hier mal die ganze /etc/network/interfaces:
auto lo
iface lo inet loopback
auto eth2
iface eth2 inet dhcp
dns-nameservers 127.0.0.1
auto br0
iface br0 inet static
address 192.168.4.1
network 192.168.4.0
netmask 255.255.255.0
broadcast 192.168.0.255
bridge-ports eth1 wlan0
auto wlan1
iface wlan1 inet dhcp
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf
dns-nameservers 127.0.0.1
# vorhandene Regeln und Ketten zuerst löschen (Restart-Funktionalität)
up /sbin/iptables -F
up /sbin/iptables -X
up /sbin/iptables -t nat -F
# Maskieren der LAN-Schnittstelle, Port-Forwarding & Nat aktivieren
up iptables -A FORWARD -o eth2 -i br0 -s 192.168.0.0/24 -m conntrack --ctstate NEW -j ACCEPT
up iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
up iptables -t nat -A POSTROUTING -o eth2 -j MASQUERADE
up sysctl -w net.ipv4.ip_forward=1
# hostapd und dnsmasq neu starten
up /etc/init.d/hostapd restart
up /etc/init.d/dnsmasq restart
dnsmasq? Ja gut, kann man nutzen. Nur dann braucht es keinen Bind. Man sollte sich hier entscheiden für einen Dienst. Und die Namensserver Einträge benötigt eigentlich nur das Interface br0. Dahin per iptables eine Regel erstellen, die die Fragen an br0 sendet und dnsmasq weiß dann wohin er weiter fragen kann, wenn nichts dazu in seiner Datenbank steckt.
Es scheint jetzt stabil zu sein. Ich glaube das Problem vorher war einfach, dass sich die vom dhclient erfragten dns-server gegenseitig überschrieben haben. Das ist zumindest meine Theorie.
Die Vermutung liegt nahe. Oder es gab nur die Anfrage an localhost und der wusste nicht, wohin die DNS-Anfragen weiter geleitet werden können. Im Moment haste zu viele localhost Anfragen laufen. Denn die hast Du ja schon auf der Schnittstelle definiert.
Einen wirklichen Geschwindigkeitszuwachs konnte ich jetzt nicht bemerken, aber es ist wenigstens stabil.
Siehe oben, zwei Leitungen gleichzeitig nutzen geht nicht.
Ich hoffe ich habe jetzt soweit alles richtig gemacht. Sollten wir das in den Wiki-Eintrag von Multi-Uplink-Routing aufnehmen?
Im Moment wohl eher noch nicht. Denn dazu müsste man dann wissen, warum 3 Konfigurationsdateien notwendig sind.
Gibt der entsprechenden Schnittstelle die DNS-Adresse, an der Namen aufgelöst werden können (deswegen braucht es auch keine resolv.conf
Bis heute hatte ich noch keinen Grund in den Client-Konfigurations-Dateien herum zu schrauben. Zudem fehlt mir Input zu besagtem Programm resolvconf. Habe ich noch nie benutzt.
Das würde mich ja doch mal interessieren, ich fühle mich, als hätte ich alles jetzt 3 mal konfiguriert. Oder sind wirklich alle 3 Einstellungen nötig?
Also aus meiner Sicht hast Du es 3 mal konfiguriert. Und je nach Lage der Dinge, wird jedes Ding für sich gesehen, irgend wann mal ne Antwort geben. Oder alle drei gleichzeitig und es wird alles lahm ohne Ende ...
Grundsätzlich aber haste ne ziemlich kuriose Konfiguration. Warum Du eth0 per Brücke an wlan0 bindest erschliesst sich mir momentan nicht. Denn eigentlich können beide Schnittstellen unabhängig voneinander funktionieren.