I agree. I have all my servers “in the open”, and only use VPN when I need to route my egress through a different geographical location. The reason I’m saying to use ListenAddress instead is because OP is already got the VPN setup, and seems like not going to change from it. No point introducing yet another piece of complexity such as firewall to the mix when their objective can be achieved with what they’re already using.
chiisana
joined 1 year ago
Also before diving too deep into firewalls, which is a good idea none the less, just go to SSHd config and set ListenAddress to only listen on the VPN network address instead of public IP, and no one can connect via the public IP.
Keep it simple, and add complexity only as needed.
The sign says
was price $7.99$
evening special only $6.99
At the same time, despite what others have said, ho slow. Don’t fall for the all too easy trap of wanting to get the latest and biggest. I ended up with a 2U quad sock server with 256GB RAM… why? Uncalled for and totally not necessary! Start slow and when you find the services you’re hosting no longer performing the speed you’d like, then gradually scale up.
Sounds like something ISP is doing… residential lines tends to have common ports blocked, it may be a good idea to check your terms of service to verify if they permit running servers on the subscribed service.
Depending on jurisdiction, I am not a lawyer, etc etc, but I’d imagine with fairly high degree of probability that re-distribution of CSAM is also a crime.
I started using Authentik lately and am really enjoying the passwordless life. You can set it up such that the authentication flow uses the WebAuthN standard and just prompt the user for passkey or biometric login. Super slick.
Sorry I got slammed by work last couple of days and didn’t check back.
I wonder if it could be asymmetrical routing by your ISP? You mentioned your setup was okay before but it doesn’t work since you changed location.
I think your friend with the UniFi network has a static IP. Can you try traceroute to their IP and see if the route is similar to the one taken by their ISP? I’m not sure if this is how you’d test for asymmetrical routing but if nothing else the symptoms sound similar.
See this page here that explains the Flags: https://opensource.com/article/18/10/introduction-tcpdump
Typically, in a TCP connection, you'd SYN, SYN+ACK, ACK, then transfer actual data over. In the successful sequence, you see this happening as expected.
In the unsuccessful sequence, it seems to be stuck in SYN, SYN+ACK, but there is no ACK that follows (Flags [.]).
Where is the second one captured? On the user's system, or on your system? Something in between is determining the packet isn't intended for the destination and dropping it. It may be a firewall, it may be something else.
We're making progress!
Looks like connection are being made, so it isn't routing after all!
Looking at the first recording, based on the different packet length, I'd guess it is doing SSL handshake properly; whereas the second one seems to be all 0 length and so something is not working out. At least on a cursory glance, your settings seems to be pretty permissive, so unless your friend's using a super old system, it shouldn't be an issue. Do you know what OS your friend is using, and if it has up-to-date root certificates? Are they on a system with openssl cli available? Judging by the unifi network, probably? Try openssl s_client -connect drkt.eu:443 -prexit (and ctrl + c to quit after it stops) and see if you can see any oddities with the SSL handshake process.
I tried this recently and it works pretty well! I haven’t migrate my RancherOS deployment yet though. Need tiny bit more testing.