←back to thread

602 points hhutw | 1 comments | | HN request time: 0.218s | source
Show context
elevation ◴[] No.45640290[source]
This place needs more of this kind of documentation.

I failed to use IP tables for years. I bought books. I copied recipes from blog posts. Nothing made sense, everything I did was brittle. Until I finally found a schematic showing the flowchart of a packet through the kernel, which gives the exact order that each rule chain is applied, and where some of the sysctl values are enforced. All of a sudden, I could write rules that did exactly what I wanted, or intelligently choose between rules that have equivalent behaviors in isolation but which could have different performance implications.

After studying the schematic, every would just work on the first try. A good schematic makes a world of difference!

replies(4): >>45640322 #>>45640323 #>>45643938 #>>45648472 #
HotGarbage ◴[] No.45640322[source]
Was it this one? https://en.wikipedia.org/wiki/File%3aNetfilter-packet-flow.s...
replies(3): >>45642616 #>>45644247 #>>45648367 #
1. immibis ◴[] No.45648367[source]
This also isn't complete because it doesn't show code between or around the various tables. I used to think of iptables as dumb filters that manipulate raw packets before/after the rest of the kernel sees them, but this view is wrong, and doesn't explain, for example, how it does NAT.

And the answer is it doesn't do NAT. The code is already preparing to do NAT, and that code merely consults the table to find out what kind of NAT it should do. The diagram makes it look like you can just move a NAT rule to a filter or mangle rule because the kernel just applies these tables in sequence anyway, but you can't because they are consulted by different blocks of code for different purposes.