• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

Wie am besten bei t-online reconnecten nach 24 Stunden

framp

Moderator
Teammitglied
Hi,

t-online schmeisst einen leider immer nach 24 Stunden raus. Hat jemand einen guten Tip wie ich am besten automatisch reconnecten kann und dabei auch meine momentan aktuellen fwrules incl zusaetzlicher netfilter settings (iptables) wieder herstellen kann? Da gibt es zwar save- und restore-iptables aber leider hat sich beim reconnect ja auch die externe IP Adresse geaendert :cry:
 
OP
framp

framp

Moderator
Teammitglied
Bin ich wirklich der Einzige, der das Problem hat? Bei n t-online Benutzern und (n-$MSNutzern) = LinuxNutzern?
 

oc2pus

Ultimate Guru
Du könntest über einen cronjob selbst jeden Tag um 23:59 oder so die
Verbindung trennen und um 00:01 wieder aufbauen.

Wofür brauchst du das ?
Normalerweise erledigt dial-on-demand das Problem, die Einwahlzeiten sind doch so verschwindend klein, das merkst du doch gar nicht.
 
OP
framp

framp

Moderator
Teammitglied
oc2pus schrieb:
Normalerweise erledigt dial-on-demand das Problem, die Einwahlzeiten sind doch so verschwindend klein, das merkst du doch gar nicht.
Sorry, was ist dial-on-demand?

Mit cron jedesmal eine Connetion bewusst zu einem bestimmten Zeitpunkt unterbrechen und wiederzuaufbauen ist durchaus eine Moeglichkeit. Allerdings moechte ich die Unterbrechungen minimieren, d.h. wenn um 23:59 die Internetconnection aufgebaut wurde moechte ich sie nicht eine Minute wieder herunterreissen - zumal sich hinter den Connection ein Subnetz befindet mit aktiven Connections.

Ausserdem habe ich den susefirewall2 aktiv mit zusaetzlichen iptables rules (susefireall-custom). Ich kann zwar beim runterfahren der Connection die rules mit iptables-save sichern und nach dem restart wieder aktivieren - nur stimmt dann meine exteren IP nicht mehr ;-), d.h. da ist ein Preprocessing der durch iptables-save gesicherten rules notwendig.
 

oc2pus

Ultimate Guru
dial-on demand bedeutet, immer dann wenn ein internet-Zugriff erfolgt wird eingewählt. Wenn nix mehr los ist, wird nach der eingestellten idle-time aufgelegt.

/etc/sysconfig/network/dsl-provider0
Code:
PROVIDER="DSL provider"
DSLSUPPORTED="yes"
MODEMSUPPORTED="no"
ISDNSUPPORTED="no"
USERNAME="ich"
PASSWORD="meinPass"
IDLETIME="600"
DEMAND="yes"
DNS1="der dns 1 vom provider"
DNS2="der dns 2 vom provider"

Ich bin damit rund um die Uhr online, nach 24 Stunden wird kurz aufgelegt, und dann weil ja aktive Sitzungen vorhanden sind wieder eingewählt.
Wenn niemand zuhause ist, und keine downloads laufen, wird halt aufgelegt. Der erste der eine HTTP,FTP, sonst was Sitzung aufmacht triggert die neueinwahl an.
Der Router sorgt bei Zwangsauflegen nach 24 Stunden für das entsprechende Umsetzen der aktiven Verbindungen. Wo ist das Problem.
Mal ganz davon abgesehen davon: eine flatrate ist KEINE Standleitung ;)
 
OP
framp

framp

Moderator
Teammitglied
Das ist zwar sehr praktisch - aber ich habe es so eingerichtet, dass jeder Rechner im lokalen Netz explizit erst seine Internetverbindung iptablesmaessig enablen muss bzw dann erst die eigentliche Verbindung aufgebaut wird.
Ich moechte nicht, dass ein xyz-ad-programm oder $MSProgramm o.ae. schon beim starten eines Clients eine Netzwerkverbindung aufbaut.
D.h. meine Clients muessen sich erst zum Router via ssh connecten und mit einem shell-script sagen, dass sie online gehen wollen. Funktioniert auch sehr gut. Nur gibt es ein paar Clients, die sind recht lange online und fluchen, wenn die Verbindung nach 24 h unterbrochen wird.
 

oc2pus

Ultimate Guru
wenn du so eine Lösung bevorzugts, dann wird dir nix anderes übrig bleiben als etwas selbst zu stricken (perl, bash, ...)

Wozu soll das gut sein sich erst am Server via ssh zu legitimieren, damit man online gehen kann? Um sicherzustellen, das kein Fremder PC-surft ?
Das kannst du doch auch im Firewall via MAC-Adressen regeln, selbst für wlan.
 
OP
framp

framp

Moderator
Teammitglied
oc2pus schrieb:
Wozu soll das gut sein sich erst am Server via ssh zu legitimieren, damit man online gehen kann? Um sicherzustellen, das kein Fremder PC-surft ?
Das kannst du doch auch im Firewall via MAC-Adressen regeln, selbst für wlan.
Wie ich oben schon gesagt habe, mittlerweile bauen alle moeglichen Programme Verbindungen auf und um das unter Kontrolle zu haben muss jeder Client seine Verbindung explizit aufbauen. Sicherheit ist nicht der Grund, denn mein WLAN haengt an einem dedizierten Port und ist per Rules geschuetzt.
Na klar kann ich mir das selbst zusammenbauen - aber warum nicht Wissensreuse betreiben? Ich bin ja noch immer zuversichtlich da was Existierendes zu finden :)
 

oc2pus

Ultimate Guru
diesen unkontrollierten Verbindungsaufbau bekommst du doch recht einfach in den Griff;

Das regelt jeder gute Firewall. Im SuSE SDB ist da sogar ein Artikel für die "armen" nicht DSL Flatrate Besitzer welche diese Einwahlen zahlen müssten.
 
OP
framp

framp

Moderator
Teammitglied
oc2pus schrieb:
... Im SuSE SDB ist da sogar ein Artikel für die "armen" nicht DSL Flatrate Besitzer welche diese Einwahlen zahlen müssten.
Welches keyword hast Du benutzt? Ich habe alles moeglichen Dinge gefunden - aber leider nicht den von Dir genannten Artikel :oops:
 

oc2pus

Ultimate Guru
auch Suchen will gelernt sein ;)

Verbindungsaufbau - war das Zauberwort

hier der Link
https://portal.suse.com/sdb/de/1997/03/isdn_dial.html
https://portal.suse.com/sdb/de/1998/04/ray_netscape.html
 
OP
framp

framp

Moderator
Teammitglied
Danke, aber beide Eintraege hatte ich auch gefunden :lol:. Nur hatte ich iptables templates erwartet :roll:

Ich denke die sicherste Methode ist immer noch fuer ein System kontrolliert den Zugriff zum und insbesondere vom Internet explizit einzuschalten. Wenn man bestimmte Ports per default aufmacht koennen AdWare, MS$ et al durch intelligente Programmierung diese offenen Ports finden und i.d.R. auch nutzen.
 

oc2pus

Ultimate Guru
framp schrieb:
Danke, aber beide Eintraege hatte ich auch gefunden :lol:. Nur hatte ich iptables templates erwartet :roll:

Ich denke die sicherste Methode ist immer noch fuer ein System kontrolliert den Zugriff zum und insbesondere vom Internet explizit einzuschalten. Wenn man bestimmte Ports per default aufmacht koennen AdWare, MS$ et al durch intelligente Programmierung diese offenen Ports finden und i.d.R. auch nutzen.

Falsch, gar kein Internet Zugriff ist viel sicherer.

Aber ich kann deinem Problem wirklich nicht folgen. Wo ist der Unterschied ob eine Verbindung on-demand aufgebaut wird oder erst via ssh beantragt wird ?
Ausnahme: der eigene Firewall taugt nix, bzw ist fehlerhaft konfiguriert;) oder bei Nicht-Flatrate, aber da muß eben noch mehr Sorgfalt beim Firewall aufgewandt werden.

Es ist ganz locker möglich eine iptables Firewall so zu konfigurieren, das der Traffic von außen "optimal" kontrolliert ist. Ob SuSEFirewall 2 da state of the Art ist, kann ich nicht beurteilen ich verwende einen anderen Firewall (shorewall). Und das mit der AdWare, kannst du sowieso nur auf dem Client abwehren, dein Firewall sieht das als HTTP Traffic.
Wenn es dir um P2P geht, den kann man portunabhängig mit Layer7 Tools abblocken bzw so runterregeln, das er nicht den normalen Traffic behindert. Auch hier kenne ich mehrere sicher funktionierende Verfahren.
Bei email-Servern kannst du die Sicherheit ziemlich einfach mit integrierten SPAM und Virenscannern gewährleisten.

Meine Netzwerkmember würden mich zum Teufel jagen, wenn iich denen käme mit extra Anmeldung und so;)
 
OP
framp

framp

Moderator
Teammitglied
oc2pus schrieb:
Falsch, gar kein Internet Zugriff ist viel sicherer.
Das Bild mit einem sicheren FW, in welchen ein Kabel links reingeht und rechts rausgeht und nach oeffnen der Box zu sehen ist, dass die Kabel nicht miteinander verbunden sind ist mir bekannt. ;-)

oc2pus schrieb:
Aber ich kann deinem Problem wirklich nicht folgen. Wo ist der Unterschied ob eine Verbindung on-demand aufgebaut wird oder erst via ssh beantragt wird ?
Hm, vielleicht hast Du Recht. Das ist eigentlich historisch gewachsen und wurde frueher u.A. als Regelwerkzeugt benutzt (Limitierung der Onlinezeit und des Onlinezeitraums der Clients via diverser Scripts). Das trifft nicht mehr zu.

oc2pus schrieb:
Wenn es dir um P2P geht, den kann man portunabhängig mit Layer7 Tools abblocken bzw so runterregeln, das er nicht den normalen Traffic behindert. Auch hier kenne ich mehrere sicher funktionierende Verfahren.
Ich habe den wshaper, der leider nur in gewissen Grenzen funktioniert. Gibt's da Besseres?

Wenn ich zu ondemand gehe vereinfacht sich die ganze Sache schon sehr und ein cron gesteuerter restart ist schon eine Moeglichkeit. Werde das mal ausprobieren.
 

oc2pus

Ultimate Guru
ad p2p:
wshaper ist ein traffic-regler

wenn du p2p blocken oder stark limitieren willst solltest du dir diesen link anschauen:
http://rnvs.informatik.uni-leipzig.de/ipp2p/index.html
das ist recht einfach zu installieren und funktioniert prima ;))

es gibt auch fertige shaper die genau dieses Modul einsetzen:
http://www.digriz.org.uk/jdg-qos-script/
(das nehme ich auch, braucht aber diverse kernel-patches, ist aber sehr gut dokumentiert und der Author ist hilfsbereit bei Fragen)

und
http://www.metamorpher.de/fairnat/
(braucht kein IMQ, evtl einfacher, noch nicht probiert, der Author ist ebenfalls sehr net und will noch einiges verändern, derzeit behakt sich das ohne Modifikation mit firewalls)

als firewall nehme ich shorewall
www.shorewall.net,
dafür gibt es auch eine webmin-GUI.

dazu noch psad als Port-Scanner-Überwachung mit dynamischer iptables generierung ;)
http://www.cipherdyne.com/psad/
leider kein rpm, aber sehr einfach zu installieren und konfigurieren


ad on-demand:
das mappt auch bei neu-einwahl die aktiven Verbindungen um, meine kleinen Powerdownloader haben jedenfalls noch nie gemeckert ;)
 
OP
framp

framp

Moderator
Teammitglied
Thx. Da habe ich ja das Wochendende was zu tun ;-)

oc2pus schrieb:
ad on-demand:
das mappt auch bei neu-einwahl die aktiven Verbindungen um, meine kleinen Powerdownloader haben jedenfalls noch nie gemeckert ;)

D.h. beim cron reconnect wie auch automatischem reconnect bleiben existierende Sessions erhalten? Aber die extrene IP hat sich doch geaendert und ein anderer dynIP Nutzer erhaelt alle Sessionrequests. Somit koennen doah nur die von innen aufgebauten Sessions ueberleben, der von aussen ist gone, oder?
 

jl

Newbie
ich hatte das selbe problem, da ich mit meinem computer emails empfange. cron kam bei mir nicht in frage, weil die verbindung zu unterschiedlichen zeiten getrennt wird.
hier ein script das ich aus einem anderen forum hab(weiß leider nicht mehr woher :roll: )
bei mir funzts einwandfrei, allerdings hab ich keinen router.
in der zeile wo ddclient.... steht könnte man die firewall neustarten, sofern das notwendig ist.
hab noch ne datei mit dem inhalt

