The current SNAT implementation has several limitations:
- SNAT source port has to be specified. It is not optional.
- SNAT source port range is not supported.
- SNAT for UDP is a one-way translation. No response packets
are handled (because conntrack doesn't support UDP currently).
- SNAT and REDIRECT can't work on the same connection.
Fixes#5489
PiperOrigin-RevId: 367750325
Implementing interfaces on value types causes the interface to be
implemented by both the value type and the pointer type of the
implementer. This complicates type assertion as it requires the
assertion to check for both the pointer type and the value type.
PiperOrigin-RevId: 357061063
We have support for the output interface name, but not for the input
interface name.
This change adds the support for the input interface name, and adds the
test cases for it.
Fixes#5300
PiperOrigin-RevId: 353179389
Adds support for the IPv6-compatible redirect target. Redirection is a limited
form of DNAT, where the destination is always the localhost.
Updates #3549.
PiperOrigin-RevId: 334698344
//test/iptables:iptables_test runs 30 seconds faster on my machine.
* Using contexts instead of many smaller timeouts makes the tests less
likely to flake and removes unnecessary complexity.
* We also use context to properly shut down concurrent goroutines and
the test container.
* Container logs are always logged.
Fixes a NAT bug that manifested as:
- A SYN was sent from gVisor to another host, unaffected by iptables.
- The corresponding SYN/ACK was NATted by a PREROUTING REDIRECT rule
despite being part of the existing connection.
- The socket that sent the SYN never received the SYN/ACK and thus a
connection could not be established.
We handle this (as Linux does) by tracking all connections, inserting a
no-op conntrack rule for new connections with no rules of their own.
Needed for istio support (#170).
Loopback traffic is not affected by rules in the PREROUTING chain.
This change is also necessary for istio's envoy to talk to other
components in the same pod.
Connection tracking is used to track packets in prerouting and
output hooks of iptables. The NAT rules modify the tuples in
connections. The connection tracking code modifies the packets by
looking at the modified tuples.
This change adds a layer of abstraction around the internal Docker APIs,
and eliminates all direct dependencies on Dockerfiles in the infrastructure.
A subsequent change will automated the generation of local images (with
efficient caching). Note that this change drops the use of bazel container
rules, as that experiment does not seem to be viable.
PiperOrigin-RevId: 308095430
This feature will match UID and GID of the packet creator, for locally
generated packets. This match is only valid in the OUTPUT and POSTROUTING
chains. Forwarded packets do not have any socket associated with them.
Packets from kernel threads do have a socket, but usually no owner.
Fixed flakes (tested via --runs_per_test=100) and added skips for
not-yet-implemented features. Once submitted, the iptables tests will be
ready to enable in kokoro.
Enables commands such as:
$ iptables -A INPUT -d 127.0.0.1 -j ACCEPT
$ iptables -t nat -A PREROUTING ! -d 127.0.0.1 -j REDIRECT
Also adds a bunch of REDIRECT+destination tests.
- Adds creation of user chains via `-N <chainname>`
- Adds `-j RETURN` support for built-in chains, which triggers the
chain's underflow rule (usually the default policy).
- Adds tests for chain creation, default policies, and `-j RETURN' from
built-in chains.
Added tests for tcp protocol with input and output rules including options sport and dport
Increased timeout in iptables_test as TCP tests were timing out with existing value.
Fix the indentation and print statements.
Moved the NAT redirect tests to new file.
Added negative test to check redirect rule on ports other than
redirected port.
This gets us closer to passing the iptables tests and opens up iptables
so it can be worked on by multiple people.
A few restrictions are enforced for security (i.e. we don't want to let
users write a bunch of iptables rules and then just not enforce them):
- Only the filter table is writable.
- Only ACCEPT rules with no matching criteria can be added.