Am Mittwoch 15 September 2004 21:35 schrieb Werner Mahr:
> Am Mittwoch, 15. September 2004 21:13 schrieb Matthias Houdek:
> > > #Variable f�r eMule auf Werner1
> > > Werner1_EMULEPORT=4662 #eMule TCP PORT
> > > Werner1_EMULEUDP2=`expr $EMULEPORT + 3` #eMule PORTs f�r Transfers
> >
> > Error: $EMULEPORT nicht definiert.
>
> Nat�rlich $Werner1_EMULEPORT
>
> > Mal davon abgesehen, dass deine Variablennamen nicht vollst�ndig sind
> > (du musst auch keine Variablen verwenden, nur die Portnummern ist
> > wesentlich k�rzer - zumindest bei dir):
>
> Sorry, nano schneidet den Rest halt weg, hab ich garnicht drauf
> geachtet. Schei� c&p. Die Variablen brauche ich nur zur besseren
> �bersicht, die Namen sind ein bisschen lang, aber an den paar Byte
> sollte es nicht liegen.
>
> > 1. Da oben steht: -A PREROUTING, also muss danach ja noch irgend
> > etwas kommen. (Stichwort: FORWARD)
>
> Nach dem Rest der Variablen folgt noch -j DNAT --to-destination mit den
> entsprechenden Host:Port-Variablen.
Das beantwortet Punkt 2 bei mir. Eine Forward-Regel braucht es trotzdem.
Au�erdem muss der Kernel prinzipiell Forwarding f�r die betreffenden
Interfaces eingeschaltet haben.
> > 2. Sind drei tolle Regeln (Bedingungen) da oben, aber sie machen nix.
>
> Die
...?
(Leg dir mal einen besseren Editor zu ;-)
> > 3. Kommunikation besteht immer aus Hin- und R�ckrichtung des
> > Datenflusses.
>
> Sollte der nicht vom NAT gemanaged werden? Ich hatte das eigentlich so
> verstanden, das die related Verbindungen (in dem Fall der R�ckkanal)
> keiner separaten Regeln bedarf.
Naja, die Pakete sollten schon explizit geforwardet werden, denn ich nehme
mal an, dass die Default-Policies f�r INPUT, OUTPUT und FORWARD bei dir
uf das hier �bliche DENY verweisen werden. Die R�ck�bersetzung der
Adressen erfolgt automatisch entsprechend deiner nat-Tabelle.
> > Mein Tipp: Literaturstudium (Grundlagen) - Wie werden IP-Pakete
> > Transportiert? Was ist Routing? Wie funktioniert IPTables
> > (Grundprinzip)?
>
> Grundlagen und Grundprinzip versuch ich ja gerade hinzukriegen, der
> Rest ist eigentlich soweit klar.
>
> Haben die Policies jetzt Einfluss darauf?
Na sicher doch, daf�r sind sie da:
INPUT: alle f�r das System selbst eingehende Pakete
OUTPUT: alle vom System selbst versendete Pakete
FORWARD: alle eingehenden Pakete, die geroutet werden
Au�erdem - du machst das Ganze doch sicher nur f�r ein LAN (mit
RFC1918-Adressen) ins Netzwerk. Warum leitest du dann nicht einfach an
MASQUERADING weiter (an Stelle von DNAT, denn das ist ja hier v�llig
flasch)?
--
Gru�
MaxX
Hinweis: PMs an diese Adresse werden automatisch vernichtet (Filter
nach /dev/null).
