shokwave a écrit :
>
> Because when I try to set up ebtables on my router to just use a
> default DROP policy, I can no longer ping the router.
May I ask why on earth do you want to set a default DROP policy in the
broute/BROUTING chain ? What is your goal ?
> That's what I initially started off with, thinking the following would
> happen
>
> 1) packet comes in
> 2) -t broute BROUTING table says "send this up to the routing code"
> 3) since the router, at 192.168.1.1 is the one being pinged, the
> loopback should catch this, and the ping should reply
Are you talking about the loopback interface lo ? If so, what does it
have to do here ? It only concerns traffic from a host to itself.
> btw: eth0 (my client PC connected to router) and atm0 are in br0
> bridge)
If you try to ping the router's address from the client, packets arrive
on eth0, not atm0.
Also, I'm afraid your plan forgot about the ARP protocol, as mentionned
by David. Here is what probably happens.
The client wants to send an IP packet with an ICMP echo request (ping)
to 192.168.1.1. Before it must learn the associated MAC address using
the ARP protocol, which is distinct from IP. It broadcasts an ARP query
for 192.168.1.1 on the link. The ARP query arrives at the interface
eth0, which is part of the bridge br0, so the packet goes through
ebtables and reaches the BROUTING chain in the broute table. As the
packet does not match the only rule in that chain, the default policy
DROP is applied. As you know, DROP in that chain means that the packet
must be "routed" instead of bridged. So instead of being handed to the
bridge, it is treated as a regular packet received on eth0. If eth0 is
bound to the IPv4 stack [1], it is handed to the ARP layer of the
network stack.
You can check which interfaces are bound to IPv4 with :
$ ls /proc/sys/net/ipv4/conf/
Note that an ethernet interface is not bound to IPv4 stack by default,
until an IPv4 address is assigned to it. You can bind an interface
without assigning it an address with :
$ ifconfig <interface> 0.0.0.0
Let's assume eth0 is bound to the IPv4 stack. So the ARP request is
handed to the ARP layer. By default the ARP layer sends a reply for
192.168.1.1 through eth0 with the MAC address of eth0 to the client.
Now the client can send the IP packet containing the ping request to
192.168.1.1 using the MAC address of eth0 advertised in the ARP reply.
The paquet arrives at eth0 and reaches the BROUTING chain in the broute
table. As the packet matches the only rule in that chain, the target
ACCEPT is applied, meaning that the packet is handed to the bridge. The
destination MAC address is known by the bridge as "local", because it
belongs to one of the bridged interfaces. So the packet is delivered to
the local IPv4 stack as received on br0.
Now the router wants to reply to the ping. Its IPv4 routing table tells
it that the destination is reachable via br0, so the information from
the previous ARP request received on eth0 is ignored. It broadcasts an
ARP query on br0, and expects a reply received on br0. But the ARP reply
won't match the ebtables rule, so it will be "routed" and received on
eth0 instead of br0. The router does not receive an ARP reply on br0 and
cannot send the ping reply.
|
Similar Threads
Linear Mode
