Nameserver Deutsche Telekom AG

S

silithium

Member
Hallo liebe OpenBSD-Freunde,

habe diverse OpenBSD-Server (4.7) aufgesetzt, die als Internet-Gateway, Firewall und OpenVPN dienen. Bisher nie Probleme gehabt, aber nun das folgende...

Die Einwahl geschieht via PPPoE bei der DTAG.
Nun gibt es Problem, dass anscheinend nach der 24h-DSL-Zwangstrennung die DNS-Server nicht korrekt an die Clients weitergegeben werden.

Der DSL-Re-connect funktioniert, komme aus der Ferne per SSH / OpenVPN auf den Gateway, aber die Clients, die den Gateway als Internetzugangspunkt nutzen, kommen nicht raus, wie gesagt, vermute ich ein DNS-Problem.

Als Caching Nameserver ist "named" installiert.

Jemand eine Idee, woran das liegen kann? Bei anderen Providern (Versatel, Vodfaone, etc..) gibts keine Probleme.

Besten Dank!
Silithium
 
Ja, die Clients haben als DNS-Server die IP des OpenBSD-Gateways eingetragen.
Für die bleibt alles gleich.

Aber an jedem Tag muss der OpenBSD neu gestartet werden, weil die Clients nicht ins Netz kommen, aber ich wiederum komme per SSH auf den OpenBSD, daher steht ja die DSL-PPPoE-Verbindung und ich vermute, dass kein gültiger DNS-Server von OpenBSD an die Clients weitergereicht wird.

Named läuft als Caching Nameserver.
 
Wie hast du den named denn konfiguriert? Vermute eher, dass da was nicht stimmt. Ansonsten probier mal tcpdump während ein Client nen Namen auflösen will. Oder starte named mit höherer Verbosity.
 
Hey, erstmal vielen Dank für Deine Hilfe.

Also bisher habe ich named nur einmal gestartet und dann per /etc/rc.conf dazu gebracht, beim Systemstart stets automatisch zu starten.

Muss ich vielleicht bei den

forwarders { DNSADRESSE1, DNSADRESSE2 }


Die DNS-Server der DTAG eingeben?
Das habe ich bis dato nicht gemacht bzw. auch nicht gebraucht.

Schonmal vielen Dank für Deine Hilfe!

Viele Grüße,
Silithium
 
Du brauchst normalerweise gar keine Nameserver von einem Provider einzutragen. Ich hatte früher auch Forwarder definiert, wie Du es gerade vor hast. Aber die habe ich inzwischen nicht mehr. Mein interner DNS-Cache läuft fast mit der Standardkonfiguration.

Was ich vielmehr vermute ist, dass die Route nach der Wiedereinwahl nicht richtig gesetzt ist. Versuch mal von dem Einwahlrouter aus Sachen anzupingen nach einem Reconnect.
 
Hi nakal,

ich dank Dir ganz herzlich für die Info.

Habe dies gestern schonmal getestet.
Nachdem die Clients keine Website aufrufen konnten, habe ich am OpenBSD-System direkt versucht google.de und andere Domains anzupingen, das klappte wunderbar.

Ein Neustart von "named" brachte nix, erst nachdem ich das ganze System neu gestartet habe, kamen die Clients wieder ins "WWW".

Ich denke auch, dass nach der Wiedereinwahl irgendwas schief läuft, weiß nur nicht was.
Bei anderen Systemen hatte ich dieses Problem bisher nie.
 
silithium schrieb:
Hallo liebe OpenBSD-Freunde,
Die Einwahl geschieht via PPPoE bei der DTAG.
Nun gibt es Problem, dass anscheinend nach der 24h-DSL-Zwangstrennung die DNS-Server nicht korrekt an die Clients weitergegeben werden.
Zum Vergrößern anklicken....

Von den DTAG DNS Servern kann ich nur abraten. Diese verfälschen Anfragen und liefern eine mit Werbung verseuchte Startseite statt NXDOMAIN. Ich habe die Erfahrung gemacht das es bessere Antwortzeiten mit einem lokalen caching Resolver zu erreichen sind. Falls du willst kannst du noch einen großen relativ zu dir gut angebunden anderen Nameserver als forwarder eintragen. Ich war es einfach satt.

silithium schrieb:
Der DSL-Re-connect funktioniert, komme aus der Ferne per SSH / OpenVPN auf den Gateway, aber die Clients, die den Gateway als Internetzugangspunkt nutzen, kommen nicht raus, wie gesagt, vermute ich ein DNS-Problem.

Als Caching Nameserver ist "named" installiert.
Zum Vergrößern anklicken....
Hinter "named" verbirgt sich BIND.

Jemand eine Idee, woran das liegen kann? Bei anderen Providern (Versatel, Vodfaone, etc..) gibts keine Probleme.

Besten Dank!
Silithium
Zum Vergrößern anklicken....

Wenn du einen lokalen Nameserver fährst solltest du bestenfalls in der /etc/resolv.conf des Routers die Nameserver deines Providers haben. Sollten diese nicht funktionieren nutz deinen eigenen.
 
Hallo Crest, danke, habe mal tabula rasa gemacht und die DNS-Server aus der resolv.conf gelöscht.

Nach einem OpenBSD-Neustart werden in der resolv.conf automatisch zwei DNS-Server eingetragen, im ppp.conf Skript ist dns aktiviert (enable dns) also denke ich, von daher passt alles?

