Only block the specific port Weave Net is listening on.
Add a comment so users know what the rule is for.
Remove the rule added in v2.6.3 because it was too coarse.
We expect the loopback address 127.0.0.1 to be accessible only from
the local host.
We need to allow RELATED,ESTABLISHED traffic which may be the return
path of a Kubernetes HostPort.
Added a check to make sure the xfrm policy has not yet been updated to
a new spi. The ipsec mutex is held at this point so nothing else should
be modifying this policy.
Prior "bridge: Change local fdb entries whenever mac address of bridge device changes" [1],
FDB entry for a bridge was not inserted when creating the bridge and it could
only be inserted when a hw address of the bridge was changed. Therefore, on
an older than the 3.14 kernel containers were not able to reach
the "weave" bridge w/o setting the promiscuous mode on.
This should have hit hard Kubernetes users as the weave bridge in their
case is used as a default gateway, and thus it works only after manually
enabling the promiscuous mode.
Additionally, w/o the promiscuous mode a packet sent from a container and
destined to the gateway is flooded on all ports, so it can reach
the "datapath" device resulting in the "Vetoed installation of hairpin flow" error.
[1]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a4b816d8ba1c1917842dc3de97cbf8ef116e043e
is found to be in DOWN state
Fixes#3133 Do something more useful when the weave bridge is DOWN
On Weave restart there is already logic in place to create the bridge interface
and bring it up, this fix only monotors the weave bridge interface and logs error if
it is in DOWN state
Egress does not work in the legacy netpol mode, so in the legacy case
we don't have to create the egress traffic steering rules. Otherwise,
some traffic will be blocked.
We need two rules:
* `-A INPUT -i weave -j WEAVE-NPC-EGRESS`: applies to packets destined
to a local node.
* `-A FORWARD -i weave -j WEAVE-NPC-EGRESS`: the rest. It can match
an ingress packet.
As ipset.New(...) can be called by two processes (weaver and weave-npc)
at the same time, there is a possibility for a race when they both
check the comment support. To prevent the race, we append a random
nonce to the test ipset name.
- Track only local changes.
- Add comment to the iptables rule which prevents SNAT'ing.
- Rename the ipset to weaver-no-masq-local to prevent NPC from destroying it.
- Fix comment about create/flush WEAVE-EXPOSE.
- Add comment about reexpose being no-op if bridge hasn't been exposed.
- Add comment that the feature is not only for Kubernetes.
- Reuse the ipset instance.
This ensures that all exposing-related iptables rules are created.
As we do the re-expose, we need to clear the WEAVE-EXPOSE chain
if such exists. Thus, we use ClearChain instead of NewChain to
create the chain.
Make the rule creation to use the same mechanism (via ensureRules)
as other rules from filter/FORWARD. Otherwise, the rule is preceded
by "-j WEAVE-EXPOSE" rule which can break the subnet isolation.
EnsureBridge used to skip creation and initialization of the weave
bridge and friends if such existed. This caused problems when
EnsureBridge failed before completing all init steps and so, subsequent
weaver could not work without "weave reset".
This change makes EnsureBridge idempotent.
Docker 1.13 has changed a default policy of FORWARD chain to DROP
(https://github.com/moby/moby/pull/28257) which makes containers
inaccessible from a remote host when the bridge is exposed.
The change breaks e.g. the AWSVPC mode. To overcome this we install
an explicit rule for accepting forwarded ingress traffic to an
exposed subnet which is appended to the WEAVE-EXPOSE chain.
The chain is a target of the rule "-t filter -A FORWARD -o weave".
The change makes "weave expose" to call the "/expose" HTTP
endpoint implemented in router which exposes the bridge.
Such architectural change required as we need to know whether NPC is
enabled when exposing the bridge and weaver knows this fact the best.
Unfortunately, this change makes impossible to "weave expose"
when weaver is not running.
It's sad because this changes a regular pattern into an irregular one,
which will create spurious diffs if more work is added at the end of
the function. Still, this is easier than fixing the lint runner to
ignore the report.
The fix ensures that if odp is not supported (usually due to
missing openvswitch, vxlan or vport-vxlan kernel modules),
weaver will create the pcap based bridge instead of crashing.
We don't get a very useful error object back from go-iptables and I
didn't feel like parsing the message, so just ignore all errors.
It would be racy to try to check if WEAVE-NPC existed before calling
NewChain.
Bryan Boreham