RE: Ursache für Verbindungsaufbau?
Guten Morgen,
> From: Gerhard Brauer [mailto:gerhard@ws01.kis.te]On Behalf Of Gerhard
>
> Sicher, die Frage ist höchstens, ob ihr unbedingt einen DNS-Slave
> zusätzlich braucht.
Nein, eigentlich nicht, aber ich hatte damals ein wenig rumexperimentiert
und dann war der Bind auf der Maschine und na ja, jetzt ist er halt ein
Slave.
> 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).
Das klappt hier soweit ganz gut, ist auch so gewollt. Jede Anfrage ins
Internet (DNS) wird auch beantwortet. Mit active-filter wird auch dann, wie
schon gesagt, sehr zuverlässig wieder getrennt.
> 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.
Das ist schlecht. Dann finde ich die Bind-Lösung besser, da in diesem Büro
die Internetnutzung zum überwiegenden Teil sich auf surfen beschränkt und
dabei ein Reverse-Lookup gebraucht wird.
> 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?
Verstehe ich jetzt nicht :-) Derzeit existiert eine DSL-Flatrate von
T-Online. Da sich die Internetaktivitäten des Büro's aber meist auf kurz mal
surfen und Emails beschränken, möchte ich gern auf einen wesentlich
günstigeren Zeittarif. Die Verbindungszeit kann aber nicht überwacht werden,
da keiner(!) in diesem Büro sich auch nur ein bisschen mit Rechner auskennt.
Für die ist Windows und Linux das gleiche, halt böhmische Dörfer. Also alles
was mit Userinteraktion zu tun hat, ist ganz schlecht.
Ich hab noch eine Verbindungsüberwachung per Skript laufen und hab ein
kleines Programm, das mir das Skript auswertet, so kann ich ziemlich genau
sehen, wie im Mittel der "Verbindungsbedarf" ist und wie man dabei auch
sieht, gibt es dabei kaum Streuungen.
> 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.
Finde ich prinzipiell auch, aber wie oben schon erwähnt, es wird in meinem
Fall nicht funktionieren. (Kleines Beispiel: Eine Mitarbeiterin konnte sich
in ihren Win2K-Rechner nicht mehr einloggen - ein telefonisch veranlasstes
Ping zeigte aber das der Rechner im Netz war, also schob ich es auf Samba;
im Endeffekt war es aber nicht Samba, die junge Frau hatte nur nicht
"gesehen", dass sich an ihrem Rechner jemand anderes eingeloggt hatte und
der Loginname des anderen immer noch da stand. Sie hat also wie gewohnt nur
ihr Passwort eingegeben und sich gewundert, warum das Login nicht klappte.
Auf so'n Fehler kommt man aus der Ferne einfach nicht und wieder umsonst
gefahren).
> 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
Danke, das versuche ich mal.
> Funktioniert nur wenn fetchmail bei euch unter dem User fetchmail
> laufen soll und ihr eine systemweite /etc/fetchmailrc verwendet.
So läuft es.
> 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).
Ich hab sonst keine großen Daemons laufen, die ins Internet wollen. Der
einzige ist postfix, falls eine Backupmail ansteht. Das stört mich nicht
bzw. hier kann man ja einfach das Ausliefern der Mails in der Nacht über
cron verzögern.
> 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, aber das hilft mir schon weiter. Ich denke und hoffe, dass mit
fetchmail das Problem gelöst ist.
Ciao, Ralf
Reply to: