• 1 Post
  • 20 Comments
Joined 1 year ago
cake
Cake day: July 8th, 2023

help-circle


  • Yeah you’re correct on the accusations, I should have clarified.

    But with that approach it doesn’t sound like there is anything an organization could do against false accusations that would absolve them of wrongdoing. I’m all for bashing corrupt/horrible companies, but it feels like there should be at least some presumption of innocence unless there is any kind of proof. Painting all accused with the same brush just leads to devaluing the brush IMO. But like you said, people may (and will) believe what they want, and people are under no obligation to watch or support any creator unless they want to. In my case I just haven’t seen any proof of wrongdoing (in this case, gamersnexus controversy was worse IMO).

    What do you think a company should do in that situation, assuming it is being falsely accused? What would a “perfect” response be? I cant think of a much better one than what LTT did, given their circumstances, but would love to hear what a better response would look like.







  • If your data is very important you should definitely prioritize implementing your backup for at least the most important stuff. You could probably move it over, but in case something happens your data will most likely be gone, or best case very hard to recover.

    Fedora is a great distro, but they are decidedly bleeding edge on purpose and IMO not the best choice for a server hosting critical data.

    A better option would be running a hypervisor like proxmox (you can even convert your existing Debian install, but I havent tried this personally) and passing your GPU to a virtual machine that runs fedora.

    This gives you both a very stable environment for your data and and a bleeding edge environment where your hardware decoding likely works great. I do this exact thing personally and it works great.







  • If the firewall cant reach the LAN, either because of a firewall rule or bad routing, it will not be able to access the DNS server even if it works well for the rest of the LAN. I’m assuming that the rest of the LAN talks to the DNS server directly and not through the firewall.

    It sounds like you would benefit from reading a bit about how routing and gateways work, as it seems like you’re mostly trying stuff without really knowing what it does. Please save yourself some sanity and make some proper planning on your different subnets, their vlans and how they should route their traffic, ideally in a diagram of some sort.

    Without knowing your exact setup I’m getting a feeling that your current configuration is both overly permissive and overly restrictive, meaning you cant access the things you want but any potential attackers can probably get around just fine.

    I would seriously consider tearing it down and starting over with a more cohesive plan, but I know that might not be possible for you time-wise. On the other hand, having a well planned network that you understand would almost certainly save you time in the long run, especially if you want to keep doing more advanced and unorthodox stuff to it.


  • First off, if your firewall can ping 8.8.8.8 it can access the WAN, as 8.8.8.8 (hopefully, or you have bigger issues) is on the WAN. It not being able to do updates etc is probably a DNS issue in that case, probably caused by your firewall not being able to access your DNS server due to improper configuration on either the firewall, the switches or the DNS server itself.

    Is your DNS server allowing clients coming from subnets other than its own? Can your Wireguard clients also ping 8.8.8.8? If so, they probably share the DNS issue with your firewall.

    I would recommend trying to debug this iteratively, as this sort of problem has a lot of potential error sources that is hard to know of no matter how many screenshots you provide, like the configuration of your switches and DNS server. Try this:

    1. Computer A cant reach computer B. What is the IP of A? What is the subnet of A? If it is different from the subnet of B, what route should it take to reach B? What is the next step on that route? Can we successfully reach this next step? Does the next hop on the route know where to go to reach the subnet for B? If so, what is the next step? Repeat until we’ve reached B, ideally ensuring each step on the way is acting as it should either trough something like wireguard or the built in tools of your firewall/switch/gateway/etc.

    2. Assuming the problem hasnt been found, repeat from B to A, as responses might not reach us resulting in a broken connection even if we can reach B.

    3. If the routing makes sense, is there a firewall on the way that doesnt allow us to reach B from A? Can we instead reach A from B? If not, we’ve found the problem.

    I would strongly reccomend drawing your network layout (or at least the route you are trying to debug) in a flowchart tool (diagrams.net being a good option), as it is extremely hard to keep track of everything otherwise.