this post was submitted on 06 Jul 2024
860 points (100.0% liked)
196
17460 readers
575 users here now
Be sure to follow the rule before you head out.
Rule: You must post before you leave.
Other rules
Behavior rules:
- No bigotry (transphobia, racism, etc…)
- No genocide denial
- No support for authoritarian behaviour (incl. Tankies)
- No namecalling
- Accounts from lemmygrad.ml, threads.net, or hexbear.net are held to higher standards
- Other things seen as cleary bad
Posting rules:
- No AI generated content (DALL-E etc…)
- No advertisements
- No gore / violence
- Mutual aid posts require verification from the mods first
NSFW: NSFW content is permitted but it must be tagged and have content warnings. Anything that doesn't adhere to this will be removed. Content warnings should be added like: [penis], [explicit description of sex]. Non-sexualized breasts of any gender are not considered inappropriate and therefore do not need to be blurred/tagged.
If you have any questions, feel free to contact us on our matrix channel or email.
Other 196's:
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
My current work acquired a company with a very poorly provisioned IT department. Their networks all happen to be in the low 192.168.0.0/16 so users VPNing in often end up with wonky IP conflicts. I've heard warnings about similar when selecting subnet ranges, so I just stick with low 192.168.0.0/16 ranges for home networks from which I might potentially VPN into a network I don't control, and I use 172.16.0.0/12 or 10.0.0.0/8 at work as needed and as aligns with our wider topology.
I will also add that I encountered some fun challenges at a small bank I worked at where they clearly under-planned their network and carried a bunch of wonky configs as vestigial networking adaptations as they grew. They did do a cool thing where they made each branch its own /24 subnet so you could tell at a glance exactly what branch someone was connecting from, plus branches could theoretically limp along with an ISP outage, but they didn't the extra steps of setting up edge servers so the end result was a full branch outage during an ISP outage