#/bin/bash
/root/scripts/stayconnected.pl > /jl/connects

erstellt und mit insserv installiert, jetzt bin ich immer online wenn ich den rechner hochgefahren hab und dann erst wieder offline wenn er aus is :D

#!/usr/bin/perl -w
#
# stayconnected.pl
#
sub t { return scalar localtime time; }

my $wait = 5; # alle 5 sekunden
my $connecting = 1;

print t." started\n";
while (1) {
$status = `cinternet -i dsl0 --status`;
$status =~ /status: (.*)\n/;
$status = $1;
if ($status eq "disconnected") {
print t." connection lost\n";
sleep 1;
print t." reconnect\n";
`cinternet -i dsl0 --start`;
$connecting = 1;
} elsif ($status eq "connecting") {
if (!$connecting) {
print t." connecting\n";
$connecting = 1;
}
} elsif ($status eq "connected") {
if ($connecting) {
print t." connection established\n";
$connecting = 0;
print t." dyndns update\n";
`ddclient -daemon=0 -quiet -force`;
print t." ready\n";
}
}
sleep $wait;
}
exec $0;
exit;

Ich hoffe das hilft ein paar von euch weiter, ich weiß halt nicht wie man das mit nem router realisieren könnte, weil ich keinen hab....
 

oc2pus

Ultimate Guru
framp schrieb:
Thx. Da habe ich ja das Wochendende was zu tun ;-)

oc2pus schrieb:
ad on-demand:
das mappt auch bei neu-einwahl die aktiven Verbindungen um, meine kleinen Powerdownloader haben jedenfalls noch nie gemeckert ;)

D.h. beim cron reconnect wie auch automatischem reconnect bleiben existierende Sessions erhalten? Aber die extrene IP hat sich doch geaendert und ein anderer dynIP Nutzer erhaelt alle Sessionrequests. Somit koennen doah nur die von innen aufgebauten Sessions ueberleben, der von aussen ist gone, oder?

yepp :)
Code:
Jul 16 12:23:13 snake pppd[30942]: LCP terminated by peer
Jul 16 12:23:13 snake pppd[30942]: Setting MTU to 1492.
Jul 16 12:23:13 snake pppd[30942]: Couldn't increase MRU to 1500
Jul 16 12:23:15 snake pppd[30942]: Script /etc/ppp/ip-down finished (pid 7487), status = 0x0
Jul 16 12:23:15 snake pppd[30942]: Connection terminated.
Jul 16 12:23:15 snake pppd[30942]: Connect time 1440.8 minutes.
Jul 16 12:23:15 snake pppd[30942]: Sent 3913312769 bytes, received 2483226990 bytes.
Jul 16 12:23:15 snake pppd[30942]: Doing disconnect
Jul 16 12:23:46 snake pppd[30942]: Starting link
Jul 16 12:23:46 snake pppd[30942]: Sending PADI
Jul 16 12:23:46 snake pppd[30942]: HOST_UNIQ successful match
Jul 16 12:23:46 snake pppd[30942]: HOST_UNIQ successful match
Jul 16 12:23:46 snake pppd[30942]: Got connection: e48
Jul 16 12:23:46 snake pppd[30942]: Connecting PPPoE socket: 00:90:1a:40:aa:1a 480e eth0 0x8089af0
Jul 16 12:23:46 snake pppd[30942]: Connect: ppp0 <--> eth0
Jul 16 12:23:46 snake pppd[30942]: Setting MTU to 1492.
Jul 16 12:23:46 snake pppd[30942]: Couldn't increase MRU to 1500
Jul 16 12:23:49 snake pppd[30942]: Setting MTU to 1492.
Jul 16 12:23:49 snake pppd[30942]: Local IP address changed to 82.83.147.251
Jul 16 12:23:50 snake pppd[30942]: Open TCP 82.83.147.251:33372 -> 80.139.166.172:6881
Jul 16 12:23:52 snake modify_resolvconf: Service pppd modified /etc/resolv.conf. See info block in this file
Jul 16 12:23:52 snake pppd[30942]: Script /etc/ppp/ip-up finished (pid 7577), status = 0x0
Jul 16 12:23:54 snake modify_resolvconf: kept /etc/resolv.conf and changed info block

Open TCP 82.83.147.251:33372 -> 80.139.166.172:6881
das ist so eine gemappte outgoing-connection (BitTorrent)
 
Oben