Nach dem Re-Connect der DTAG komme ich ja weiterhin per SSH / OpenVPN drauf, nur die internen Clients kommen nicht mehr raus. Kann es sein, dass das Interface "rl0" (für das interne Netz) down ist? Aber ich vermute eher, dass die DNS-Server vom OpenBSD nicht richtig an die Clients weitergereicht werden?
 
enable dns beachtet die DNS-Server Deines Providers. Wozu? Du hast doch einen voll funktionstüchtigen DNS-Cache lokal und der unterhält sich sowieso nur mit den Root-Servern, wenn Du keine Forwarder einträgst.

Außerdem ist tcpdump Dein Freund. Ohne zu sehen was mit dem Traffic passiert, kann man nicht genau sagen wohin die Pakete wollen.
 
Wie kommst du denn überhaupt auf die Idee, dass es ein DNS Problem sein soll? Hast du irgendetwas in dieser Richtung getestet? Falls ja: was?
Und welche DNS Server sollten an die Clients weitergereicht werden? Erklär doch bitte mal deine Theorie...
 
Also in deiner dhcpd.conf steht, was an den DHCP Clients mitgeteilt wird, wenn du dir da nicht etwas sehr seltsames gebaut hast ist das von dem Inhalt deiner /etc/resolv.conf unabhängig. Irgendwo in deiner dhcpd.conf sollte mindestens eine Zeile mit "option domain-name-servers 134.102.20.20;" der dhcpd.conf Manualpage solltest du entnehmen können wo diese Option gesetzt werden kann und für wen sie im Zweifelsfall gültig ist (Gruppen, Subnets, Hosts). Ich würde einen funktionierenden lokalen Cache vorrausgesetzt diesen in die /etc/resolv.conf schreiben d.h. "nameserver ::1". Das ist aber jedem selbst überlassen. SSH sollte sofern du die IP Addresse des Ziel kennst auch ohne DNS funktionieren. Nur dauert es "dank" UseDNS etwas bis SSH aufgibt.
 
Ohne Logs ist das alles hier nur ein Fischen im Trüben (man tcdump).

tcpdump -netttr /var/log/pflog
tcpdump -nettti internesInterface

Interessant ist die Zeit, bei der der Router zwangsgetrennt wird, wenn es daran liegen sollte.
 
Oh man oh man,

beim Aufruf des /etc/ppp/ppp.linkup Skriptes fehlte in der Zeile für die Firewall /etc/pf.conf am Ende ein " (Anführungszeichen).

Das war der Fehler, sorry! Manchmal sind es einfach nur Kleinigkeiten.

Sagrotan hat mich nochmal nachdenklich gestimmt, so dass ich alle Skripte kontrolliert habe und dabei ist mir der Fehler aufgefallen.

Ich danke euch ganz herzlich für eure Hilfe und eure Ideen.

Viele Grüße,
silithium
 
Crest schrieb:
Von den DTAG DNS Servern kann ich nur abraten. Diese verfälschen Anfragen und liefern eine mit Werbung verseuchte Startseite statt NXDOMAIN. Ich habe die Erfahrung gemacht das es bessere Antwortzeiten mit einem lokalen caching Resolver zu erreichen sind. Falls du willst kannst du noch einen großen relativ zu dir gut angebunden anderen Nameserver als forwarder eintragen. Ich war es einfach satt.
Zum Vergrößern anklicken....

Du kannst dich bei T-Online einloggen und dort konfigurieren wie der Nameserver sich verhalten soll. Die haben das ganz einfach gelöst, wenn du keine Suchseite als Antwort haben willst, kriegst du bei der nächsten Einwahl einfach einen DNS Server zugewiesen der gescheit antwortet ;)
 
oenone schrieb:
Das ist eine Realtek... Mit denen kann man lustige Fehler erleben, für die es keine Erklärung gibt. Probier mal aus, ob es mit einer anderen Netzwerkkarte auch passiert.
Zum Vergrößern anklicken....

Auch sowas wie „rl0 watchdog timeout“ beim booten?

Das plackt mich gerade mit einem RTL8xxxx-schieß mich tot-Chip bei 4.8.

Die fest vergebene IP kann man lokal anpingen - aber raus und rein geht nichts...

:confused:
 
silithium schrieb:
Oh man oh man,

beim Aufruf des /etc/ppp/ppp.linkup Skriptes fehlte in der Zeile für die Firewall /etc/pf.conf am Ende ein " (Anführungszeichen).

Das war der Fehler, sorry! Manchmal sind es einfach nur Kleinigkeiten.

Sagrotan hat mich nochmal nachdenklich gestimmt, so dass ich alle Skripte kontrolliert habe und dabei ist mir der Fehler aufgefallen.

Ich danke euch ganz herzlich für eure Hilfe und eure Ideen.

Viele Grüße,
silithium
Zum Vergrößern anklicken....
warum startest du pf neu, wenn dein ppp hochfährt? das brauchst du eigentlich nicht, zumindest habe ich das weder aktuell am kabel im einsatz noch zu DSL zeiten gehabt.

benutzt du eigentlich den kernel-pppoe? laut den entwicklern ist der um längen besser, als der aus dem userland. der aus dem userland funktionierte bei mir nie wirklich, wohingegen ich mit dem kernel-pppoe auf anhieb gar keine probleme hatte (nachdem ich die richtige MTU fest zugewiesen hatte, da die jedes mal einen falschen wert hatte).
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben