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.
In a world gone mad, posting a map of the Gulf of Mexico is a revolutionary act.
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.
Queens, New York
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:
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.
I like to imagine the origin of life as some organic scum sloshing around in a tidal wavepool. The evaporation creates concentration, the soapy foam provides compartmentalization. The bubbles merge and break apart, hosting populations of spontaneously-polymerizing goo. With enough time and luck, you get some randomly-formed polymer that is able to catalyze more polymerization. From there natural selection takes over. Sometime later the polymers learn how to stabilize their own bubbles, so they are not at the mercy of the waves any longer. This keeps the other random polymers out, such that when the auto-catalytic polymers catalyze more polymerization, they create more copies of themselves rather than of random junk. This is hugely advantageous to their population numbers, so that if such bubble stabilization can happen at all, it will happen and then dominate.
In this fantasy it is difficult to point to any single bubble and say “This, this is the first cell.” It’s all just a bunch of foam seething, forming and reforming. The polymers keep mixing and separating. To draw a line at one is as arbitrary as to say “This, this is the first chicken, born of an egg, laid by a bird-like creature who is not a chicken” to solve the chicken-and-egg problem. There could be thousands of generations of chicken-like creatures, any one as good a pretender to be the first as another.
There are thousands of bubbles, no single moment of transition between non-life, proto-life, and cellular life, but I do believe they have to come from around the same time and the same wavepool. There isn’t some other wavepool from a hundred million years later that completely independently grew its own bubbles and resulted in a separate line of universal descent that later got merged into the tree of life. It happened on Earth once, so it could have happened again in a hundred million years… EXCEPT that now that it has happened, the existing life would colonize the entire planet and eat up all the organic goo molecules as quickly as they become available. Proto-life cannot outcompete full-life.
I like this cosmology calculator: https://www.astro.ucla.edu/~wright/CosmoCalc.html Enter redshift z=1100 (which is the observed redshift of the CMB) and hit the “general” button, which calculates the distances using the currently-accepted general model and Hubble parameter/dark matter/dark energy values. This gives the “comoving radial distance” of 45.5 Gly (giga light years). That means that if right now, at this very instant, you put down a meter stick in front of you, and the buddy next to you put down a meter stick, and the buddy next to them, and so on through the next galaxy, and every galaxy, all the way to the place where the CMB in that direction originally came from (the place is still there and there is probably a galaxy there now though there wasn’t one back then), there will be 45 billion light years worth of meter sticks.
The other values of note are the light travel time of 13.72 Gyr (travel time is how distances are usually reported in news articles, as opposed to scientific articles that only report the redshift z), and the age of the universe at the time the light was emitted: 0.37 My = 370000 years, which is the age when recombination happened. The total age of the universe (13.721 Gyr) is the sum of these two.
The value you probably want is the “angular size distance” in the calculator, which is the meter-stick method done in the moment when the light was emitted rather than at the moment right now. In this case the distance is 0.0413 Gly. Only 41 million light years, really close by! There was a lot of stuff packed together, but it has stretched out since. The relationship between the two distances is:
comoving distance = angular-size distance * (z + 1)
So redshift of 1100 means the spacing has been made 1101x times wider.
Of course if the universe were literally stationary then your question wouldn’t make sense because the universe would never cool down and CMB would not happen. If the universe expansion had stopped at the moment the CMB happened, then the distance to the CMB you want is the 13.72 Gly travel time distance, but it wouldn’t be our CMB anymore, it would be some other last scattering surface much farther out away.
I got a dozen eggs, will trade you for 6 big macs. Everybody wins. Capitalism!
Exactly right! The desire on display in this snow path is the desire for more space/safer lane width tolerances. The handlebars on my bike alone are more than 2 feet wide, I literally cannot fit in the quarter-lane as designated!
There’s been talk for several years of repurposing the mirror traffic lane on the other side of the bridge for exclusive pedestrian use, which would solve this. Both lanes were originally streetcar tracks when the bridge was first built, then converted into car lanes and remained so for decades. The car lane still in use on the opposite side is hardly even used because the un-expandable 8 feet is narrower than standard lane width. Trucks and larger cars can’t fit there, almost all motor vehicle traffic goes through the interior bridge lanes instead. Yet for years the city resisted the switch. Showing desire is important to win them over.
I do have good news to report for accuracy’s sake: after several more snowfalls during the winter, the many bridge paths did get salted every time afterwards, and this scene did not repeat. Must have been an aberration!
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 routerouting 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.