How do iptables rules work and not create routing loops #5402
-
Hi everyone. I'm new to linkerd and fairly new to iptables so apologies if this is a silly question. I'm trying to understand how linkerd's iptables rules work and do not cause a routing loop. There's probably something obvious about iptables or linkerd that I'm missing, but I can't for the life of me figure out what. From the linkerd architecture page I understand that linkerd-init sets up iptables rules to redirect inbound and outbound traffic to the proxy. Here are the iptables rules that are set up in one my pods (I've told linkerd to ignore port 8000).
So taking the case of an incoming connection to the pod, I think what's happening is:
At this point, I would expect the outbound packet to go through the OUTPUT and POSTROUTING steps (as it is now leaving a local process), hit the NIC, then enter PREROUTING as a new packet. But because the packet is destined for the original address, why doesn't it get redirected back to the proxy server port? In the case of an outgoing connection, the packet hits the OUTPUT chain which invokes PROXY_INIT_OUTPUT which redirects to the proxy on port 4140. But doesn't the packet then go through POSTROUTING -> NIC -> PREROUTING? At which point why isn't the packet redirected to port 4143 by PROXY_INIT_REDIRECT? Thanks in advance! Alex. |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 4 replies
-
@AlexHockey thanks for the question, I'm also not fluent in iptables rules, but I think I know what's going on here and if I'm wrong, someone else may be able to chime in. In the PROXY_INIT_OUTPUT chain, the proxy user So, in the scenario you mention, the proxy has accepted the packet and will send a the request to the underlying service as the proxy user I think that's what's happening after looking through the rules in your post. |
Beta Was this translation helpful? Give feedback.
@AlexHockey thanks for the question, I'm also not fluent in iptables rules, but I think I know what's going on here and if I'm wrong, someone else may be able to chime in.
In the PROXY_INIT_OUTPUT chain, the proxy user
2102
is ignored, with this rule:-A PROXY_INIT_OUTPUT -m owner --uid-owner 2102 -m comment --comment "proxy-init/ignore-proxy-user-id/1607688012" -j RETURN
So, in the scenario you mention, the proxy has accepted the packet and will send a the request to the underlying service as the proxy user
2102
, in which case, the jump to RETURN prevents the loop that you've described.I think that's what's happening after looking through the rules in your post.