Roberto
only today, after my LVS is runnign so nicely, I have been looking at
setting up
ftp-proxy again on the director.
In your mail of 8 May you quote some of your ipchains rules.
You you please explain all variables you have in your sell script,
below, e.g.
$chain
$LOGIN
$SRCDEV
$SRC
$SRCPORTS
$DST
$DSTDEV
$DSTIF
$LOGFWD
$LOG
I know I could try to find out by trial and error, but my LVS is now
an active production machine at a remote location (colocated in a
cybercenter)
and I am somewhat reluctant to play with ipchains for experiments, if
it
can be avoided. The danger is that I lock myself out (because I
connect from
outside to the director) or that I inhibit normal LVS usage if I make
errors
with new ipchains scripts.
Alois
Roberto Nibali wrote:
> Alois wrote
> > could you do us the favour and present a concrete example
> > of the Packetfilter-ruleset
> > which you describe abstractly in your post, e.g. as ipchains rules?
>
> I'm not so sure if I should do so, this will maybe causes too much troubles.
> It's an excerpt of one rule of our rulebase from our packetfilter:
> fw-masq-ftp-active.
>
> # 1. from Client to Server (cmd-channel port unpriv-->21, initiated by
> # client; active data channel, port 20-->unpriv, initiated by server)
> # Command Channel
> # $4 is the fwmark
> ${IPCHAINS} -A input -j $chain $LOGIN ! -y -p tcp -i $SRCDEV -s $SRC
> $SRCPORTS -d $DST 21 -m ${4:-0}
> ${IPCHAINS} -A input -j $chain $LOG -p tcp -i $SRCDEV -s $SRC $SRCPORTS
> -d
> $DST 21 -m ${4:-0}
> # Data Channel
> ${IPCHAINS} -A input -j $chain $LOGIN ! -y -p tcp -i $SRCDEV -s $SRC
> $SRCPORTS -d $DST 20 -m ${4:-0}
> #${IPCHAINS} -A input -j $chain $LOG -p tcp -i $SRCDEV -s $SRC $SRCPORTS
> -d
> $DST 20 -m ${4:-0}
>
> # Now control and data packets in the forward-chain get masqueraded.
> if [ "$1" = "accept" ]; then
> ${IPCHAINS} -A forward -j MASQ $LOGFWD -p tcp -i $DSTDEV -s $SRC
> $SRCPORTS -d $DST 21 -m ${4:-0}
> ${IPCHAINS} -A forward -j MASQ $LOGFWD ! -y -p tcp -i $DSTDEV -s $SRC
> $SRCPORTS -d $DST 20 -m ${4:-0}
> fi
>
> # Now control and data channel in the output-chain.
> # Note: In the first rule $SRCPORTS should be replaced by the range of
> # ports which is actually used for masquerading by the kernel
> ${IPCHAINS} -A output -j $chain $LOGOUT -p tcp -i $DSTDEV -s $DSTIF
> $SRCPORTS -d $DST 21 -m ${4:-0}
> ${IPCHAINS} -A output -j $chain $LOGOUT ! -y -p tcp -i $DSTDEV -s $DSTIF
> $SRCPORTS -d $DST 20 -m ${4:-0}
>
> # 2. From Server to Client.
> # Note: In all rules $SRCPORTS should be replaced by the range of
> # ports which is actually used by the kernel for masquerading
> ${IPCHAINS} -A input -j $chain $LOGIN ! -y -p tcp -i $DSTDEV -s $DST 21
> -d
> $DSTIF $SRCPORTS -m ${4:-0}
> ${IPCHAINS} -A input -j $chain $LOGIN ! -y -p tcp -i $DSTDEV -s $DST 20
> -d
> $DSTIF $SRCPORTS -m ${4:-0}
> ${IPCHAINS} -A input -j $chain $LOG -p tcp -i $DSTDEV -s $DST 20 -d
> $DSTIF
> $SRCPORTS -m ${4:-0}
>
> # Here no forwarding rules are needed since this is handled by the
> # masquerading module (the "demasquerading")
>
> ${IPCHAINS} -A output -j $chain $LOGOUT ! -y -p tcp -i $SRCDEV -s $DST 21
> -d $SRC $SRCPORTS -m ${4:-0}
> ${IPCHAINS} -A output -j $chain $LOGOUT -p tcp -i $SRCDEV -s $DST 20 -d
> $SRC $SRCPORTS -m ${4:-0}
>
|