lemmyvore

You should not have to open such a permissive rule. Like you’ve seen, docker will set firewall rules as needed if you have services that actually need to listen on the public interface.

If you’ve run that permissive input command on the VPS it’s most likely not a good idea.

What exactly are you trying to do? If you’re trying to use curl from inside a docker container that is not the correct way to achieve that. In fact you should not need to do anything like that, outside connections should be allowed (OUTPUT), and incoming collections (INPUT) should be allowed only if they’re related to an already ongoing connection (look up the ESTABLISHED flag).

Any extra flag you can offer that would narrow things down would also be welcome. When you write firewall rules you should be as restrictive as possible. For example since this is curl you’re probably going to connect to ports 80 and 443 so you can add --dport to restrict the ports to the OUTPUT rule. And you should specify the interface (in this case docker0) in almost all cases.

What does “old network” and “new network” mean? What are they, LAN setup? Docker setup? Describe them better (netmasks, routing etc.)

Claws-Mail is still alive and well and works great. Lots of plugins, you can write your own post processing actions, custom powerful filters, customizable interface etc.

You. Don’t. Store. Secrets. In. Plaintext.

SSH stores the secret keys in plaintext too. In a home dir accessible only by the owning user.

I won’t speak about Windows but on Linux and other Unix systems the presumption is that if your home dir is compromised you’re fucked anyway. Effort should be spent on actually protecting access to the home personal files not on security theater.

The IRC bots that run these sharing channels will crap themselves if hit with any kind of automation. Many/most have limited bandwidth and use a queueing system that only serves one or two downloads at a time and a small queue (it varies, some may have a 10 slot queue, some may have 50 or 100).

It’s GPL, they have to also provide the source. And you benefit from all the rights they do.

“Business” licenses try to prevent competition while still benefiting from free contributions, and pass it as “fairness”. But how is it fair for anybody except that particular company? What about the contributors? If OBS used such a license and reaped all the benefits would you still contribute to them?

I love that website. Now I have an easy way to find all the licenses and projects and companies I need to stay away from.

First of all, have you stacking the public and private subdomains on the same base domain? It’s what I do at the moment, I have external services on *.mydomain.com and internal services on *.home.mydomain.com.

You can get one wildcard cert for *.mydomain.com and one for *.local.mydomain.com so all your services are protected by TLS, both inside and outside your LAN. You also get to manage all of them identically in the same place (Traefik in your case).

You do NOT have to define any of these domains in DNS in order to pass the Let’s Encrypt DNS challenge. LE doesn’t care what you’ll put in DNS, just wants to verify the domain is yours. So just giving it an API token with access to mydomain.com is enough. (If your DNS provider doesn’t offer API check out this list of providers.)

It’s important to understand that the reverse proxy doesn’t actually care about DNS and whether those domains resolve, it just looks for the domain in the HTTP headers. So you can define those domains anywhere you want. You have several options:

1. For the public subdomains you need to define them in your public DNS, so you can resolve them from anywhere on the Internet. Let’s say your server IP is 1.2.3.4. You define an A record pointing mydomain.com to 1.2.3.4, and a wildcard CNAME that points *.mydomain.com to mydomain.com. Now all the subdomains directly under mydomain.com resolve to that IP.
2. For the private subdomains you have several options:
   • Best approach is to do the same as above for *.home.mydomain.com, but do in on the private DNS used on your LAN, and point to the LAN IP of your server instead of your public IP.
   • If for whatever reason your LAN DNS can’t do this (or you can’t control it) you can put the entries in the public DNS. It’s a bit unorthodox putting private LAN stuff in a public DNS but it works.
   • You can even define sub.home.mydomain.net names in the local hosts file on your PC, if you only need to access them from the PC. You only need to trick your browser into resolving them so it will put them in the HTTP headers, the reverse proxy doesn’t care.

An important note about security, because someone has already mentioned this in another comment. There are malware bots that keep scanning domains and IPs and ports looking for apps, and then they try exploits to try to break in. Having services exposed publicly without an extra authentication in front can make you vulnerable to these bots. It’s not a question of if they’ll find your app, it’s a question of when. You can mitigate the risk by blacklisting IPs in your router, for example you can blacklist anything that’s not coming from your country, but that only reduces the surface, does not completely eliminate the threat.

The bots also scan issued Let’s Encrypt certificates (which are a matter of public record) which is why it’s important to only get wildcard (*.mydomain.com) certificates, never explicit subdomains (sub.mydomain.com). It’s also important to never link to your services from web pages or share them with others.

Assuming you keep the subdomains for yourself, and you get a wildcard cert, and you use a reverse proxy, and you make the domain not easy to guess (don’t use something like “calendar.mydomain.com”) then you can very effectively prevent bots from getting to your services. That’s because the reverse proxy won’t honor requests if it doesn’t recognize the full domain name. So the subdomain can act as a sort of access key if you make it long enough (63 chars limit per subdomain, 255 max limit on the entire domain). That’s a pretty respectable key length… as long as you don’t publish it anywhere (only define it on the reverse proxy and your phone for example).

OP hasn’t purchased any book. They’re on a plan that lets them listen to any book for free, except it’s time-limited.

When you “cast” from the phone to the Chromecast, what happens it that the phone gives the Chromecast an URL where it can find the stream to play. The phone can read that stream because it’s connected to the Tailscale VPN. The Chromecast isn’t, so the stream URL is inaccessible to it. You see the Jellyfin logo because that’s a feature of casting (the app on the phone gives the Chromecast a logo to show).

There’s no point in announcing the subnet from your laptop, because your laptop is not a router for the local LAN. You can use this to reach local LAN devices from remote Tailscale nodes but not the other way around.

Some possible solutions:

1. You enable the hotspot feature on the phone while connected to Tailscale, and connect the Chromecast to the wifi of the phone. But the stream will consume the cellular connection, because you’re using the phone’s wifi for the hotspot (the phone only has one wifi interface so it cannot use it both to connect to the local LAN and for hotspot).
2. If you connect the local laptop to the router with a wired connection you can use its wifi as hotspot, connect the laptop to Tailscale, connect the Chromecast to the laptop hotspot, and the stream will arrive over the local connection.
3. You can try to install Tailscale on the router, if it runs OpenWRT or something similar, and if it has enough storage space (the Tailscale packages are kinda large). If you announce the subnet from the router then it will work as intended and all the devices on the local LAN will be able to “see” the remote laptop.
4. If you’re using nginx as reverse proxy with TLS certificates for the remote Jellyfin you can try this: expose it to the internet without Tailscale and use nginx-ip-whitelister to temporarily allow access from your local LAN’s public IP. All devices in the local LAN will see the remote Jellyfin. But read the warnings on the project page, it’s not as secure as a VPN. And of course “expose jellyfin to the internet” is not as simple as it sounds (you need a domain, you need to get Let’s Encrypt certs, a public IP, a port forward etc.)

Because “critical of western propaganda” is a front for promoting authorianism and intolerance. The “western propaganda” they’re critical of include human rights, inclusiveness, social security etc.