TauZero @ TauZero @mander.xyz

Posts

7

Comments

295

Joined

2 yr. ago

Gravity—the curvature of space-time—can’t stop changes in the curvature of spacetime from propagating outward.

This is false. If it were true, you could build a device to communicate from inside a black hole event horizon. By waving around a heavy ball you would create gravitational waves that a sensitive enough LIGO outside the black hole could detect. But this is impossible. You would create gravitational waves, yes, but they would fall towards the center singularity same as you, and will never penetrate and escape the event horizon.

Use wireshark and listen on your ethernet interface. When you use tailscale, are the packets coming in/out from the tailscale server IP or the VPN ip? Check through the ip route routing table and figure out which pathway a packet will take in each use case. Might need to add a route exception specifically for the tailscale server IP to go out on the ethernet device.

sacrifice the luxury of convenience and being able to get doordash whenever you want

Not necessary. I live in Manhattan and the street canyons are full of doordasher ebikes, and grocery store isles are jammed with instacarter trailer carts which they then hitch up to more ebikes.

otherwise empty bike lane

Over here in New York, everyone got an e-bike and now we get bike jams in the bike lane during commute hour. Dunno how I should feel about it. Aladeen? :(: Still faster than a car for sure.

    
PostUp = ip route add 100.64.0.0/10 dev tailscale0


  

Looks like you need to stick this line in the tailscale service file, since it's the only time that the existence of the tailscale0 device is guaranteed. If you don't want to modify the service file inside the package, could you write your own systemd service file and include the tailscale service as a prerequisite?

Also make sure that when you start the VPN first and then tailscale, you don't get a double tunnel situation where tailscale goes out through the VPN (unless that's what you wanted).

I saw a study that DHMO is stored in the balls.

The exact script would depend on the use case; you'd use commands something like this:

    
mkdir -p /etc/netns/VPN
sh -c 'echo nameserver 1.1.1.1 > /etc/netns/VPN/resolv.conf'
ip netns add VPN
ip link add tun1 type wireguard
ip link set tun1 netns VPN


  

Because the wireguard device was created in the default namespace, it will "magically" remember its birthplace, even after you move its mouth (the tun1 device) to a separate namespace. The envelope VPN packets will keep going in/out in the default namespace.

    
ip netns exec VPN wg setconf tun1 /etc/wireguard/vpn.conf
ip netns exec VPN wg set tun1 private-key /etc/wireguard/vpn-key.private
ip -n VPN addr add 192.my.peer.ip/32 dev tun1


  

Get the wireguard config file from the VPN website, both mullvad and OVPN have a wizard to generate them. Your assigned private network ip is in the config file. Also get and save your device key.

    
ip -n VPN link set tun1 mtu 1420
ip -n VPN link set tun1 up
ip -n VPN route add default dev tun1
ip netns exec VPN su myuser -c 'firefox --no-remote'


  

Now all firefox (and only that firefox) traffic will go through the tunnel. Firefox has its own DNS, if you run another app it will use 1.1.1.1.

I actually do the reverse of this - I create a namespace ETH and move my eth0 device in there and attach dhcpcd to it. Then I create the wireguard tun1 device inside ETH namespace, and move tun1 to the default namespace. Then any software I run can only use the tunnel, because the ethernet device doesn't even exist there. This keeps the routing table simple and avoids a whole class of issues and potential deanonymization exploits with the split routing table used in traditional single-namespace VPN configurations.

You can set up split tunneling yourself if you run the wireguard/OpenVPN daemon manually and move the "mouth" of the tunnel to a separate Linux network namespace.

OVPN is a 1-to-1 feature clone of mullvad (wireguard, multiple device keys, crypto payments/cash in the mail, no usernames/emails, etc.) AND has port forwarding. Switched to them when mullvad sadly closed their ports, no problems since. Can't live without port forwarding.

That allows sending packets inside the VPN tunnel, but the outer envelope packets still need to be able to reach the VPN server.

sudo ufw default deny outgoing

I'm guessing this would block the VPN packets themselves as well.

Yep, that's how the calculation goes! You only need mssfix on the innermost tunnel, and the outer tunnel will stay under the limit naturally. Mssfix only works on TCP, so it wouldn't work on the VPN packets themselves anyway, inside the outer tunnel. OpenVPN/wireguard use UDP. By the way, does Discord use UDP at all? I don't know what's the proper way to limit the size of UDP packets in a situation where pathway mtu discovery is the problem/issue. I only know the trick with TCP and clamp-mss. Is there a way to tell discord to force use TCP only? Also, can you be sure that Discord service itself doesn't block your commercial VPN?

