| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We store the destination IP of incoming packets as the source IP of
outgoing packets. When we send outgoing packets, we then ask the routing
table for which interface to use and which source address, given our
inputs of the destination address and a suggested source address. This
all is good and fine, since it means we'll successfully reply using the
correct source address, correlating with the destination address for
incoming packets. However, what happens when default routes change? Or
when interface IP addresses change?
Prior to this commit, after getting the response from the routing table
of the source address, destination address, and interface, we would then
make sure that the source address actually belonged to the outbound
interface. If it didn't, we'd reset our source address to zero and
re-ask the routing table, in which case the routing table would then
give us the default IP address for sending that packet. This worked
mostly fine for most purposes, but there was a problem: what if
WireGuard legitimately accepted an inbound packet on a default interface
using an IP of another interface? In this case, falling back to asking
for the default source IP was not a good strategy, since it'd nearly
always mean we'd fail to reply using the right source.
So, this commit changes the algorithm slightly. Rather than falling back
to using the default IP if the preferred source IP doesn't belong to the
outbound interface, we have two checks: we make sure that the source IP
address belongs to _some_ interface on the system, no matter which one
(so long as it's within the network namespace), and we check whether or
not the interface of an incoming packet matches the returned interface
for the outbound traffic. If both these conditions are true, then we
proceed with using this source IP address. If not, we fall back to the
default IP address.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
DaveM prefers it to be this way per [1].
[1] http://www.spinics.net/lists/netdev/msg443992.html
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
This logic belongs upstream.
|
| |
|
|
|
| |
This helps "unstick" stuck source addresses, when changing routes
dynamically.
|
| |
|
|
|
|
|
| |
This not only removes the depenency on x_tables, but it also gives us
much better performance and memory usage. Now, systems are able to have
millions of WireGuard interfaces, without having to worry about a
thundering herd of garbage collection.
|
| |
|
|
|
|
|
|
|
|
|
| |
We can let userspace configure wireguard interfaces before the RNG is
fully initialized, since what we mostly care about is having good
randomness for ephemerals and xchacha nonces. By deferring the wait to
actually asking for the randomness, we give a lot more opportunity for
gathering entropy. This won't cover entropy for hash table secrets or
cookie secrets (which rotate anyway), but those have far less
catastrophic failure modes, so ensuring good randomness for elliptic
curve points and nonces should be sufficient.
|
| |
|
|
|
|
|
|
| |
It's possible that get_random_bytes() will return bad randomness if it
hasn't been seeded. This patch makes configuration block until the RNG
is properly initialized.
Reference: http://www.openwall.com/lists/kernel-hardening/2017/06/02/2
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
It still is sort of experimental, I suppose, especially this part in the
udp_tunnel drop-in:
skb_orphan(skb);
sk_mem_reclaim(sk);
It seems like sometimes this won't do what we want, but it's hard to
diagnose exactly what's happening. In any case, nobody paid attention to
that warning anyway, so let's just get rid of it.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
On 4.11, get_random_u32 now either uses chacha or rdrand, rather than
the horrible former MD5 construction, so we feel more comfortable
exposing RNG output directly.
On older kernels, we fall back to something a bit disgusting.
|
| | |
|
| | |
|
| | |
|
| |
|
Jason A. Donenfeld