Re: Problems understanding nftables part 2

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello Kerin,


>>
>>> It's not clear that you understand that the value of nftrace doesn't quietly reset itself to 0 between hooks, however.
>>
>> Can you explain this further? Which value of nftrace? What shall reset itself?

> What I mean is that, once the nftrace attribute is set to 1 for a given packet, it stays that way
> until the packet is given its final verdict. So, if you hook at a sufficiently early juncture, it
> normally takes no more than two hooks by which to set the nftrace attribute to 1 and be able to
> trace the path of a packet through a ruleset very comprehensively. Of course, you can create as
> many hooks as you wish. However, if the resulting chains are to contain nothing but a single rule
> to set nftrace to 1 (again) then there is no need; it will only serve to make the trace output more noisy.

Ok, so here we have the same understanding. I really don't care actually about noisy rules, as my
test rules are only containing constraints to single connections, i create with socat, netcat etc.
This is just a tool, to see, whats going on and getting a deeper understanding.

> The path does go through ingress/egress. That the interface isn't a physically tangible one
> doesn't matter. For that reason, I don't think that it requires any special accommodation by the
> diagram. For locally generated packets, "lo" may be selected by the routing decision. Meanwhile,
> packets arriving at "lo" are handled similarly to any other interface.

For me right now its really important, as I missed in that diagram the way, internal communication
flows. I had one problem, I researched, where this explanation helped me a lot.
And as this kind of diagrams are used by so many people, with different intention, what they search,
it is -by my opinion- a very important piece.
It was for me not clear, that local traffic between two applications listening on eth0 ip addresses,
is in reality handled over lo.

In my roadmap is now to investigate tun/tap and other stuff, I assume, that this is also flowing
through lo.

Regards

  Wolfgang





[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux