[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Ursache für Verbindungsaufbau?



Gruesse!
* R.Schade@tu-braunschweig.de <R.Schade@tu-braunschweig.de> schrieb am [21.07.04 15:46]:

> Hallo,
> 
> > Ursache dürfte die fetchmail Abfrage sein. Fetchmail läuft als
> > Daemon auf dem Gateway(192.168.66.1)? Dann wird's logisch:
> > 
> > fetchmail will die IP von post.strato.de wissen und fragt dazu den
> > DNS-Master (192.168.66.2). Dieser kann die Anfrage nicht bedienen
> > und leitet zum DNS-Slave (192.168.66.1) weiter. Dieser kann die
> > Adresse ebenfalls nicht auflösen und fragt dazu seine Forarders und
> > löst dazu eine Internet-Einwahl aus.
> Rein vom Bind her, kann man das so machen, oder?

Sicher, die Frage ist höchstens, ob ihr unbedingt einen DNS-Slave
zusätzlich braucht.  Aber *jede* Anfrage die euer lokaler DNS nicht
auflösen kann löst halt bei DialOnDemand(DoD) automatisch eine
kostenpflichtige Verbindung aus - gewollt oder ungewollt. Und das
automatische Trennen der Verbindung bei z.B. "Inaktivität" klappt ja
in Zeiten der Tauschbörsen-Kids auch nicht mehr (ohne zusätzliche
ppp-Filter).

Ein zweiter Ansatz wäre halt wie von mir schon mal angesprochen
dnsmasq. Dieser arbeitet z.B. ohne automatische Forwarders sondern
nutzt *nach* einer Einwahl den DNS vom Provider. Ohne Verbindung zum
Internet dient dnsmasq als normaler DNS-Server fürs lokale Lan,
externe Adressanfragen werden ohne Internet-Verbindung halt nicht
beantwortet.
Allerdings würde solch ein Tool z.B. keine Einwahl mehr auslösen,
wenn einer im Browser www.debian.org aufruft - aber auch keine
ungewollte Verbindung aufbauen.

Wobei ich bei meinem zweiten Tip bin: aus welchem Grund nutzt ihr
DoD, wenn ihr einen Volumen-/ Zeit-abhänigen Tarif habt? Ist es nur
die Bequemlichkeit ohne Zusatztool "drin" zu sein?

Ich baue kleinere Netze ohne Flatrate bzw. Standleitung eigentlich
immer mit dnsmasq und linesrv (apt-cache show linesrv), wobei sich
die User über ein Win- oder Linux-Clienttool "einwählen" und die
Verbindung auch wieder trennen. Der "Erste" initiiert die Einwahl,
die anderen hängen sich an die Verbindung "dran", und der letzte
trennt beim Auflegen die ppp-Verbindung wirklich. Das ist
kontrollierbar, konfigurierbar (wer darf wann und überhaupt) und
nach einiger Zeit auch transparent für die User. So etwas wäre
vielleicht auch für euch im Gegenzug zu DoD eine Überlegung wert.

> > Oder: fetchmail z.B. nicht als Daemon laufen lassen, sondern nur
> > über die ppp/ip-up.d und ppp/ip-down.d, also Abholen bei jeder
> > Einwahl.
> Genau, ich hab fetchmail als Daemon laufen. Ich kann mich leider nicht
> erinnern, ob ich den so eingerichten hatte oder ob Debian mir ihn gleich
> beim Installieren so konfiguriert hat. Gibt es da eine elegante Art, den
> fetchmail für ip-up und ip-down fit zu machen (dpkg-reconfigure (Stoppt und
> startet den Daemon nur) oder so was) oder muss ich den Daemon abschalten und
> mir selber Skripte schreiben?

Ich habe es so gemacht:
apt-get install rcconf
rcconf -> fetchmail aus init.d raus
in /etc/ppp/ip-up.d/fetchmail beide Zeilen ([ - /etc/fetch... und
die awaken) auskommentiert und hinzugefügt:
su -c "fetchmail -f /etc/fetchmailrc" fetchmail

und ein Skript fetchmail nach /etc/ppp/ip-down.d mit dem Inhalt:
killall fetchmail

Funktioniert nur wenn fetchmail bei euch unter dem User fetchmail
laufen soll und ihr eine systemweite /etc/fetchmailrc verwendet.

Als erstes würde ich halt wie dir Christian auch vorschlug, alle
eure Daemons und sonstige Jobs kontrollieren ob sie evtl. eine
*ungewollte* Einwahl vornehmen (bzw. wenn nicht, diese nach getaner
Arbeit auch wieder trennen).

> > Außerdem könntest du das Dial-On-Demand z.B. für die unerwünschten
> > Zeiträume (nachts, Wochenende,etc) per cron abschalten, indem zu
> > z.B. daß Interface pppX auf Down stellst oder den laufenden pppd
> > ganz killst und zu den erlaubten Zeiten erst wieder Up schaltest
> > oder startest.
> Hatte ich auch schon mal überlegt, allerdings will ich das nicht, da, falls
> doch mal einer Überstunden machen will, er das dann auch einfach tun kann
> und ich nicht wieder einen hektischen Anruf bekomme :-)

Dazu s.o. mein Hinweis mit der kontrollierbaren, usergesteuerten
Einwahl. Infos dazu kann ich dir gerne z.B. per PM geben, da das
ganze eigentlich nur am Rande mit Debian zu tun hat.

> 
> Danke, Ralf

Gruß
	Gerhard



Reply to: