• 0 Posts
  • 30 Comments
Joined 1 year ago
cake
Cake day: June 12th, 2023

help-circle


  • Not a professional networking guy either but here’s my opinion.

    What I would do is use the ISP router as is, open all ports on it (except to itself, hopefully it doesn’t do that…), and put a firewall in between the router and everything else that controls the actual access to everything behind it (in bridge mode between the two network interfaces of the firewall, so you only have the one network).

    Could a potential second router also assign addresses to devices in that globally routable space directly?

    Devices in IPv6 assign addresses themselves via SLAAC, you just need one device advertising the prefix which the ISP router should already do. The firewall should be able to just purely be there for packet filtering. If you need fixed addresses for public facing servers I would just assign them manually to the respective boxes as you likely also need to add them to public DNS manually anyway.










  • This is a great project. The way it handles mixing markup and code is on point. Also, for drawing its CeTZ is so much nicer than TiKZ, the LaTeX equivalent. I made some great graphics with it for a seminar presentation and paper that I couldn’t have done anywhere near as easily with LaTeX. (The presentation slides I made entirely with Typst, the paper had a LaTeX template that I didn’t feel like remaking because it was huge so I just embedded the graphics I made with Typst)


  • I’m not convinced this is a good idea. Resident keys as the primary mechanism were already a big mistake, syncing keys between devices was questionable at best (the original concept, which hardware keys still have, is the key can never be extracted), and now you’ve got this. One of the great parts about security keys (the original ones!) is that you authenticate devices instead of having a single secret shared between every device. This just seems like going further away from that in trying to engineer themselves out of the corner they got themselves into with bullshit decisions.

    Let me link this post again (written by the Kanidm developer). Passkeys: A Shattered Dream. I think it still holds up.


  • I changed all the KDE shortcuts to be like on Mac (because I like those more). I have a keyboard with Mac layout for my Linux PC and have swapped meta and ctrl via the keyboard settings (i.e. you press ⌘C but software receives ctrl+c), because a lot of non-KDE apps are way worse about remapping shortcuts so if they really want ctrl I at least want it to be on the ⌘ key, and also because the meta key behaves weirdly at least in Qt, for example it doesn’t block text input when held down unlike ctrl.

    These are the big annoyances with this that do trip me up:

    • Terminal (since I’ve switched ⌘ and ⌃, the standard shell keys such as ⌃C are now ⌘C instead because that is unremappable in Konsole, and I’ve had to put copy/paste/etc. on ⌃C etc. instead)
    • Text navigation in Firefox — while I remapped the bindings for KDE/Qt, it’s impossible to do that in Firefox which means ⌥◀︎ is “navigate back” instead of “move caret back one word”. This is the most awful because it keeps making me reload pages when I’m editing text and don’t pay attention
    • Text navigation in KDE/Qt apps — it’s so close to good but I can’t remap the “extend selection word left/right” keys from ⇧⌘◀︎/▶︎ to ⇧⌥◀︎/▶︎ to be like the “move caret” keys (⌥◀︎/▶︎). Same for the select to start/end of line keys.






  • The easy way is to just use tunnelbroker.net, that is what I currently have (this would use one of their assigned net blocks, not the one from the VPS). Set it up on the Pi, set up IP forwarding with appropriate firewall rules, make the Pi serve RA so clients can assign themselves an IP, done (IIRC).

    If you want to set up the v6/v4 gateway yourself, I would do this with a /64 you can fully route to your home network like you would get with tunnelbroker.net because then you don’t have to deal with the network split and essentially two gateways for the same network (your Pi and the VPS), because otherwise your clients would assume the VPS is directly reachable since it’s in the same network when in reality it would have to go through the gateway (you would have to set up an extra route in that case on every client, I think). You’d need a second network from Oracle for this.

    But it’s pretty much the same thing I would assume plus the setup on the VPS side, make the VPN route your /64 block (or use 6in4 which is what tunnelbroker.net uses), configure IP forwarding on the Pi and the VPS between the VPN interface and local/WAN respectively.