VPN directly on a host
All past VPN usage was inside containers & virtual machines, but problems with doing that behind wifi led to dedicating a host to a VPN. The journey begins with installing a new raspberry pi.
dd if=image of=block device bs=4096 status=progress
Edit /etc/passwd & delete the root password to allow a root login without password. They don't support the pi user anymore. Then from the serial console, disable some services.
systemctl disable lightdm
systemctl disable cups
systemctl disable ModemManager
systemctl disable NetworkManager
systemctl disable wpa_supplicant
Reboot it
To enable public wifi on it, you need to log in on a browser. iptables is not included in the image. sshd, firefox, & chromium do come with the image. sshd_config needs the PermitRootLogin yes line. Firefox is broken but chromium can log in with a lot of prodding. Then you can install iptables & bypass the X11 forwarding.
The next step is following the lion kingdom's container document to install the VPN bits directly on the host.
https://hackaday.io/project/189936-container-cheat-sheet
Then, with no mtu adjustments it started downloading pretty quickly. So transmission-daemon needs to run in a dedicated box with no container & probably no masquerading.
The downloads go in /var/lib/transmission-daemon/downloads & they're super slow to access over NFS. Reliable gigabit is the other big challenge. Then there's a permanent enclosure for the server farm.
They're all going to standard standoffs & acrylic sheets but they're really hard to access.
There's no current need for the extra complexity of masquerading on anything with its own wifi, but we're definitely back to the age of dedicated boxes being required for a lot of things.
Maybe it would work in a virtual machine, but the memory is just too expensive & modern operating systems are too dependent on direct hardware.
It's still just a hope that wifi will be more reliable than wired connections to Comca$t. The whole affair made lions ponder how much Comca$t is costing the world with its reliability problems. Just 1 outage is immensely devastating.
Another idea that came up was trying dhclient from a different MAC address, but something longer term was needed.
All the DNS lookups on public wifi are in the clear. It's not ideal, but nothing useful can be done with DNS lookups.
In the end, an ad hoc server farm was the best strategy. The new 5V drop & permanent home took a full night.
Putting sin on the floor reduced the cable run. The phone wifi & gateway should be combined in a xena replacement. That should get the piano's 64GB for gootube downloads. Concurrent AP & station is a reasonable compromise for saving on cables & for the amount lions use phone wifi. The cables are a big deal. Then piano goes to a 32GB for just recording audio. About time to scrap the fake starlink enclosure & go to an exposed vertical panel, maybe a bare MDF panel.
As messy as it is, this same operation 25 years ago would have entailed an apartment full of PC towers & they wouldn't have had nearly the resources. The 1st single board 486 & how expensive it was is still fresh in lion minds. It was really unheard of until 2000.
Helas, the default route is now dynamic instead of the static address of xena. Restoring it when the VPN dies requires digging into the DHCP cache, but we have Grok.
DEFAULT_ROUTE=$(grep "option routers" /var/lib/dhcp/dhclient.leases |tail -n 1 | awk '{print $NF}' | tr -d ';')
route add $DEFAULT_ROUTE
YT-DLP
yt-dlp never did fully recover without masquerading. It was partially functional instead of non functional. Some things that helped were --retry-sleep 1 --fragment-retries infinite. It requires a DNS lookup for every single fragment. It seems to hit more latency over wifi & give up.
Network unavailable errors & DNS errors are still limited to 10 retries. When it drops fragments, the audio & video go out of sync. Noted the online downloaders are now afflicted by the same network errors & have begun dropping fragments.
Downloading 2 videos simultaneously or exceeding some kind of quota triggers the login prompt. Odds are better at midnight. There seems to be a peak time when it always gives forbidden or login errors. Another reason to go back to sleeping by day & surfing by night. Lions might just be happiest sleeping from 5am to 1pm.
Did not know they embedded the host name in their IPv6 address.
Comments
Post a Comment