Next Previous Contents

17. dod: Unerw{[uuml ]}nschte Hinauswahl mit dial-on-demand

17.1 dod{[lowbar]}how: Wie funktioniert dial-on-demand?

Nachdem Du ein Netzwerk-Interface eingerichtet und eine Route daf{[uuml ]}r definiert hast, werden alle IP-Pakete, f{[uuml ]}r die eine Route dorthin eingestellt wurde, zu diesem Interface geleitet. Wenn autodial aktiviert wurde (siehe Frage dialout_dialmode zu den Dialmodes), wird das Interface beim Vorliegen von abzusendenden IP-Paketen automatisch eine Hinauswahl durchf{[uuml ]}hren. Das bedeutet, da{[szlig ]} jeder Benutzer eine Hinauswahl verursachen kann.

Beispiel: Du {[ouml ]}ffnest einen Browser mit leerer Startseite oder mit einer lokalen Homepage. Es passiert nichts. Wenn Du nun einen URL eingibst, werden dadurch IP-Pakete zum Netzwerk-Interface gesendet und es wird eine Hinauswahl ausgel{[ouml ]}st.

Der Gebrauch von dial-on-demand ist ein gef{[auml ]}hrliches (= kostspieliges) Feature: siehe Frage dod_disaster.

17.2 dod{[lowbar]}disaster: Was ist ein Geb{[uuml ]}hren-GAU?

Der Geb{[uuml ]}hren-GAU kann aus verschiedenen Gr{[uuml ]}nden eintreten (Details unter dod_causes). Das Resultat ist jedoch gleich: Dein Computer w{[auml ]}hlt Deinen ISP {[ouml ]}fter an als Dir lieb ist und erh{[ouml ]}ht dadurch Deine Telefonrechnung um einen gro{[szlig ]}en Betrag (besonders dann, wenn Du nicht nur die Online-Zeit sondern auch einen Mindestbetrag/Einheitsbetrag f{[uuml ]}r jede Einwahl bezahlen musst). Der Ausdruck 'gro{[szlig ]}er Betrag' ist recht dehnbar. Alles ist m{[ouml ]}glich:

Dies ist kein Scherz, all diese Dinge sind tats{[auml ]}chlich passiert, sogar bei richtigen ISDN4LINUX-Experten! Schau bei Frage dod_off nach, wie Du jedes Risiko, da{[szlig ]} dies Dir passiert, vermeiden kannst.

17.3 dod{[lowbar]}causes: Wodurch wird ein Geb{[uuml ]}hren-GAU ausgel{[ouml ]}st?

