Über uns
Know-how
FAQ
Projektverlauf
Technikbereich
Ip-Vergabe
Organisation / Termine
Community
Forum
Karte
Gästebuch
Partner
Sonstiges
Downloads
Gallery
Spenden-Topf
Forum Startseite Wiki Karte Forum
WLanhsh & WLanwse Foren-Übersicht WLanhsh & WLanwse
Forum des WLan Hohenschönhausen und des WLan Weißensee
wlanhsh.freifunk.net
 
 FAQFAQ   SuchenSuchen   MitgliederlisteMitgliederliste   BenutzergruppenBenutzergruppen   RegistrierenRegistrieren 
 ProfilProfil   Einloggen, um private Nachrichten zu lesenEinloggen, um private Nachrichten zu lesen   LoginLogin 

IPP2P
Gehe zu Seite Zurück  1, 2
 
Dieses Forum ist gesperrt, du kannst keine Beiträge editieren, schreiben oder beantworten.   Dieses Thema ist gesperrt, du kannst keine Beiträge editieren oder beantworten.    WLanhsh & WLanwse Foren-Übersicht -> Selfmade Server
Vorheriges Thema anzeigen :: Nächstes Thema anzeigen  
Autor Nachricht
tm-107



Anmeldedatum: 24.03.2005
Beiträge: 1130
Wohnort: Panketal - OT Schwanebeck

BeitragVerfasst am: 04.06.2006, 13:02    Titel: Antworten mit Zitat

Hallo nochmal,

wenn ich in der Konfig-Datei IPP2P_AUTOBLOCK='yes' setze, dann wird zwar wieder alles geblockt (auch mein privates LAN), aber dafür kann ich mich per WLan auch nicht mehr connecten. Nun sieht der Screenshot so aus:



Es muss also irgendwo in der Syntax liegen. Kann es evtl an der 4. Zeile in meinem Screenshot liegen?
UPDATE: Ja, es liegt an dieser Zeile. Wenn die erste Regel nicht existiert, werden hier Verbindungen erlaubt bevor sie von IPP2P gefiltert werden können.

Ich benötige leider eine Verbindung mit einem speziellen edk-Clienten (AkteMule falls es jemandem was sagt), sonst wäre mir das ganze relativ egal.

Eine andere Lösung wäre das ganze auf den WRT zu installieren. Das soll ja ab FFF 1.3 im Gateway-Plugin drin sein. Ich weiss nur nicht ob da nur die Standardports geblockt werden oder ein Paketfilter wie IPP2P eingesetzt wird.

gruss
tm-107

PS: Dem genauen Betrachter wird ein Unterschied in der Zuordnung der IP-Netze aufgefallen sein:
Das .107.x-Netz ist weiterhin mein privates LAN
Das .108.x-Netz ist weiterhin das Netz in dem der WRT hängt
Das .109.x-Netz ist jetzt mein privates WLan (ehemals .1.x)


Zuletzt bearbeitet von tm-107 am 05.06.2006, 18:40, insgesamt 2-mal bearbeitet
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden Website dieses Benutzers besuchen
gockelhahn



Anmeldedatum: 07.12.2005
Beiträge: 184
Wohnort: Berliner Allee / Smetanastraße (104.13.13.13)

BeitragVerfasst am: 04.06.2006, 14:27    Titel: Antworten mit Zitat

im neuen gateway plugin für fff 1.3 soll wohl ein ipp2p modul enthalten sein

Marek Lindner hat Folgendes geschrieben:
Hi,

die neue Version des Gateway-Plugins hat nun das Teststadium erreicht.
Folgende Neuerungen könnt ihr erwarten:

* P2P-Filter über ipp2p iptables Modul. Es analysiert den
durchgehenden Traffic auf P2P-Kommandos und blockt dann die
entsprechenden Verbindungen. Folgende P2P-Protokolle werden
erkannt: eDonkey, eMule, Kademlia, KaZaA, FastTrack, Gnutella,
Direct Connect, BitTorrent, extended BT, AppleJuice, WinMX,
SoulSeek, Ares, AresLite. Mehr Infos unter: http://www.ipp2p.org/ .
* WebUI hat ein Facelifting bekommen (danke an die vielen Hinweisgeber).
* Das Laden der Whitelist wurde verbessert, um die Performance zu
steigern (Anregungen von Stefan Pirwitz und MM).
* Alle Seiten sind nun übersetzt (Dank an Wulf).
* Viele Bugfixes. Winken

quelle
_________________
jabber: gockelhahn @ dernico.no-ip.org
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
tm-107



Anmeldedatum: 24.03.2005
Beiträge: 1130
Wohnort: Panketal - OT Schwanebeck

BeitragVerfasst am: 05.06.2006, 15:19    Titel: Antworten mit Zitat

Na dann könnten sich einige meiner Probleme ja von selbst lösen ... jetzt muss ich den Filter nur noch für mein privates WLan einrichten.

gruss
tm-107
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden Website dieses Benutzers besuchen
tm-107



Anmeldedatum: 24.03.2005
Beiträge: 1130
Wohnort: Panketal - OT Schwanebeck

BeitragVerfasst am: 05.06.2006, 18:35    Titel: Antworten mit Zitat

Sooo,

jetzt habe ich es endlich hinbekommen!!! Gefiltert werden jetzt nur noch die Verbindungen ins OLSR-Netz und mein privates WLan. Derzeit versucht mein Notebook seit über 30 min eine Verbindung zum edk-Netz aufzubauen ...

Nach unzähligen Versuchen habe ich mich wieder für die unfeine Methode entschieden und in den Startscripten des OPT_IPP2P rumgefummelt.

Aus
Code:
    /usr/local/bin/colecho "Auto-Blocking common known P2P Traffic"
    iptables -I FORWARD  -m ipp2p --ipp2p -j DROP

wurde jetzt
Code:
    /usr/local/bin/colecho "Auto-Blocking common known P2P Traffic"
    iptables -I FORWARD -p tcp -s 192.168.109.0/24 -m ipp2p --ares -j DROP
    iptables -I FORWARD -p tcp -s 192.168.109.0/24 -m ipp2p --soul -j DROP
    iptables -I FORWARD -p tcp -s 192.168.109.0/24 -m ipp2p --soul -j DROP
    iptables -I FORWARD -p tcp -s 192.168.109.0/24 -m ipp2p --apple -j DROP
    iptables -I FORWARD -p tcp -s 192.168.109.0/24 -m ipp2p --winmx -j DROP
    iptables -I FORWARD -s 192.168.109.0/24 -m ipp2p --bit -j DROP
    iptables -I FORWARD -s 192.168.109.0/24 -m ipp2p --gnu -j DROP
    iptables -I FORWARD -s 192.168.109.0/24 -m ipp2p --gnu -j DROP
    iptables -I FORWARD -s 192.168.109.0/24 -m ipp2p --kazaa -j DROP
    iptables -I FORWARD -s 192.168.109.0/24 -m ipp2p --edk -j DROP
    iptables -I FORWARD -p tcp -s 192.168.108.0/24 -m ipp2p --ares -j DROP
    iptables -I FORWARD -p tcp -s 192.168.108.0/24 -m ipp2p --soul -j DROP
    iptables -I FORWARD -p tcp -s 192.168.108.0/24 -m ipp2p --apple -j DROP
    iptables -I FORWARD -p tcp -s 192.168.108.0/24 -m ipp2p --winmx -j DROP
    iptables -I FORWARD -s 192.168.108.0/24 -m ipp2p --bit -j DROP
    iptables -I FORWARD -s 192.168.108.0/24 -m ipp2p --gnu -j DROP
    iptables -I FORWARD -s 192.168.108.0/24 -m ipp2p --kazaa -j DROP
    iptables -I FORWARD -s 192.168.108.0/24 -m ipp2p --edk -j DROP


Falls jetzt jemand fragt warum ich die Reihenfolge umgedreht habe ... damit im Webinterface wieder die richtige Reihenfolge entsteht. Die Befehle werden immer vorne angestellt.

Damit sieht der Screenshot dann folgendermassen aus:



So langsam wird mein Fli4l immer mehr zu dem was ich mir vorgestellt habe. Jetzt müsste das BIOS nur noch eine 2te 80GB-HDD akzeptieren ... aber das ist ein anderes Thema Winken

gruss
tm-107
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden Website dieses Benutzers besuchen
wusel



Anmeldedatum: 28.05.2006
Beiträge: 43

BeitragVerfasst am: 06.06.2006, 08:25    Titel: Antworten mit Zitat

Na super. Hätte mich auch gewundert, wenn es nicht geht. Da hast Du also in dem Paket einen Fehler entdeckt. Werde ich dann bei meinem berücksichtigen, wenn ich ipp2p einbaue.

Uli
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
glockman



Anmeldedatum: 21.09.2004
Beiträge: 2097
Wohnort: suermondtstr/degnerstr ... ohne AP

BeitragVerfasst am: 06.06.2006, 11:12    Titel: Antworten mit Zitat

ahauaha ... was haste da gemacht??

Code:
iptables -A FORWARD -s 192.168.108.0/24 -p tcp -m ipp2p --ipp2p -j DROP
iptables -A FORWARD -s 192.168.109.0/24 -p tcp -m ipp2p --ipp2p -j DROP


reicht vollkommen aus ... ich würde die filterung auf tcp beschränken, weil ipp2p auf udp-pakete eine heftiges overmatching, gerade bei voip, erzeugt ... deswegen "-p tcp" ... wenn du das in kauf nehmen möchtest, dann lass es weg ... könnte den gefilterten aber probleme beim onlinezocken und viop-telefonieren bereiten.

das "-m ipp2p --ipp2p" deckt alle netzwerke ab, die ipp2p zuverlässig unterstützt ... die einzelnen netzwerke müssen nicht extra angegeben werden .. und wenn, dann in einer zeile:

Code:
iptables -I FORWARD -p tcp -s 192.168.109.0/24 -m ipp2p --ares --apple --winmx -j DROP
iptables -I FORWARD -s 192.168.109.0/24 -m ipp2p --bit --gnu --kazaa --ed2k -j DROP

das sieht sauberer aus und senkt die benötigte rechenzeit ...
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
wusel



Anmeldedatum: 28.05.2006
Beiträge: 43

BeitragVerfasst am: 06.06.2006, 20:03    Titel: Antworten mit Zitat

Wenn ich tm-107 richtig verstanden habe, dann braucht er ja einen dieser Dienste und kann daher nicht alle mit einem Befehl erschlagen.

Bin mir auch nicht sicher, ob man wirklich auf UDP verzichten kann.
Hinweise darauf habe ich gefunden unter:

http://www.gulli.com/filesharing/programme/emule/

Muss man die Protokolle noch mal genauer unter die Lupe nehmen.

Vielleicht kann ich mal mit Ethereal tracen.

Vielleicht reicht ja wirklich nur TCP zu filtern, wenn immer wichtige Nachrichten dabei sind, die nur mit TCP übertragen werden. Wie gesagt, muss man untersuchen.

Uli
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
tm-107



Anmeldedatum: 24.03.2005
Beiträge: 1130
Wohnort: Panketal - OT Schwanebeck

BeitragVerfasst am: 06.06.2006, 21:56    Titel: Antworten mit Zitat

Hi,

also der Standardbefehl --ipp2p deckt nur 3 p2p-Protokolle ab (edonkey, kazaa, gnutella). Alle anderen werden in dem Paket immer extra gefiltert.
Die einzelne Auflistung habe ich aus rein informatorischen Gründen gewählt ... so kann ich sehen mit welchen Clienten es versucht wurde. Meinst Du das macht solche Probleme?

Die von mir verwendete Syntax (inkl. UDP-Filterung) habe ich an anderer Stelle in dem Paket in genau dieser Form gefunden (nur halt ohne Source-Angabe), also dachte ich mir das passt schon:
Code:
    /usr/local/bin/colecho "Auto-Blocking ALL known P2P Traffic"
    iptables -I FORWARD -m ipp2p --ipp2p -j DROP
    iptables -I FORWARD -m ipp2p --bit -j DROP
    iptables -I FORWARD -p tcp -m ipp2p --winmx -j DROP
    iptables -I FORWARD -p tcp -m ipp2p --apple -j DROP
    iptables -I FORWARD -p tcp -m ipp2p --soul -j DROP
    iptables -I FORWARD -p tcp -m ipp2p --ares -j DROP


Die UDP-Filterung soll ja wohl nur bei den Beta-Protokollen Probleme bereiten ... bei den 4 wichtigen funktioniert es laut IPP2P-Homepage ja recht zuverlässig.

Nebenbei bemerkt: VoIP funktioniert ohne Probleme über meinen WRT ...

@wusel: Ich habe derzeit alle Netze "erschlagen", aber halt nicht in meinem LAN ... dort ist alles erlaubt.

gruss
tm-107
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden Website dieses Benutzers besuchen
wusel



Anmeldedatum: 28.05.2006
Beiträge: 43

BeitragVerfasst am: 06.06.2006, 23:09    Titel: Antworten mit Zitat

Habe nochmal auf der Webside von IPP2P nachgeschaut.

Wenn man der Beschreibung dort folgt dann sind die Regeln von tm-107 OK.

Allerdings steht dort noch, dass "Direct Connect" von der Standard- Option mit abgedeckt wird.

Habe bei mir auch nochmal meine Einstellungen von

IPP2P_AUTOBLOCK = yes

auf

IPP2P_AUTOBLOCK = all

geändert und siehe da die benötigten Regeln landen alle vor dem Rest und das ganz ohne Modifikation des Standard- Paketes.

So sieht dann meine "Forward- chain" aus:

Code:
Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           ipp2p v0.8.0 --ares
    0     0 DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           ipp2p v0.8.0 --soul
    0     0 DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           ipp2p v0.8.0 --apple
    0     0 DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           ipp2p v0.8.0 --winmx
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           ipp2p v0.8.0 --bit
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           ipp2p v0.8.0 --ipp2p
 1103  642K accin      all  --  *      *       0.0.0.0/0            0.0.0.0/0
 1103  642K accout     all  --  *      *       0.0.0.0/0            0.0.0.0/0
   25  1500 TCPMSS     tcp  --  *      ppp0    0.0.0.0/0            0.0.0.0/0           tcp flags:0x06/0x02 TCPMSS clamp to PMTU
 1078  640K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED /* FORWARD_ACCEPT_DEF */
    0     0 DROP       all  --  *      *       127.0.0.1            0.0.0.0/0           state NEW /* FORWARD_ACCEPT_DEF */
    0     0 DROP       all  --  *      *       0.0.0.0/0            127.0.0.1           state NEW /* FORWARD_ACCEPT_DEF */
   25  1500 PORTFWACCESS  all  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW /* state:NEW PORTFWACCESS */
    0     0 ACCEPT     all  --  *      *       192.168.250.0/24     192.168.252.0/24    /* FORWARD_LIST_1='IP_NET_1 192.168.252.1/24 ACCEPT BIDIRECTIONAL' */
    0     0 ACCEPT     all  --  *      *       192.168.252.0/24     192.168.250.0/24    /* FORWARD_LIST_1='IP_NET_1 192.168.252.1/24 ACCEPT BIDIRECTIONAL' */
    0     0 DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:139 /* FORWARD_LIST_2='tmpl:samba DROP' */
    0     0 DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:445 /* FORWARD_LIST_2='tmpl:samba DROP' */
    0     0 DROP       udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp dpts:137:138 /* FORWARD_LIST_2='tmpl:samba DROP' */
   25  1500 ACCEPT     all  --  *      *       192.168.250.0/24     0.0.0.0/0           /* FORWARD_LIST_3='IP_NET_1 ACCEPT' */
    0     0 fw-rej     tcp  --  *      *       104.0.0.0/8          104.15.15.15        tcp dpt:81 /* FORWARD_LIST_4='IP_NET_2 IP_NET_2_IPADDR:81 REJECT' */
    0     0 fw-rej     udp  --  *      *       104.0.0.0/8          104.15.15.15        udp dpt:81 /* FORWARD_LIST_4='IP_NET_2 IP_NET_2_IPADDR:81 REJECT' */
    0     0 fw-rej     tcp  --  *      *       104.0.0.0/8          104.15.15.15        tcp dpt:5000 /* FORWARD_LIST_5='IP_NET_2 IP_NET_2_IPADDR:5000 REJECT' */
    0     0 fw-rej     udp  --  *      *       104.0.0.0/8          104.15.15.15        udp dpt:5000 /* FORWARD_LIST_5='IP_NET_2 IP_NET_2_IPADDR:5000 REJECT' */
    0     0 fw-rej     tcp  --  *      *       104.0.0.0/8          104.15.15.15        tcp dpt:5001 /* FORWARD_LIST_6='IP_NET_2 IP_NET_2_IPADDR:5001 REJECT' */
    0     0 fw-rej     udp  --  *      *       104.0.0.0/8          104.15.15.15        udp dpt:5001 /* FORWARD_LIST_6='IP_NET_2 IP_NET_2_IPADDR:5001 REJECT' */
    0     0 fw-rej     tcp  --  *      *       104.0.0.0/8          104.15.15.15        tcp dpt:22 /* FORWARD_LIST_7='IP_NET_2 IP_NET_2_IPADDR:22 REJECT' */
    0     0 fw-rej     udp  --  *      *       104.0.0.0/8          104.15.15.15        udp dpt:22 /* FORWARD_LIST_7='IP_NET_2 IP_NET_2_IPADDR:22 REJECT' */
    0     0 ACCEPT     all  --  *      *       104.0.0.0/8          104.0.0.0/8         /* FORWARD_LIST_8='IP_NET_2 IP_NET_2 ACCEPT' */



Da ist auch alles schön dicht. Aber in dem Standardpaket eben an allen Interfaces.

Das FLI4L- Paket setzt die Regeln auch nicht zusammen. Das Zusammensetzen macht sicher Sinn.

Uli
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
glockman



Anmeldedatum: 21.09.2004
Beiträge: 2097
Wohnort: suermondtstr/degnerstr ... ohne AP

BeitragVerfasst am: 06.06.2006, 23:44    Titel: Antworten mit Zitat

wenn man die benutzung der eizelnen netzwerke accounten will, macht das natürlich sinn ... wenn du in der richtung keine probleme hast, dann lass es so ...

aber das filtern von udp macht keinen wirklichen sinn ... denn alle resourcenraubenden verbindung laufen auf tcp ab ... lasst den P2P-geilen olsr-knoten doch den gleuben, er hätte sich erfolgreich verbunden ... wenn keine tcp-connection zustandekommt, wird er keinen byte runterladen können ... irgendwann ist er frustiert und gibts auf ... vlt ist er sogar so frustriert, dass er das filesharen sogar freiwillig als unbrauchbar abtut ... wodurch die P2P-netz in zukunft einen schmarotzer weniger haben ...

wegen der unterschiedlichen infos zur option "--ipp2p" ... die seite ist teilweise URALT ... die doku habe ich fast unverändert schon im sommer letzten jahren lesen können ... in der zwischenzeit arbeitet schon nen neuer entwickler dran ...
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
tm-107



Anmeldedatum: 24.03.2005
Beiträge: 1130
Wohnort: Panketal - OT Schwanebeck

BeitragVerfasst am: 07.06.2006, 18:34    Titel: Antworten mit Zitat

Hi,

also DirectConnect habe ich doch glatt vergessen ... *gleich ändern*

Ich möchte aber nicht dass sich jemand zu einem Server verbinden kann, denn dabei werden ja auch seine Freigaben an den Server übermittelt. Und genau ab diesem Punkt befindet man sich juristisch nicht mehr ganz auf legalem Gebiet. Solchen Problemen möchte ich halt einfach von Anfang an aus dem Weg gehen.

gruss
tm-107
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden Website dieses Benutzers besuchen
wusel



Anmeldedatum: 28.05.2006
Beiträge: 43

BeitragVerfasst am: 07.06.2006, 20:31    Titel: Antworten mit Zitat

Wäre da auch noch der Punkt mit den vielen hundert Verbindungen, die die P2P clients beim Connecten erzeugen. Manche Syteme steigen ja auch bei so vielen IP- Verbindungen aus.

Bei FLI4L hab ich das noch nicht gesehen, aber wer weiss...

Uli
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
tm-107



Anmeldedatum: 24.03.2005
Beiträge: 1130
Wohnort: Panketal - OT Schwanebeck

BeitragVerfasst am: 08.06.2006, 19:09    Titel: Antworten mit Zitat

Und schon hat der Filter zugeschlagen Cool



Die jeweiligen Verursacher sind mir mittlerweile jedoch bekannt (war keine böse Absicht) und versicherten mir beide dass kein Verbindungsaufbau möglich war.

Damit sind jetzt drei P2P-Netze definitiv geblockt Sehr glücklich

Trotzdem sollte ich vielleicht doch mal die Zuverlässigkeit der anderen Filter überprüfen. Hatte bisher nur keine Lust mir lauter P2P-Software auf mein Notebook zu packen bzw. kein Bock auf ein Backup Winken

gruss
tm-107

PS:
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden Website dieses Benutzers besuchen
tm-107



Anmeldedatum: 24.03.2005
Beiträge: 1130
Wohnort: Panketal - OT Schwanebeck

BeitragVerfasst am: 16.08.2006, 00:19    Titel: Antworten mit Zitat

Interessante Beobachtung:

Mein Fli4l meldet wiedermal Soulseek-Traffic und fischerbln ist derzeit der einzige User in unserem 2-Personen-Netz auf Kanal 6.
Laut seiner Aussage lief auf dem Rechner zur betreffenden Zeit nur ein Radio-Stream in Winamp. Also scheint IPP2P hier ein paar Pakete falsch zuzuordnen ...

Jetzt ist Winamp abgeschaltet und die Sache wird bis morgen beobachtet. Mal schauen ob sich die Vermutung bestätigt.

gruss
tm-107
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden Website dieses Benutzers besuchen
glockman



Anmeldedatum: 21.09.2004
Beiträge: 2097
Wohnort: suermondtstr/degnerstr ... ohne AP

BeitragVerfasst am: 16.08.2006, 09:20    Titel: Antworten mit Zitat

jaja ... das meinte ich mit overmatching ... bei tcp nicht weiter wild ... wirds halt nochmal gesendet ... aber bei udp ist das fälschlicherweise gedroppte paket einfach wech!
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Beiträge der letzten Zeit anzeigen:   
Dieses Forum ist gesperrt, du kannst keine Beiträge editieren, schreiben oder beantworten.   Dieses Thema ist gesperrt, du kannst keine Beiträge editieren oder beantworten.    WLanhsh & WLanwse Foren-Übersicht -> Selfmade Server Alle Zeiten sind GMT + 2 Stunden
Gehe zu Seite Zurück  1, 2
Seite 2 von 2

 
Gehe zu:  
Du kannst keine Beiträge in dieses Forum schreiben.
Du kannst auf Beiträge in diesem Forum nicht antworten.
Du kannst deine Beiträge in diesem Forum nicht bearbeiten.
Du kannst deine Beiträge in diesem Forum nicht löschen.
Du kannst an Umfragen in diesem Forum nicht mitmachen.


Powered by phpBB © 2001, 2005 phpBB Group
Deutsche Übersetzung von phpBB.de