Not sure what your setup is trying to do, but I run a double tunnel, and it is not usable without clamping the mss! Even when I set the correct link mtu, I still see in wireshark that the envelope IP packets get fragmented. The packets still get delivered, which is good in a way since it lets many internet services work albeit at half the speed, EXCEPT that most (but not all) TLS connections fail to progress past the handshake. It is as if TLS is trying to squeeze an entire certificate into a single packet and refuses to work if that packet gets fragmented, even if all the fragments arrive intact. This fails silently, with the browser window just spinning forever for example.

However if I set mtu AND clamp mss like this:

    
ip link set tun1 mtu 1420
ip link set tun2 mtu 1340
iptables -t mangle -A FORWARD -o tun2 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
iptables -t mangle -A FORWARD -i tun2 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu


  

Then the packets do not get fragmented, every service including TLS works perfectly, and I get 90% of full tunnel-less bandwidth. I use wireguard, not OpenVPN, and testing with wireshark shows that a single wireguard wrapper is about 80 bytes. The iptables --clamp-mss-to-pmtu option is equivalent to OpenVPN's mssfix option if I recall.

IMHO if you don't have a globally-reachable address or forwarded port, you are not really a participant of the internet, you are just a receptacle xD

One service I never see mentioned is OVPN. They have a 1-to-1 feature parity with mullvad and were an easy drop-in replacement when mullvad closed their ports:

• wireguard
• port forwarding
• no usernames/emails/registration, only account numbers
• crypto payments/cash in the mail
• same price as mullvad
• multiple device keys
• multihop
• no bandwidth limits
• setup guides
• status dashboard

I used mullvad for years, sad to see them go, and all my scripts basically worked without any change other than the server addresses/public keys. Only downside is they don't have as many users so not as many servers. I wish more people would join up so I get more IPs to choose from :D

I know you are just nitpicking on whether the current dictatorship has an official policy to deport American citizens, but I want to clarify, for the benefit of anyone else who might not be aware of this, that the American government has in fact already deported multiple American citizens by mistake. This GAO investation found that while ICE doesn't keep track of such stats, based on the data that is available it must report that indeed "ICE and CBP took enforcement actions against some U.S. citizens." The numbers are in the hundreds-arrests-per-year range, and dozens-per-year deportations. There are many interviews in the press with American citizens who say they were illegally detained or deported. Some Americans had to sneak back across the border after being illegally deported. Many Americans sued and won settlements for their illegal deportations, so now it is official court record that such events happened.

This is not just a matter of ambiguity, cases of "who can really know whether that person was a citizen or not". These are cases where CBP has been clearly negligent, where the victims had been able to procure for display real birth certificates, real passports, and the agents wouldn't look at them. The court-appointed lawyers would "lose" the documents and claim none were received in front of the judge, or there would not even be court hearings at all, just deportations. When sued later, no one would take responsibility, no one reprimanded, just settlements paid out. Sometimes the CBP would get sued, receive a court judgement affirming that the victim was a citizen who was unlawfully deported, then ignore the judgement and deport them again. This has all already happened... under past administrations. The implication is that the willful negligence under the current one will not get better.

For something like a browser, you don't even need to "install" at all. You only need to acquire the standalone/portable executable from the browser developer's official website. For example you get Waterfox from https://www.waterfox.net/download/. If you read the PKGBUILD, even if you can't see through all the potential malicious tricks you'll at least find that that's basically all it claims to do: download a binary from official website and put it somewhere. In this case "installing" means using root permissions to stick it in /usr/bin, so all users on the computer can run it. But since almost all home computers only have a single user, you can skip having to give it (temporary) root access by saving it in your home directory instead. I also run the binary inside its own Firejail so it doesn't even have access to my personal files. You are always trusting someone, be it the Arch maintainers, the AUR contributors, or the independent browser developers, but this way the least number of parties get the least number of permissions.

windy.com with a VPN in a private browser window. They can't track you if they don't know where you are!

Yeah, I concede that small caps are more likely to be carried away by rainwater than whole bottles :D. What I meant was that for every loose cap on the ground there is a bottle lying around somewhere, and also there are bottles with caps on. No one is tossing their cap into the bushes and then taking the bottle to the recycling center.

Can you explain please, where I made a mistake?

Your mistake is thinking Earth is 6km in radius! :D 6km is how far you walk in an hour. Either you think Earth 1000 times too small or kilometer 1000 times too big.

For an object heavier than the Earth, 1g radius will be greater than the radius of Earth. For 56 Earth masses that's sqrt(56) times bigger = 48000km.

A 56 Earth mass black hole will take 5.5e55 years to evaporate according to this calculator. A 100kg black hole (more close to what Richard used to be) is much smaller than the nucleus of an atom and will evaporate in 0.05 nanoseconds.

Curiously there was a paper recently that calculated that even if there was a small black hole in the center of the Sun, it would take millions of years for it to grow, because the aperture is so small not much can fit through, and the infalling gas heats up so much as to repel the rest, creating an internal hot bubble.