Da gibt es viele M{[ouml ]}glichkeiten. Bei Frage dod_strategy erf{[auml ]}hrst Du, wie Du herausfindest was gerade passiert. Bei der Frage dod_disaster erf{[auml ]}hrst Du dann, wie teuer das sein kann. Es folgt eine nicht vollst{[auml ]}ndige Liste von Ursachen:

  1. Du hast Deinen Kernel irrt{[uuml ]}mlich mit der Option Bridging kompiliert.
  2. ARP Anfragen oder Broadcasts? Du solltest ifconfig mit den Optionen -arp und -broadcast aufrufen und dadurch das Herstellen von Verbindungen aus diesen Gr{[uuml ]}nden vermeiden. Du erkennst diese Ursache daran, da{[szlig ]} Du einen W{[auml ]}hlvorgang hast aber keine Daten {[uuml ]}bertragen werden.
  3. Andere Broadcasts von den Interfaces werden von ISDN weitergeleitet.
  4. Wenn IP-Verbindungen noch ge{[ouml ]}ffnet sind w{[auml ]}hrend die Leitung geschlossen wird und die IP-Addressen dynamisch vergeben werden, ist die Katastrophe unausweichlich. Es wird eine neue Verbindung aufgebaut, um die offenen IP-Verbindungen zu schlie{[szlig ]}en. Das misslingt, da die neue IP-Addresse anders lautet. Die Leitung wird aufgelegt aber die offenen IP-Verbindungen sind immer noch vorhanden. Daher wird neu gew{[auml ]}hlt, und so weiter... Dies wird nur durch den RST-Revoking Patch vermieden, der in die Kernel 2.0.x eingebunden ist, jedoch nicht in den Kerneln 2.1/2.2/2.3. Du kannst jedoch einen angepassten Patch f{[uuml ]}r die Kernel 2.2.x und etwas Hintergrundwissen dazu von {urlnam} bekommen. Sieh Dir dazu auch die Frage syncppp_1stpacketan. Beachte auch, da{[szlig ]} Du die Option "defaultroute" des ipppd benutzt statt route add/del default in ip-up/ip-down.
  5. TCP-Wiederholversuche l{[ouml ]}sen Hinauswahlen aus: wenn der Kernel versucht, TCP-Pakete zu senden und keine Antwort bekommt, wird er versuchen, die Sendung zu wiederholen (normalerweise alle 120 Sekunden). Pr{[uuml ]}fe, ob Du die folgenden Parameter anpassen willst: Dazu geh{[ouml ]}rende Dokumentation findest Du in /usr/src/linux/Documentation/proc.txt.
  6. Anfragen von Deinem lokalen DNS l{[ouml ]}sen einen W{[auml ]}hlvorgang aus: siehe Frage dod_localdns.
  7. Sendmail l{[ouml ]}st den W{[auml ]}hlvorgang aus: siehe Frage dod_sendmail.
  8. Windows 95 Clients l{[ouml ]}sen den W{[auml ]}hlvorgang aus: siehe Fragen dod_win95, dod_localdns, und dod_win95b.
  9. Samba l{[ouml ]}st den W{[auml ]}hlvorgang aus: siehe Frage dod_samba.
  10. Netscape l{[ouml ]}st beim Start einen W{[auml ]}hlvorgang aus: siehe Frage dod_netscape.
  11. dhcpd l{[ouml ]}st Ausw{[auml ]}hlvorg{[auml ]}nge aus: Deaktivieren Sie den dhcpd und pr{[uuml ]}fen Sie Ihre Einstellungen...
  12. Schlie{[szlig ]}e manuell noch offene IP-Verbindungen wenn die Leitung unterbrochen wird: siehe Frage dod_closeipconnect.
  13. Dein Computer ist abgest{[uuml ]}rzt, erzeugt aber noch Interrupts: siehe Frage dod_onlineoncrash.

17.4 dod{[lowbar]}off: Wie kann ich Dial-on-Demand verl{[auml ]}sslich abschalten?

  1. Wenn Du immer manuell w{[auml ]}hlen willst, setze den Dialmode auf manual (siehe Frage dialout_dialmode). Dann benutze isdnctrl dial {[lt ]}device{[gt ]} zum Hinausw{[auml ]}hlen und isdnctrl hangup {[lt ]}device{[gt ]} zum Beenden der Verbindung.
  2. Richte Deinen Dialmode korrekt ein (siehe Frage dialout_dialmode). Setze z.B. den Dialmode auf manual in ip-down. Dann findet eine automatische Hinauswahl nur einmal statt, wenn Du den Dialmode auf auto setzt.
  3. Entferne die Telefonnummer des Interfaces oder stelle eine ung{[uuml ]}ltige Nummer ein. Dann kannst Du an den Beschwerden im syslog sehen, ob ein Prozess Pakete in die Welt hinaus schicken will.
  4. Schalte das System ab.
  5. L{[ouml ]}sche die Route zum ISDN-Device. Ein Beispiel, wie jedes automatische W{[auml ]}hlen vermieden wird:
    /sbin/route del default
    /sbin/isdnctrl system off
    /sbin/ifconfig ippp0 down
    

    So l{[auml ]}uft wieder alles normal:
    /sbin/isdnctrl system on
    /sbin/ifconfig ippp0 up 
    /sbin/route add {[dollar]}GATE-IP dev ippp0
    /sbin/route add default ippp0
    

    Diese Methode hat den Nachteil, da{[szlig ]} {[uuml ]}berhaupt kein W{[auml ]}hlvorgang m{[ouml ]}glich ist.

17.5 dod{[lowbar]}strategy: Wie {[uuml ]}berpr{[uuml ]}fe ich unerkl{[auml ]}rbare W{[auml ]}hlvorg{[auml ]}nge?

Das Finden der Ursache von unerwarteten W{[auml ]}hlvorg{[auml ]}ngen ist der erste Schritt, sie zu stoppen. Dieses Finden ist jedoch normalerweise schwieriger als die Probleml{[ouml ]}sung. Hier sind Vorschl{[auml ]}ge, was Du tun kannst:

17.6 dod{[lowbar]}winclient: Kann es sein, da{[szlig ]} die Win95-Maschine in meinem LAN automatische W{[auml ]}hlvorg{[auml ]}nge ausl{[ouml ]}st?

Ja. Beim Start von Windows 3.11/95 versucht dieses, sich mit dem Nameserver Deines Providers zu unterhalten (falls bekannt) um einige Domains aufzul{[ouml ]}sen (z.B. WORKGROUP.xxx). Hier folgen M{[ouml ]}glichkeiten, dieses zu vermeiden:

17.7 dod{[lowbar]}localdns: Ich habe einen lokalen DNS eingerichtet. Warum l{[ouml ]}st dieser unerw{[uuml ]}nschte Anwahlen aus? Wie finde ich die Ursache?

Schalte in named den Debug-Level 1 ein und schau Dir das Logfile in /var/tmp an. Du findest da sehr oft normale DNS-Anfragen von Windows-Maschinen. Das Problem ist, da{[szlig ]} Namen wie "WORKGROUP.domain.de" abgefragt werden, d.h., Namen, die der DNS nicht kennen kann. Windows scheint nach seinem master browser oder einem Domain-Controller zu suchen (deutschsprachige Leser finden in der ct 12/99, Seite 224: "Schnitzeljagd - Netzwerkumgebung und Browserdienst im Windows-Netzwerk" weitere Details). Zur Umgehung dieses Problems muss der Name der Workgroup per DNS aufgel{[ouml ]}st werden k{[ouml ]}nnen. Oder setze einen Primary Domain Controller in Deinem LAN ein.

17.8 dod{[lowbar]}forwarddns: Ich habe meinen Nameserver im 'forward' Modus konfiguriert, mit einer Adresse. Nun w{[auml ]}hlt er fast jede Minute?

Von Zeit zu Zeit wird der Nameserver eine Anfrage an seinen Forwarder schicken. Das l{[ouml ]}st eine Anwahl aus. Da Dein ISP dynamische IP-Adressen benutzt wird die Anfrage mit einer falschen IP-Adresse hinaus geschickt (zum Zeitpunkt der Starts der Verbindung). Also wird keine Antwort empfangen. Bind wartet eine Minute und wiederholt den Vorgang. Wenn Deine Verbindung in dieser Zeit getrennt wurde, l{[ouml ]}st das einen neuen W{[auml ]}hlvorgang mit wiederum einer anderen Adresse aus, usw.n...

Als Workaround kannst Du die Wartezeit zwischen den Sendeversuchen verk{[uuml ]}rzen, wie es bei der Frage dialout_bind beschrieben wird.

Alternativ kannst Du die Option {[quot ]}dialup yes;{[quot ]} in der named.conf setzen. Dadurch wird named beim Start nur eine Interaktion mit dem Verteiler durchf{[uuml ]}hren (und dabei ein Ausw{[auml ]}hlen ausl{[ouml ]}sen). Danach wird named ein sehr langes Intervall (24h?) abwarten ehe er eine erneute Abfrage startet. named wird nur bei direkten Anfragen mit dem Verteiler in Kontakt treten und das passiert im Normalfall wenn Du sowieso verbunden bist.

17.9 dod{[lowbar]}sendmail: Wie kann ich erreichen, da{[szlig ]} sendmail zwar keine Verbindungen aufbaut aber trotzdem die lokale Mail ausliefert?

Zuerst musst Du sendmail dazu bringen, keine DNS-Verbindungen zu {[ouml ]}ffnen. Du musst die Optionen 'nodns' und 'nocanonify' aktivieren.

Wenn Du einen smarthost hast, musst Du sicherstellen, da{[szlig ]} wegen ihm kein Nameserver abgefragt wird. Du kannst den smarthost direkt mit seiner IP-Addresse angeben oder seinen Namen in /etc/hosts eintragen (/etc/host.conf sollte dann die Zeile 'order hosts bind' enthalten).

Setze alle nicht lokalen Mailer auf 'expensive' ('define(SMTP{[lowbar]}MAILER{[lowbar]}FLAGS, e)') und verbiete dann sendmail, automatisch {[uuml ]}ber diese teueren Wege zu verbinden (mit einem 'define('confCON{[lowbar]}EXPENSIVE", 'True')'). Der Aufruf von sendmail sollte keine Zeitangabe f{[uuml ]}r die Option '-q' enthalten (d.h., nur '-bd -os -q'). '-os' bewirkt, da{[szlig ]} alle Mails in die Warteschlange eingereiht werden (was nicht verhindert, da{[szlig ]} lokale Mails sofort ausgeliefert werden). Der einzige Haken ist, da{[szlig ]} sendmail beim Booten Mail, die noch in der Warteschlange liegt, ausliefern will, obwohl das Netzwerk noch nicht l{[auml ]}uft. Deshalb solltest Du beim Booten alle Mails aus /var/mqueue entfernen bevor sendmail gestartet wird und nach dem Start von sendmail wieder dort ablegen.

Mail an teuere Mailer wird nun nur durch den expliziten Aufruf 'sendmail -q' abgeschickt.

17.10 dod{[lowbar]}samba: Das Samba-Paket l{[ouml ]}st bei mir immer W{[auml ]}hlvorg{[auml ]}nge aus. Wie kann ich das vermeiden?

Andreas Glahn andreas@tao.westfalen.de schrieb am 31 Januar 1997: Ich hatte das gleiche Problem. Dann gab ich beim Start des Samba-Demons diesem die interne IP-Addresse, die ich hier zuhause benutze. Seither wird eine Anfrage von Samba nicht mehr an das default gateway geschickt sondern bleibt intern.

Schau Dir die Konfiguration mit netstat und tcpdump an. Mit tcpdump findest Du schnell heraus, zu welcher IP-Addresse Samba verbinden will.

Mein interner Linux Computer hat z.B.: 192.168.99.99 und mein Win95 Computer hat: 192.168.99.88

Auf dem Linux Computer starte ich Samba mit:


nmdb -S -B 192.168.99.255 -I 192.168.99.99

Schau Dir auch die vorherige Frage an: benutze -broadcast und vielleicht -arp bei der Definition des Interfaces!

Durchsuche die Hilfeseiten der Samba-Konfigurationsdatei nach weiteren M{[ouml ]}glichkeiten des Vermeidens von Ausw{[auml ]}hlvorg{[auml ]}ngen (mir wurde gesagt, da{[szlig ]} es einige spezielle Parameter daf{[uuml ]}r geben soll).

17.11 dod{[lowbar]}netscape: Wie kann ich Netscape abgew{[ouml ]}hnen, beim Start eine Verbindung aufzubauen?

Meistens ist in den Preferences eine nicht lokale Homepage eingetragen. Nur eine Homepage, die Netscape sofort laden kann (z.B. 'file://localhost/xxx'), l{[ouml ]}st keinen sofortigen W{[auml ]}hlvorgang aus. Alternativ kannst Du einen Cache Demon einrichten, der oft ben{[ouml ]}tigte Seiten speichert.

Des weiteren pr{[uuml ]}fe Deine Proxy-Einstellungen. Wenn Netscape einen kompletten Namen anstatt einer IP-Adresse beim Start bekommt, kann es versuchen, den Namen durch eine DNS-Anfrage aufzul{[ouml ]}sen. In dem Fall gib Netscape eine IP-Adresse.

Auch kann es sein, da{[szlig ]} Netscape versucht, seinen Newsserver zu erreichen. Wenn Du dieses Feature nicht ben{[ouml ]}tigst, kannst Du den Newsserver, den Netscape sucht (vermutlich 'news') in Deinen lokalen DNS oder in die /etc/hosts aufnehmen und auf 'localhost' verweisen.

17.12 dod{[lowbar]}closeipconnect: Nach dem Auflegen einer Leitung stelle ich mit netstat -nt fest, da{[szlig ]} IP-Verbindungen noch offen sind. Wie kann ich diese manuell schlie{[szlig ]}en?

Dies mag nur mit dem RST-Revoking-Patch (auf den in Frage dod_causes hingewiesen wird) funktionieren: Du kannst das Interface 'runterfahren' und dann wieder 'starten'. Dann wird es versuchen, hinaus zu w{[auml ]}hlen. Wenn Du aber vorher die anzuw{[auml ]}hlende Telefonnummer entfernt hast, erh{[auml ]}ltst Du die Meldung 'no outgoing number...' im syslog und sobald das Interface wieder gestartet ist werden alle offenen Verbindungen geschlossen.

Du kannst diese durch offene IP-Verbindungen ausgel{[ouml ]}sten W{[auml ]},hlversuche vermeiden, indem Du eine spezielle Firewall-Einstellung in /etc/ppp/ip-down einf{[uuml ]}gst und sie in /etc/ppp/ip-up wieder deaktivierst. Diese Firewall-Einstellung wehrt alle TCP-Pakete, die nicht den Status SYNSENT haben, ab. F{[uuml ]}ge dies in Deine /etc/ppp/ip-down ein (bei einem 2.2.x kernel):


ipchains -A output -j DENY -p tcp -i 'interface' ! -y

Add this in /etc/ppp/ip-up:
ipchains -A output -j DENY -p tcp -i 'interface' ! -y

(Bei allen Firewall-Regeln gilt: Am besten schreibt man diese Regeln in ein Script, das dann mit einem start oder stop aufgerufen wird.).

Beachte, da{[szlig ]} diese Firewall-Regel nur ganze Pakete betrifft. Fragmente werden immer diese Firewall passieren und einen W{[auml ]}hlvorgang ausl{[ouml ]}sen.

17.13 dod{[lowbar]}onlineoncrash: Ist es m{[ouml ]}glich, da{[szlig ]} selbst bei einem abgest{[uuml ]}rzten Computer eine ISDN-Verbindung bestehen bleibt (und die Geb{[uuml ]}hren weiterlaufen)?

Der ISAC Chipset, der auf vielen ISDN-Karten benutzt wird, kann im auto Modus oder im non-auto Modus laufen. Im auto Modus kann die Verbindung bei abgest{[uuml ]}rztem Computer bestehen bleiben (die Karte h{[auml ]}lt sie am Leben). Da der HiSax Treiber den non-auto Modus benutzt, sollte das mit ISDN4LINUX nicht passieren. Wenn einmal kein Interrupt mehr auf Deiner Maschine verarbeitet wird, wird die Verbindung sp{[auml ]}testens nach einer halben Minute beendet. Ein Weiterbestehen der Verbindung kann nur in dem unwahrscheinlichen Fall passieren, wenn die Maschine abst{[uuml ]}rzt, jedoch Interrupts weiterhin normal verarbeitet werden.


Next Previous Contents