Next Previous Contents

17. dod: Unerwünschte Hinauswahl mit dial-on-demand

17.1 dod_how: Wie funktioniert dial-on-demand?

Nachdem Du ein Netzwerk-Interface eingerichtet und eine Route dafür definiert hast, werden alle IP-Pakete, fü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ühren. Das bedeutet, daß jeder Benutzer eine Hinauswahl verursachen kann.

Beispiel: Du ö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öst.

Der Gebrauch von dial-on-demand ist ein gefährliches (= kostspieliges) Feature: siehe Frage dod_disaster.

17.2 dod_disaster: Was ist ein Gebühren-GAU?

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

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

17.3 dod_causes: Wodurch wird ein Gebühren-GAU ausgelöst?

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

  1. Du hast Deinen Kernel irrtü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ünden vermeiden. Du erkennst diese Ursache daran, daß Du einen Wählvorgang hast aber keine Daten übertragen werden.
  3. Andere Broadcasts von den Interfaces werden von ISDN weitergeleitet.
  4. Wenn IP-Verbindungen noch geöffnet sind wä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ß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ä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ür die Kernel 2.2.x und etwas Hintergrundwissen dazu von http://www.another.de/linux/router/ bekommen. Sieh Dir dazu auch die Frage syncppp_1stpacketan. Beachte auch, daß Du die Option "defaultroute" des ipppd benutzt statt route add/del default in ip-up/ip-down.
  5. TCP-Wiederholversuche lö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üfe, ob Du die folgenden Parameter anpassen willst: Dazu gehörende Dokumentation findest Du in /usr/src/linux/Documentation/proc.txt.
  6. Anfragen von Deinem lokalen DNS lösen einen Wählvorgang aus: siehe Frage dod_localdns.
  7. Sendmail löst den Wählvorgang aus: siehe Frage dod_sendmail.
  8. Windows 95 Clients lösen den Wählvorgang aus: siehe Fragen dod_win95, dod_localdns, und dod_win95b.
  9. Samba löst den Wählvorgang aus: siehe Frage dod_samba.
  10. Netscape löst beim Start einen Wählvorgang aus: siehe Frage dod_netscape.
  11. dhcpd löst Auswählvorgänge aus: Deaktivieren Sie den dhcpd und prüfen Sie Ihre Einstellungen...
  12. Schließe manuell noch offene IP-Verbindungen wenn die Leitung unterbrochen wird: siehe Frage dod_closeipconnect.
  13. Dein Computer ist abgestürzt, erzeugt aber noch Interrupts: siehe Frage dod_onlineoncrash.

17.4 dod_off: Wie kann ich Dial-on-Demand verlässlich abschalten?

  1. Wenn Du immer manuell wählen willst, setze den Dialmode auf manual (siehe Frage dialout_dialmode). Dann benutze isdnctrl dial <device> zum Hinauswählen und isdnctrl hangup <device> 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ü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ösche die Route zum ISDN-Device. Ein Beispiel, wie jedes automatische Wählen vermieden wird: 
    /sbin/route del default
/sbin/isdnctrl system off
/sbin/ifconfig ippp0 down
    So läuft wieder alles normal: 
    /sbin/isdnctrl system on
/sbin/ifconfig ippp0 up 
/sbin/route add $GATE-IP dev ippp0
/sbin/route add default ippp0
    Diese Methode hat den Nachteil, daß überhaupt kein Wählvorgang möglich ist.

17.5 dod_strategy: Wie überprüfe ich unerklärbare Wählvorgänge?

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

17.6 dod_winclient: Kann es sein, daß die Win95-Maschine in meinem LAN automatische Wählvorgänge auslö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ösen (z.B. WORKGROUP.xxx). Hier folgen Möglichkeiten, dieses zu vermeiden:

17.7 dod_localdns: Ich habe einen lokalen DNS eingerichtet. Warum löst dieser unerwü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ß 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öst werden können. Oder setze einen Primary Domain Controller in Deinem LAN ein.

17.8 dod_forwarddns: Ich habe meinen Nameserver im 'forward' Modus konfiguriert, mit einer Adresse. Nun wählt er fast jede Minute?

Von Zeit zu Zeit wird der Nameserver eine Anfrage an seinen Forwarder schicken. Das lö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öst das einen neuen Wählvorgang mit wiederum einer anderen Adresse aus, usw.n...

Als Workaround kannst Du die Wartezeit zwischen den Sendeversuchen verkürzen, wie es bei der Frage dialout_bind beschrieben wird.

Alternativ kannst Du die Option "dialup yes;" in der named.conf setzen. Dadurch wird named beim Start nur eine Interaktion mit dem Verteiler durchführen (und dabei ein Auswählen auslö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_sendmail: Wie kann ich erreichen, daß sendmail zwar keine Verbindungen aufbaut aber trotzdem die lokale Mail ausliefert?

Zuerst musst Du sendmail dazu bringen, keine DNS-Verbindungen zu öffnen. Du musst die Optionen 'nodns' und 'nocanonify' aktivieren.

Wenn Du einen smarthost hast, musst Du sicherstellen, daß 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_MAILER_FLAGS, e)') und verbiete dann sendmail, automatisch über diese teueren Wege zu verbinden (mit einem 'define('confCON_EXPENSIVE", 'True')'). Der Aufruf von sendmail sollte keine Zeitangabe für die Option '-q' enthalten (d.h., nur '-bd -os -q'). '-os' bewirkt, daß alle Mails in die Warteschlange eingereiht werden (was nicht verhindert, daß lokale Mails sofort ausgeliefert werden). Der einzige Haken ist, daß sendmail beim Booten Mail, die noch in der Warteschlange liegt, ausliefern will, obwohl das Netzwerk noch nicht lä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_samba: Das Samba-Paket löst bei mir immer Wählvorgä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öglichkeiten des Vermeidens von Auswählvorgängen (mir wurde gesagt, daß es einige spezielle Parameter dafür geben soll).

17.11 dod_netscape: Wie kann ich Netscape abgewö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öst keinen sofortigen Wählvorgang aus. Alternativ kannst Du einen Cache Demon einrichten, der oft benötigte Seiten speichert.

Des weiteren prü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ösen. In dem Fall gib Netscape eine IP-Adresse.

Auch kann es sein, daß Netscape versucht, seinen Newsserver zu erreichen. Wenn Du dieses Feature nicht benö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_closeipconnect: Nach dem Auflegen einer Leitung stelle ich mit netstat -nt fest, daß IP-Verbindungen noch offen sind. Wie kann ich diese manuell schließ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ählen. Wenn Du aber vorher die anzuwählende Telefonnummer entfernt hast, erhä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östen Wä,hlversuche vermeiden, indem Du eine spezielle Firewall-Einstellung in /etc/ppp/ip-down einfü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ü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ß diese Firewall-Regel nur ganze Pakete betrifft. Fragmente werden immer diese Firewall passieren und einen Wählvorgang auslösen.

17.13 dod_onlineoncrash: Ist es möglich, daß selbst bei einem abgestürzten Computer eine ISDN-Verbindung bestehen bleibt (und die Gebü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ürztem Computer bestehen bleiben (die Karte hä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ätestens nach einer halben Minute beendet. Ein Weiterbestehen der Verbindung kann nur in dem unwahrscheinlichen Fall passieren, wenn die Maschine abstürzt, jedoch Interrupts weiterhin normal verarbeitet werden.

Next Previous Contents