Sharkey-touching mutuals, weird question for y'all: do you know of any reason that a new Sharkey instance would federate with *key and Akkoma instances without issue, but fail for every Mastodon instance?
-
pancake :butterfly_::neofox_lesbian:replied to Amber last edited by
@[email protected] @[email protected] @[email protected] wait how is Mastodon causing this out of all things
-
Amberreplied to pancake :butterfly_::neofox_lesbian: last edited by
@[email protected] @[email protected] @[email protected] what happens is people use something like wireguard for ip forwarding… and they end up dealing with mtu mismatch (and it doesn’t matter whether it’s in docker, just that docker is more prevalent for this sort of configuration nightmare). I have debugged several instances that were running akkoma and couldn’t connect to mastodon instances (funnily enough it was always them being unable to connect to tech.lgbt). Then Julia had the problem on sharkey and now we have another person having problems and you know… I hate speculating but i have a bias
-
@puppygirlhornypost2 @natty @SymTrkl @julia Best part? This should be covered by "MTU discovery" that works almost everywhere else. But wireguard intentionally breaks MTU discovery for the tunnel by ignoring "MTU exceeded" because "security," when they have numerous other options. The most "secure" being probe the MTU at handshake time rather than "oh you configured it wrong? Well that's your own fault, 'security' means we can't have auto-discovery." And the second best is "oh, we got an MTU exceeded? Let's clamp to the minimum IPv6 MTU" to prioritize working traffic over "slightly more performance but also silently dropping packets"
(Specifically if you set the MTU wrong on the tunnel interface, applications sending too-large packets will cause oversized tunneled packets, and because wireguard appears to prioritize security above functionality, those wrapped packets are silently dropped. If you set the MTU correctly, the tunnel rejects the too-large packets normally with an MTU exceeded)
-
-
@becomethewaifu @puppygirlhornypost2 @natty @SymTrkl @julia Wireguard: It’s just not that good, actually.
-
@[email protected] @[email protected] @[email protected] @[email protected] @[email protected] it’s good but you have to take certain things into consideration. I still find UDP based vpns to be far superior (tcp over tcp is awful, same goes for udp over tcp)
-
@puppygirlhornypost2 @natty @SymTrkl @becomethewaifu @julia there exist other, significantly higher performance options with less stupid foodguns like “we ignore all ICMP packets received from the other end” VPN options
Like IPsec, which has its own problems but not these stupid assinine ones.
-
@puppygirlhornypost2 @SymTrkl @becomethewaifu @julia @natty (and WireGuard could have been a simple handshake protocol which then shoves key material into the kernel over the Linux
xfrm
interface and the result would have been equally secure, more functional, much faster, and already offloaded on a surprising amout of networking hardware) -
@erincandescent @SymTrkl @natty @julia @puppygirlhornypost2 It's more that it's just extremely opinionated, and some of those opinions are kinda shit... It doesn't even bother to check the MTU of the outgoing network interface prior to dropping packets, and that has no "security" excuse: if you can't trust the system kernel to provide an accurate MTU at least for the first hop, that means an attacker is already potentially in your system with pretty high privileges, and that's not a scenario wireguard can protect against.
-
@puppygirlhornypost2 @natty @SymTrkl @becomethewaifu @julia @erincandescent do you have a VPN that you would recommend for this sort of usage? At some point I was hoping to do something and was probably just gonna use wireguard...
-
@[email protected] @[email protected] @[email protected] @[email protected] @[email protected] @[email protected] is still use wireguard just ask what other people have done to alleviate the issues.