RE: Ursache für Verbindungsaufbau?
Hallo, Wobei zu bemerken ist das sich auch mit meinem Vorschlag eine Remote-Einwahl ins Netz realisieren läßt, inclusive Call-Back etc. Oder halt remote-Admin über eine dann zu aktivierende Interbet-Verbindung. Ist schon realisiert, hat aber in dem Fall nix genutzt bzw. bin nicht auf den Fehler gekommen. 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. Okay, ich hab's jetzt mit einer Mischung aus einer alten SuSE-Distri und Deinem Vorschlag realisiert: fetchmail aus der init.d rausgenommen und in ip-up.d folgendes Skript: su -c /usr/bin/fetchmail -a -v -D meineDomain.de -d 600 -f /etc/fetchmailrc /var/log/fetchmail.log 21 fetchmail sowie in ip-down.d: su -c /usr/bin/fetchmail -q /var/log/fetchmail.log 21 fetchmail Scheint momentan soweit ganz gut zu laufen, werde das jetzt mal eine Weile beobachten. Danke noch mal für die Hilfe, hab den Wald vor lauter Bäumen nicht gesehen :-) Ciao, Ralf
RE: Ursache für Verbindungsaufbau?
Guten Morgen, From: Gerhard Brauer [mailto:[EMAIL PROTECTED] 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
Re: Ursache für Verbindungsaufbau?
Hallo Gerhard, Gerhard Brauer, 21.07.2004 (d.m.y): 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. Klingt ja zunaechst etwas umkomfortabel... ;-) 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? Das vermute ich mal. 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. Ich habe die Erfahrun gemacht, dass es fuer die User am bequemsten ist, wenn man normales DoD hat: Sie brauchen nur den Browser anzuwerfen, eine URI einzugeben, und schon sind sie drin... Dass man zum automatischen Beenden der DSL-Verbindung u.U. einen Active-Filter einsetzen muss, hast Du ja schon selbst erwaehnt... Ausserdem wuerde mich interessieren, wie Du bei Deiner Loesung automatische Vorgaenge wie z.B. den von cron angestossenen Lauf von fetchmail realisierst. Gruss, Christian -- Die Schwierigkeit liegt darin, daß wir als Menschen nicht nur Probleme lösen, sondern auch Probleme schaffen. -- Edward Teller signature.asc Description: Digital signature
Re: Ursache für Verbindungsaufbau?
Gruesse! * [EMAIL PROTECTED] [EMAIL PROTECTED] schrieb am [22.07.04 07:48]: 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). Typischer Einfach-Geld-verdienen-Fehler ;-) Wobei zu bemerken ist das sich auch mit meinem Vorschlag eine Remote-Einwahl ins Netz realisieren läßt, inclusive Call-Back etc. Oder halt remote-Admin über eine dann zu aktivierende Interbet-Verbindung. Der einzige Unterschied ist IMHO halt: DoD: Anfrage - IP außerhalb des eigenen Subnets - automatische Einwahl am Gateway über die Defaultroute. Kontrollierte Einwahl: Anfrage - IP außerhalb des eigenen Subnets - kein Routen über das Gateway (da keine Defaultroute) solange nicht jemand die Einwahl tätigt. [Plaudern aus dem Nähkästchen] Wobei zu bemerken ist, das mein Herangehen *sehr* geprägt ist aus der Zeit, in der DSL bzw. irgendetwas was auch nur annähernd mit Flatrate zu tun hat, ein Fremdwort war. Mir liegt da ein Akustik-Koppler gefühlsmäßig immer noch näher als ein DSL-Splitter ;-) Und sich Bekannte und Firmen durch DoD (zumindest die erste) Telefonrechnungen einhandelten, die sich gewaschen hatten. Ich selbst habe leider kein DSL (zu modernes Glasfaser-Netz in unserer Kleinstadt) und keine Alternative zu Telek*m-ISDN. So ist das Schielen nach der Uhr allgegenwärtig. Und ich möchte halt immer auf einen Knopf drücken zum Ein- und Abwählen. [Nähkasten zu] 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. Anmerkung: dann gehört natürlich in die /etc/fetchmailrc ein Eintrag wie: set daemon 300 # alle 5min pollen damit *während* der Verbindung auch permanent Mail geholt wird. *Das* allerdings kann wieder eure automatische Trennung bei Inaktivität behindern. 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. Wobei ich bei DoD *dann* wie Christian vorschlug eher die cron-Skripte zu fetchmail an vernünftige Mail-Hol-Zeiten anpassen würde. Ciao, Ralf Gruß Gerhard
Re: Ursache für Verbindungsaufbau?
Gruesse! * Christian Schmidt [EMAIL PROTECTED] schrieb am [22.07.04 11:54]: Hallo Gerhard, Gerhard Brauer, 21.07.2004 (d.m.y): 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. Klingt ja zunaechst etwas umkomfortabel... ;-) Bezieht sich aber nur auf DNS-Anfragen. Kleines Beispiel was im Gegensatz zu DoD damit verhindert werden kann: - HTML-Mails, die beim Öffnen Bilder etc. aus dem Netz nachziehen wollen, lösen *keine* Einwahl aus. - Irgendwelche Betriebsysteme, die von sich aus gerne ungefragt mit dem Internet kommunizieren, oder deren Viren/Backdoors, lösen *keine* Einwahl mehr aus bzw. der User kriegt etwas davon mit (Host xyz nicht gefunden) - Ich installiere z.B. den Mozilla irgendwo neu. Nach dem Start will er sofort eine Verbindung zu mozilla.org. Das will ich nicht, da für mich kein Anlaß dazu besteht. Und es ohne Nutzen Geld kostet. Es gibt sicher noch mehr Gründe, die IMHO immer dann Sinn machen, sobald für die Verbindung in Form von Volumen oder Zeit Geld bezahlt werden muß. Und in diesen Fällen bin ich eigentlich (siehe auch andere Mail) immer für absolute Kontrolle in Form eines Ein-/Aus-Schalters. Ich habe die Erfahrun gemacht, dass es fuer die User am bequemsten ist, wenn man normales DoD hat: Sie brauchen nur den Browser anzuwerfen, eine URI einzugeben, und schon sind sie drin... Dass man zum automatischen Beenden der DSL-Verbindung u.U. einen Active-Filter einsetzen muss, hast Du ja schon selbst erwaehnt... Ausserdem wuerde mich interessieren, wie Du bei Deiner Loesung automatische Vorgaenge wie z.B. den von cron angestossenen Lauf von fetchmail realisierst. Z.B. in dem im cron-Skript erst die Verbindung hergestellt wird, etwas wie: pppd call $provider oder isdnctrl dial $provider und am Ende wieder getrennt. Oder über den ifconfig up/down Mechanismus. GNU/Linux bietet da ja zum Glück diverse Wege zum Ziel an. Auch zum Punkt DoD ja oder nein. Ich persönlich bin halt bisher immer gut gefahren mit der Prämisse: Kein Pauschalpreis für die Internet-Anbindung *und* keine Dienste ins Internet - dann kein DoD. Es ist ja evtl. auch eine Frage der Haftbarmachung wenn in einem nicht ständig administrierten Netzwerk über längere Zeit eine kostenpflichtige Verbindung (vielleicht sogar mit unerlaubtem Traffic) besteht und keiner der Benutzer bzw. der Mitarbeiter kriegt das mit. Gruss, Christian Gruß Gerhard
Re: Ursache für Verbindungsaufbau?
Hallo Gerhard, Gerhard Brauer, 22.07.2004 (d.m.y): Bezieht sich aber nur auf DNS-Anfragen. Kleines Beispiel was im Gegensatz zu DoD damit verhindert werden kann: - HTML-Mails, die beim Öffnen Bilder etc. aus dem Netz nachziehen wollen, lösen *keine* Einwahl aus. [..] Es gibt sicher noch mehr Gründe, die IMHO immer dann Sinn machen, sobald für die Verbindung in Form von Volumen oder Zeit Geld bezahlt werden muß. Und in diesen Fällen bin ich eigentlich (siehe auch andere Mail) immer für absolute Kontrolle in Form eines Ein-/Aus-Schalters. Macht durchaus Sinn. Ich vermute mal, dass aber auch bei dieser Variante ein (einstellbarer) Timeout zuschlaegt, wenn ein Benutzer vergisst, die Verbindung zu beenden? [..] Ausserdem wuerde mich interessieren, wie Du bei Deiner Loesung automatische Vorgaenge wie z.B. den von cron angestossenen Lauf von fetchmail realisierst. Z.B. in dem im cron-Skript erst die Verbindung hergestellt wird, etwas wie: pppd call $provider oder isdnctrl dial $provider und am Ende wieder getrennt. Oder über den ifconfig up/down Mechanismus. OK, ist klar - die Frage haette ich mir eigentlich auch selbst beantworten koennen. Nach dem, was apt-cache show linesrv mir so verraet, erfolgt die Bedienung benutzerseitig ueber ein CGI-Skript? Gruss, Christian -- Pension ist die begehrteste Alterserscheinung. -- Wolfram Weidner signature.asc Description: Digital signature
Re: Ursache für Verbindungsaufbau?
Gruesse! * Christian Schmidt [EMAIL PROTECTED] schrieb am [22.07.04 13:55]: Hallo Gerhard, Gerhard Brauer, 22.07.2004 (d.m.y): Bezieht sich aber nur auf DNS-Anfragen. Kleines Beispiel was im Gegensatz zu DoD damit verhindert werden kann: - HTML-Mails, die beim Öffnen Bilder etc. aus dem Netz nachziehen wollen, lösen *keine* Einwahl aus. [..] Es gibt sicher noch mehr Gründe, die IMHO immer dann Sinn machen, sobald für die Verbindung in Form von Volumen oder Zeit Geld bezahlt werden muß. Und in diesen Fällen bin ich eigentlich (siehe auch andere Mail) immer für absolute Kontrolle in Form eines Ein-/Aus-Schalters. Macht durchaus Sinn. Ich vermute mal, dass aber auch bei dieser Variante ein (einstellbarer) Timeout zuschlaegt, wenn ein Benutzer vergisst, die Verbindung zu beenden? Das kann man einstellen. Entweder Client-seitig (s.u.) oder am Gateway selbst. Ich hatte z.B. mal eine Konstellation, bei der der User so vergesslich war, das er selbst irgendwelche grüne Lichter am Client (für online) geflissentlich übersah. Da hab ich ihm eine Umgebung gebaut, in der er in einem bestimmten Ordner in seinem Home eine Datei anlegen mußte (deren Vorhanden- oder Nichtvorhanden-Sein dann von einem Cron geprüft wurde) um länger als 5 min Online sein zu können. Ansonsten wurde vom Gateway gnadenlos getrennt. Das war aber schon sehr krank, aber mit Bordmitteln halt machbar. Nach dem, was apt-cache show linesrv mir so verraet, erfolgt die Bedienung benutzerseitig ueber ein CGI-Skript? Es gibt einen Linus-GTK-Client (apt-cache show xlc) und einen kostenlosen Win-Client. Auch einen Java-Client. Die URL zu linesrv (bzw. linecontrol) ist http://linecontrol.sourceforge.net/ , dort gibt es IMHO auch die Clients. Etwas ähnliches (Einwahltool über einen maskierten Router) ist masqdialer, mit diesem habe ich aber keine guten Erfahrungen gemacht. Dieses Client/Server-Tool ist halt ideal für z.B. mehrere Provider, die man auswählen möchte in Verbindung mit ISDN oder Modem. Aber auch eine DSL-Verbindung läßt sich bequem ein- und auschalten (wie grafisches pon/poff für die Clients). Und halt konfigurierbar nach IP (welcher Rechner im LAN und mit Username/Passwortabfrage). Das hält 90% aller Benutzer mit durchschnittlichem PC-Wissen davon ab, am Client Internet zu benutzen. Gruss, Christian Gruß Gerhard
RE: Ursache für Verbindungsaufbau?
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? 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? 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 :-) Danke, Ralf
Re: Ursache für Verbindungsaufbau?
Hallo R.Schade, [EMAIL PROTECTED], 21.07.2004 (d.m.y): From: Christian Schmidt Offensichtlich forwardest Du DNS-Anfragen. Das wuerde ich abstellen... Hier jedenfalls wird von 192.168.66.2 eine DNS-Anfrage an den T-Online-Nameserver weitergeleitet. Ich weiß, so soll es auch sein. Alle DNS-Anfragen, die nicht lokal sind und nicht aufgelöst werden können, sollen über T-Online aufgelöst werden. Aber einer Deiner Rechner ist fuer Dein LAN (Caching-Only) Nameserver, oder? Wenn ja, dann sollte der _Server_ beim Forwarder (dem Nameserver von T-Online) anfragen und nicht der Client. [..] Der erste Logeintrag stammt aus der Output-Chain... Stimmt, sehe ich auch gerade. Also doch ein Auslösen vom Server.1, der, wenn ich es mit dem anderen Log vom Bind vergleiche, post.strato.de auflösen will. Da sehe ich bei mir 2 Probleme. Zum einen sollte der Server die IP langsam kennen, da er sie ja oft genug auflöst (Problem mit Bind) Nicht unbedingt. Wenn die auf dem Strato-Nameserver (der die Zonendatei fuer strato.de vorhalten duerfte) die TTL klein genug ist, duerfte Dein bind die IP-Adresse schnell wieder vergessen. und zum anderen wird die IP von fetchmail gefordert, der ja gar nicht laufen sollte, da die Verbindung ja eigentlich down war?! Was wäre das dringendere Problem, was es als erstes zu lösen gilt? Auf welchem Rechner laeuft bei Dir denn fetchmail? Auf dem sich einwaehlenden oder auf dem anderen? Im Falle des letztgenannten frage ich Dich nochmal: Woher soll Maschine2 wissen, ob Maschine1 eingewaehlt ist? [..] Woher soll uebrigens der zweite Host wissen, ob der erste online ist oder nicht? Ähm gar nicht?! Wie gesagt, fetchmail löst die DNS-Anfrage aus und fetchmail sollte Ruhe geben, da die Verbindung ja nicht besteht. fetchmail moechte sie aber offensichtlich aufbauen... Dem 2. Server ist es egal, er bekommt die Anfrage (okay, ob das so sein muss, ist eine andere Frage) und beantwortet sie auch, worauf eine Einwahl erfolgt. Diese würde aber auch erfolgen, wenn fetchmail die IP schon wüsste und diese dann auf Mails abfragt. Das ist klar. Gruss, Christian -- Auf seine Freiheit verzichten heißt auf seine Menschenwürde, Menschenrechte, selbst auf seine Pflichten verzichten. -- Jean Jacques Rousseau signature.asc Description: Digital signature
Re: Ursache für Verbindungsaufbau?
N'Abend, Am 2004-07-21 10:24:36, schrieb [EMAIL PROTECTED]: Hallo, | Jul 20 21:33:27 apollo pppd[171]: Starting link | Jul 20 21:33:27 apollo kernel: OUTPUT:IN= OUT=ppp0 SRC=217.82.163.80 DST=194.25.2.129 LEN=71 TOS=0x00 PREC=0x00 TTL=64 ID=1880 DF PROTO=UDP SPT=53 DPT=53 LEN=51 Da versucht der Rechner mit der IP 217.82.163.80 (pD952A350.dip.t-dialin.net) einen Domain Name Server auf 194.25.2.129 (not found) anzusprechen. | Jul 20 21:33:29 apollo chronyd[385]: Source 130.149.17.21 online hora.cs.tu-berlin.de. | Jul 20 21:33:29 apollo chronyd[385]: Source 140.162.8.3 online Host 21.17.149.140.in-addr.arpa not found: 3(NXDOMAIN) | Jul 20 21:33:29 apollo chronyd[385]: Source 192.53.103.103 online 103.103.53.192.in-addr.arpa domain name pointer ntp1.ptb.de. | Jul 20 21:33:29 apollo chronyd[385]: Source 192.53.103.104 online 104.103.53.192.in-addr.arpa domain name pointer ntp2.ptb.de. | Jul 20 21:33:29 apollo kernel: FORWARD:IN=eth1 OUT=ppp0 SRC=192.168.66.2 DST=194.25.2.129 LEN=71 TOS=0x00 PREC=0x00 TTL=63 ID=85 DF PROTO=UDP SPT=53 DPT=53 LEN=51 Der andere Server hat die IP 192.168.66.2, so dass ich denke, dass er die Verbindung wg. einer DNS-Anfrage auslöst. Sieht so aus... Und nach den obigen Servern zu urteilen versuch der Server sich mit den vier ZeitServern in verbindung zu setzen. | Jul 20 21:33:29 apollo kernel: OUTPUT:IN= OUT=ppp0 SRC=217.82.164.35 DST=217.5.115.7 LEN=71 TOS=0x00 PREC=0x00 TTL=64 ID=1881 DF PROTO=UDP SPT=53 DPT=53 LEN=51 35.164.82.217.in-addr.arpa domain name pointer pD952A423.dip.t-dialin.net. Host 7.115.5.217.in-addr.arpa not found: 3(NXDOMAIN) Da der erste iptables-Eintrag aus der Forward-Chain stammt und eine DNS-Anfrage ist, habe ich jetzt die Verbindungsanfragen auf dem 192.168.66.2 mitgeloggt: Danke, Ralf Greetings Michelle -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: Ursache für Verbindungsaufbau?
Hallo R.Schade, [EMAIL PROTECTED], 21.07.2004 (d.m.y): Genau, ich hab fetchmail als Daemon laufen. Das wuerde ich als erstes abschalten. 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? Jein. Das Abschalten des Daemons macht u.U. Sinn. Ich wuerde aber genauso davon absehen, den fetchmail-Aufruf durch ein ip-up-Skript erledigen zu lassen - eher wuerde ich das System so einrichten, dass es in sinnvollen (!) Abstaenden die eMails abgeholt werden, z.B. einmal die Stunde, und zwar in der Arbeitszeit. Gruss, Christian -- Ein Dutzend verlogener Komplimente ist leichter zu ertragen als ein einziger aufrichtiger Tadel. -- Mark Twain (eigl. Samuel Langhorne Clemens) signature.asc Description: Digital signature
Re: Ursache für Verbindungsaufbau?
Gruesse! * [EMAIL PROTECTED] [EMAIL PROTECTED] 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
RE: Ursache für Verbindungsaufbau?
Hallo, danke erst mal allen für die Hilfe. Ich hab jetzt mit iptables und -state NEW sowie -j LOG --tcp-sequence die Output- und Forward-Chain geloggt. From: Michelle Konzack [mailto:[EMAIL PROTECTED] Am 2004-07-19 12:43:24, schrieb Gerhard Brauer: Gruesse! I.d.R. sind das DNS(=Nameserver)-Anfragen (=Port tcp/udp 53). Wenn ihr in eurem Netz einen eigenen Nameserver verwendet, muß der wirklich alle Adressen die im lokalen LAN vorkommen auflösen können und alle Clients dürfen nur diesen DNS benutzen. Bei Anfragen nach draußen ist es dann halt eine Frage der Konfiguration, ob eine nicht beantwortete Anfrage einen Dial-out auslöst. Leider ist es genauso :-( Es sind DNS-Anfragen des Servers für die lokale Domain. Jetzt frage ich mich natürlich, wer fragt welche Adressen ab und warum (sie müssten vom Server direkt ausgehen, denn andere Rechner sind über Nacht nicht an). Als DNS läuft auf dem Server Bind9 als Master für die Domain. Auf dem Gateway läuft ebenfalls als DNS ein Bind9 als Slave für die Domain und Forwarder für weitere Anfragen. Jetzt muss ich mal schauen, ob ich mir die Queries mitloggen lasse. Gibt es noch andere Möglichkeiten? Das Problem hatte ich auch, und es war Ruhe, nachdem ich meine gesamte /etc/hosts in bind9 importiert hatte. Das habe ich auch. Werde wohl doch mal mich mit bind rumschlagen müssen (oder evtl. mir dnsmasq mal anschauen). Ciao, Ralf
Re: Ursache für Verbindungsaufbau?
On Tue, Jul 20, 2004 at 09:34:11AM +0200, [EMAIL PROTECTED] wrote:
Als DNS läuft auf dem Server Bind9 als Master für die Domain. Auf dem
Gateway läuft ebenfalls als DNS ein Bind9 als Slave für die Domain und
Forwarder für weitere Anfragen.
Jetzt muss ich mal schauen, ob ich mir die Queries mitloggen lasse. Gibt es
noch andere Möglichkeiten?
Mit Bind8 funktioniert Logging mit
logging {
channel q_log {
file /var/log/named-debug.log versions 3 size 2m;
print-time yes;
print-category yes;
};
category queries { q_log; };
category lame-servers { null; };
category cname { null; };
};
Ich vermute allerdings das ein Programm IPv6-Adressen() haben möchte,
und dein Bind9 nur IPv4-Adressen für deine Domain hat. Dann sollte dir
Einträge in der Form:
server1 IN A 192.168.10.9
server1 IN :::192.168.10.9
helfen.
signature.asc
Description: Digital signature
Re: Ursache für Verbindungsaufbau?
[EMAIL PROTECTED] schrieb: Hallo, wie kann ich quasi automatisiert den Verursacher für Verbindungsanfragen ins Internet heraus bekommen? Hintergrund ist der, dass der Internetzugang über einen Woody-Server mit einem DSL-Zeittarif geschieht. Da dieser in einer Firma steht, möchte ich gern, dass er Nachts und am Wochenende Ruhe gibt, damit ein kleinerer Tarif gewählt werden kann. Auf dem Server selber sind alle Skripte und Crondienste so angepasst (meine ich jedenfalls; /etc/crontab, /etc/cron.d, /etc/cron.*, /var/spool/cron/crontabs/*), dass hier nichts außer der Reihe passieren sollte. Ein weiterer Woody-Server, der ebenfalls ständig an ist und den anderen Server als Gateway nutzt, ist ebenfalls so konfiguriert, dass er z.B. Virenupdate's nur zu bestimmten definierten Zeiten holt. Trotz dem wird alle 10 Minuten eine Verbindung aufgebaut (24h lang, jeden Tag). Wie kann ich über Logs herausbekommen, wer diese Verbindungen verursacht? Ich kann nicht mal sagen, von welchem Server diese initiiert werden. Kann man da etwas mit der Logfunktionalität von iptables was machen oder gibt es Möglichkeiten in den ip-up-Skripten? Mir würde die Rechner-IP, die die Verbindung haben will und evtl. die IP, von der etwas angefragt wird, schon für weitere Untersuchungen reichen. Du kannst mit iptables die Pakete ins syslog schreiben lassen. Eine Übersicht über alle Optionen bekommst du in der iptables man-page. MfG Markus Schulz -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Ursache für Verbindungsaufbau?
Hallo R.Schade, [EMAIL PROTECTED], 19.07.2004 (d.m.y): wie kann ich quasi automatisiert den Verursacher für Verbindungsanfragen ins Internet heraus bekommen? Spontan fallen mir da die Log-Funktion von iptables sowie Programme wie (t)ethereal und/oder tcpdump ein. Hintergrund ist der, dass der Internetzugang über einen Woody-Server mit einem DSL-Zeittarif geschieht. Da dieser in einer Firma steht, möchte ich gern, dass er Nachts und am Wochenende Ruhe gibt, damit ein kleinerer Tarif gewählt werden kann. Auf dem Server selber sind alle Skripte und Crondienste so angepasst (meine ich jedenfalls; /etc/crontab, /etc/cron.d, /etc/cron.*, /var/spool/cron/crontabs/*), dass hier nichts außer der Reihe passieren sollte. Ein weiterer Woody-Server, der ebenfalls ständig an ist und den anderen Server als Gateway nutzt, ist ebenfalls so konfiguriert, dass er z.B. Virenupdate's nur zu bestimmten definierten Zeiten holt. Trotz dem wird alle 10 Minuten eine Verbindung aufgebaut (24h lang, jeden Tag). Die Tatsache, dass das alle 10 min passiert, spricht IMO sehr dafuer, dass da etwas Zeitgesteuertes eine Verbindung aufbaut. Wenn es nur die beiden Linux-Maschinen betreffen kann, wuerde ich nochmal verstaerkt nach automatischen Aufrufen von z.B. dem MTA oder fetchmail fahnden. Kannst Du denn ausschliessen, dass da noch irgendwelche Windows-Rechner herumfuhrwerken? Wie kann ich über Logs herausbekommen, wer diese Verbindungen verursacht? Du koenntest z.B. mit (t)ethereal alle nach aussen gehenden DSN-Abfragen mitprotokollieren lassen. Deren Inhalt (die Information, welcher Rechnername aufgeloest werden soll) koennte weiteren Aufschluss ueber die Ursache der Einwahl geben. Gruss viel Erfolg, Christian -- - Schnee, der sich leicht ballen läßt, schmilzt bald. -- Jean Paul signature.asc Description: Digital signature
Re: Ursache für Verbindungsaufbau?
Gruesse! * [EMAIL PROTECTED] [EMAIL PROTECTED] schrieb am [19.07.04 10:32]: Hallo, wie kann ich quasi automatisiert den Verursacher für Verbindungsanfragen ins Internet heraus bekommen? Hintergrund ist der, dass der Internetzugang über einen Woody-Server mit einem DSL-Zeittarif geschieht. Da dieser in einer Firma steht, möchte ich gern, dass er Nachts und am Wochenende Ruhe gibt, damit ein kleinerer Tarif gewählt werden kann. Auf dem Server selber sind alle Skripte und Crondienste so angepasst (meine ich jedenfalls; /etc/crontab, /etc/cron.d, /etc/cron.*, /var/spool/cron/crontabs/*), dass hier nichts außer der Reihe passieren sollte. Ein weiterer Woody-Server, der ebenfalls ständig an ist und den anderen Server als Gateway nutzt, ist ebenfalls so konfiguriert, dass er z.B. Virenupdate's nur zu bestimmten definierten Zeiten holt. Trotz dem wird alle 10 Minuten eine Verbindung aufgebaut (24h lang, jeden Tag). Wie kann ich über Logs herausbekommen, wer diese Verbindungen verursacht? Ich kann nicht mal sagen, von welchem Server diese initiiert werden. Kann man da etwas mit der Logfunktionalität von iptables was machen oder gibt es Möglichkeiten in den ip-up-Skripten? Mir würde die Rechner-IP, die die Verbindung haben will und evtl. die IP, von der etwas angefragt wird, schon für weitere Untersuchungen reichen. Wie dir schon geschrieben wurde, lass iptables alle Pakete dieser 10-min Intervalle ins syslog schreiben. Dann kannst du anhand der zeitlichen Abfolge den Verursacher anhand geloggtes Paket - pppd Einwahl erkennen. I.d.R. sind das DNS(=Nameserver)-Anfragen (=Port tcp/udp 53). Wenn ihr in eurem Netz einen eigenen Nameserver verwendet, muß der wirklich alle Adressen die im lokalen LAN vorkommen auflösen können und alle Clients dürfen nur diesen DNS benutzen. Bei Anfragen nach draußen ist es dann halt eine Frage der Konfiguration, ob eine nicht beantwortete Anfrage einen Dial-out auslöst. Wenn ihr keinen eigenen DNS verwendet, kannst du evtl. zu betsimmten Zeiten DNS-Anfragen (=Port udp/tcp 53) über das externe Interface per iptables-Regel sperren. Allerdings würde ich ab einer gewissen Anzahl PCs auf jedenfall einen eigenen DNS einrichten. Mein Favorit in kleinen LANs, bei denen der DNS des Providers nach der Einwahl mitbenutzt wird, ist dnsmasq. apt-cache show dnsmasq gibt dir weitere Infos. Oder halt bind, ist IMHO aber meistens Overkill. Danke, Ralf Gruß Gerhard
RE: Ursache für Verbindungsaufbau?
Hallo, From: Markus Schulz [mailto:[EMAIL PROTECTED] Sent: Monday, July 19, 2004 12:14 PM Du kannst mit iptables die Pakete ins syslog schreiben lassen. Okay, _das_ wollte ich aber gern vermeiden, da ich das Log im Zeitraum von 1-2 Tagen laufen lassen muss, was es ziemlich groß macht und mir das spätestens bei der Analyse zu aufwendig erscheint. Außerdem wüsste ich jetzt auch nicht so genau, ob ich die Output oder die Forward Regeln brauch, da ich den Verursacher noch nicht lokalisieren konnte. Deshalb dachte ich auch eher an eine Lösung mittels ip-up. Denn da müsste ja theoretisch die Anfrage irgendwo auftauchen, so dass ich sie loggen könnte. Ciao, Ralf
Re: Ursache für Verbindungsaufbau?
[EMAIL PROTECTED] schrieb: Hallo, From: Markus Schulz [mailto:[EMAIL PROTECTED] Sent: Monday, July 19, 2004 12:14 PM Du kannst mit iptables die Pakete ins syslog schreiben lassen. Okay, _das_ wollte ich aber gern vermeiden, da ich das Log im Zeitraum von 1-2 Tagen laufen lassen muss, was es ziemlich groß macht und mir das spätestens bei der Analyse zu aufwendig erscheint. Außerdem wüsste ich jetzt auch nicht so genau, ob ich die Output oder die Forward Regeln brauch, da ich den Verursacher noch nicht lokalisieren konnte. du könntest mit --limit und/oder --limit-burst die Datenmenge verkleinen. Ansonsten logge beides, Forward und Output und setze jeweils ein anderes Prefix wenn du nicht weißt ob es der Server selbst oder ein anderer Rechner aus dem Netz ist. Sonst fällt mir leider auch keine andere Variante ein (ausser den bereits genannten in den anderen Antworten) Deshalb dachte ich auch eher an eine Lösung mittels ip-up. Denn da müsste ja theoretisch die Anfrage irgendwo auftauchen, so dass ich sie loggen könnte. hmm muss ich leider passen, keine Ahnung ob sich da was machen läßt. MfG Markus Schulz -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Ursache für Verbindungsaufbau?
On Montag, 19. Juli 2004 10:32, [EMAIL PROTECTED] wrote: Hallo, wie kann ich quasi automatisiert den Verursacher für Verbindungsanfragen ins Internet heraus bekommen? Hintergrund ist [...] Hier nur eine kleine Referenz zu einem Problem was ich mal in die Richtung hatte: http://groups.google.de/groups?q=%22kim+neunert% 22start=30hl=delr=ie=UTF-8selm=i86vla.am1.ln%40127.0.0.1rnum=39 Gruß Kim -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Ursache für Verbindungsaufbau?
Am 2004-07-19 12:43:24, schrieb Gerhard Brauer: Gruesse! Wie dir schon geschrieben wurde, lass iptables alle Pakete dieser 10-min Intervalle ins syslog schreiben. Dann kannst du anhand der zeitlichen Abfolge den Verursacher anhand geloggtes Paket - pppd Einwahl erkennen. Dann sollte aber auch die Source-Addresse im syslog drinstehen... I.d.R. sind das DNS(=Nameserver)-Anfragen (=Port tcp/udp 53). Wenn ihr in eurem Netz einen eigenen Nameserver verwendet, muß der wirklich alle Adressen die im lokalen LAN vorkommen auflösen können und alle Clients dürfen nur diesen DNS benutzen. Bei Anfragen nach draußen ist es dann halt eine Frage der Konfiguration, ob eine nicht beantwortete Anfrage einen Dial-out auslöst. Das Problem hatte ich auch, und es war Ruhe, nachdem ich meine gesamte /etc/hosts in bind9 importiert hatte. Mein Favorit in kleinen LANs, bei denen der DNS des Providers nach der Einwahl mitbenutzt wird, ist dnsmasq. apt-cache show dnsmasq gibt dir weitere Infos. Oder halt bind, ist IMHO aber meistens Overkill. Also wenn Du ein volles /24 hast würde ich bind9 empfehlen :-) Danke, Ralf Gruß Gerhard Greetings Michelle -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
