|
Hello,
On Sat, 18 Nov 2000, Anush Elangovan wrote:
> Hi Lorn,
> Thanks for your good suggestion, I surely think what you have
> suggested is a good way to do it because of the difficulties with
> respect to the generation of the TCP RST in DR and TUN modes. With what
> you have suggested, the whole mechanism could be moved to the real
> servers rarther than sitting on the director only and each system would
> take care of only the connections that are destined for it. Then this
> would also work irrespective of LVS. Can anyone of the experienced lvs
> people tell me if the FWMarking would work?
I don't understand very well this idea. You want to mark the
packets and LVS to deliver them locally to the TCP stack instead of
forwarding them?
> One problem could be the ICMP Reqests generated by the real
> server, will the replies be relayed by the LVS director to the
> corressponding real server?? A solution could be to use the routeable
> "real IP" of the realserver to send the ICMP requests.
No, LVS forwards TCP, UDP and "related ICMP" to the real servers.
You can't expect from LVS to forward all ICMP replies for requests
generated from the real servers. This works only with NAT and is not
related to the LVS work. LVS tries to forward only the traffic related
to its connections. The other incoming ICMP traffic is not touched. May
be someone just pings VIP :)
> But Im not sure if LVS would be able to work with the above
> mentioned hook in place. The reason Im skeptical about this is because
> of the "double connection tracking" done by ip_vs and ip_conntrack,
> that Julian had mentioned on the list a few days ago. Ahh... and one
> more thing, can anyone clearly demarcate what parts of the netfilter
> code do we use in lvs and what parts we dont? Like for example we dont
> use ip_conntrack. Are there any similar modules we dont /should not use
> ? Im trying to go through the code but I guess you may have first hand
> information.
LVS hooks in the LOCAL_IN chain. Hm, it is again on wrong place.
Must be LOCAL_IN:100, i.e. after the filter. I didn't made full testing
but LVS should work with any netfilter module except the mentioned and
the depending modules.
The packets are handled in this way (I don't mention all steps,
please correct me if something is wrong):
- PRE_ROUTING:
1. iptables
- ip_conntrack (pri=-200)
- firewall marking (pri=-150)
- iptable_nat (pri=-100)
- net/sched/sch_ingress.c:ing_hook (QoS ingress qdisc) (pri=1)
2. ipchains.o
- firewall marking
- filter
- net/sched/sch_ingress.c:ing_hook (QoS ingress qdisc) (pri=1)
- ip_route_input (the routing)
- can decide to feed the packet to LOCAL_IN or FORWARD
- can drop the packet
- LOCAL_IN:
- filter (pri=0), drop/reject/pass packets
- LVS (pri=100)
- FORWARD (outgoing):
- filter (pri=0)
- LVS (pri=100)
- POST_ROUTING
- iptable_nat (pri=100)
- ip_conntrack (pri=last)
Here is how the packet walk the chains when it is handled
from LVS:
Client -> Real Server
pre_routing -> local_in (LVS) -> post_routing
Real Server -> Client (NAT only)
pre_routing -> forward (LVS) -> post_routing
Here is the description:
- the packets are marked in the pre_routing in both cases (iptables and
ipchains). LVS uses this for the fwmark-based virtual services. The users
can use fwmark in the routing decision or for QoS
- LVS stays in LOCAL_IN chain, after any packet filter in the pre_routing
or in the local_in chains, the place of the filter is different in iptables
and ipchains. Staying in LOCAL_IN allows the users to filter the packets
before they reach LVS and before they are forwarded to the real server.
- the routing decides whether to accept the packet locally and later
this packet to reach LVS. For this decision the IP header and other
skb info is used
- LVS tries to avoid two or more lookups in the connection table
by working with the packet in only one place, i.e. LOCAL_IN for
the incoming packets (external -> internal) and FORWARD for the
outgoing packets (LVS handles the outgoing packets only for NAT).
Finally, you see where the ip_conntrack and iptable_nat
are placed. These modules work with all packets. While the ip_conntrack
looks passive the nat module is active and can mangle the packets
handled from LVS. There is no known way to determine whether the
packet delivered to LVS is already handled from these modules in the
pre_routing. In any case ip_conntrack creates its own connection
structure and later LVS creates second one. You understand that
the effect for DR and TUN is only this double connection tracking.
For the NAT mode the picture is different: the packets are mangled
at pre_routing and at post_routing if you have such nat rules and
the LVS packets can be dropped as untracked packets at the post_routing
chain.
> Finally does anyone of you have any experience with hacking the
> netfilter code and using those hooks in userspace, or any example code
> that I could use as a reference to try a prototype implementation.
You can find such examples may be in the netfilter sites.
> Thanks,
> Anush
> Lorn Kay wrote:
>
> > Well, I think it would make sense to mark the packets with netfilter
> > in the NF_IP_PRE_ROUTING hook if you suspect a DOS attack. Build the
> > intelligence into netfilter with user interaction through the
> > iptables/ipchains command so it can be adapted based on the experience
> > of hacking attacks without modifying source code. (This is a
> > "firewall" function you are trying to implement isn't it?)
IMO, this is a TCP stack function. This is a protocol issue
at the end host. LVS uses these strategies only to guard itself,
not the real servers.
> > Perhaps a special packet FWMARKing scheme could be developed which
> > IPVS could then interpret thanks to ipvsadm commands.
Please, elaborate! I don't understand very well how this
mechanism will work.
> > That would be cool...
> >
> > --K
Regards
--
Julian Anastasov <ja@xxxxxx>
|
