lemmyvore

How to physically isolate a camera with OpenWRT, tagged VLANs and Docker Having fought for several days with this, I’d thought it would be worth sharing while it’s still fresh in what’s left of my mind: Problem: OpenWRT router running latest available version (25.12) and Luci UI. IP cam that I want hardwired-only (Ethernet). Cam must have no access to internet or rest of LAN. Cam must only be accessed directly by the NVR software. Software (NVR and reverse proxy) run as docker containers on server PC. Any other LAN device (laptop, phone) must be able to access the NVR only via the reverse proxy. Network topology: Cam is plugged physically in lan1 port on router. Server is plugged physically in lan3 port on router. The problem above basically means we need two tagged VLANs, one for regular LAN devices, and one just for NVR and camera. Configuring the VLANs in OpenWRT: Before anything else: try doing the next batch of configs from wireless if possible not Ethernet, in case you mess up and lose wired connectivity to the router. Go to Network > Interfaces > Devices and press “Configure” for the bridge that holds your router ports. This will typically be called “br-lan”. Go to the “Bridge VLAN filtering” tab and check “enable Vlan filtering”. Press the “Add” button twice to get two VLANs. First VLAN: set id=1, check “local”, mark lan1=off (not member), lan2=untagged, lan3=tagged (also primary), lan4=untagged. You can use any ID but “1” is traditional for the base LAN network. Second VLAN: set id=100, check “local”, mark lan1=untagged, lan2=off, lan3=tagged, lan4=off. Again, you can use any ID, but it’s traditional to avoid numbers under 10 because they’re typically used for core VLANs. Case in point, please note that my router has two physical NICs, one for LAN ports 1-4 and one for WAN, so I have a separate br-wan device just for wan. But some routers only have one physical NIC so they only have one bridge that covers both lan1-4 and wan ports. On these routers when you get to the filtering tab you will find two VLANs (1 and 2, typically) already set up. If this is the case add the VLAN 100 and modify VLAN 1 as above and mark wan as off in 100. After you press “save” you will notice two new virtual devices called “br-lan.1” and “br-lan.100” type VLAN 802.1q have appeared in the device list. Do not apply modifications yet. First go to Network > Interfaces, edit the “lan” interface and switch it from device “br-lan” to device “br-lan.1”, otherwise you may lose connectivity to router if you’re on Ethernet. If you’ve applied changes early and lose connectivity, don’t panic, just wait. In recent OpenWRT versions after 90s without confirmation from the UI the router will automatically rollback the last changes. If all went well and you’re on wireless or one of the untagged Ethernet ports (lan2 or lan4) you should have retained connectivity to the router and wireless devices. Configuring the NVR network in OpenWRT: Go to Network > Interfaces, click “Add new interface”. Call it “NVR”, protocol “static address”, device “br-lan.100”. Next, edit it and set up your desired IPv4 address and netmask. You MUST go to “firewall settings” and use the “custom” field to add a new “NVR” zone. alternatively you can go to Network > Fireall, create the NVR zone there, and choose it here. Enable DHCP if you want. If you do, please note that some routers bind dnsmasq only explicitly to select interfaces. Please check under Network > DHCP > dnsmasq > Devices & Ports and if “non-wildcard” is checked you will have to add “NVR” to the “Listen interfaces” to actually get DHCP services on that network. Under Network > Firewall you should have a zone called “NVR”. Set input/output/forward to accept/accept/reject. Under Network > Firewall > Traffic rules you have to add a new rule, calld it “NVR DHCP”, that says that protocol UDP, source zone “NVR”, destination “device (input)”, destination port 67, action “accept”, and under advanced restrict address family to IPv4. Traffic rules have priority over zone configuration so DHCP will work no matter how you fuck up your zone access. We will be skipping DNS because we don’t want the NVR network to benefit from any. But if we did we’d be doing the same we did for DHCP (got to Network > DNS to enable explicitly on NVR interface, and add a traffic rule for it). Configuring the camera: Plug the camera into port lan1, it should pick up a DHCP address on the network you’ve defined for interface “NVR”. In order to be able to access that IP from your regular LAN to configure the camera with your phone you’ll have to temporarily add the “NVR” zone to the list of forward zonez of the “lan” zone. Would probably be a good idea to either configure the camera to a static IP or give it a static DHCP assignment based on the Ethernet MAC, so you know where to reach it from the NVR software. Remember to remove the “NVR” zone from the lan’s zone forwards when you’re done. Configuring the server for tagged VLAN connectivity: Your server (port lan3) was marked for tagged VLAN connectivity in OpenWRT but it doesn’t (yet) actually use tagged connections. We have to fix that or it won’t be reachable. Feel free to mark lan3 as “untagged” on VLAN 1 to connect to it while you change the settings, but keep in mind that direct console access may be needed if you fuck up. My server runs Debian so configuration basically runs down to loading module 8021q (and adding it to /etc/modules just in case, although this should be largely automated), and editing /etc/network/interfaces. Feel free to adjust the example below to your needs: # this will bring up eth0 but leave it unconfigured, merely as a support carrier for the VLANs auto eth0 iface eth0 inet manual # this will set up VLAN ID 1 and tell it to use DHCP auto eth0.1 iface eth0.1 inet dhcp # this will set up VLAN ID 100 with a static address auto eth0.100 iface eth0.100 inet static address 10.234.100.2/24 Configuring docker networks and containers: Remember I said the proxy and the NVR are running in docker containers. If you haven’t done anything fancy with them before, you were probably using ports: to expose a port for the proxy and one for the NVR on the host’s LAN IP, and pointing the proxy to the NVR. First, we will want to make an ipvlan or macvlan docker network that will use the eth0.100 interface. Containers that use this network will be placed in the NVR network/zone, and have their communications tagged with VLAN ID 100. Feel free to customize the network range. You can use either ipvlan or macvlan, the latter is not very useful since docker can’t do DHCP. Note the use of aux-address to reserve the IP you’ve assigned the camera, in case there’s potential overlap with the range you choose for automatic allocation. It’s essential that you use the eth0.100 interface as parent. docker network create --driver ipvlan \ --ip-range=10.234.100.97/27 --subnet=10.234.100.0/24 --gateway=10.234.100.1 \ --aux-address 'cam1=10.234.100.10' \ -o parent=eth0.100 nvr-vlan We also need a bridge network that will allow the proxy to see the NVR container, because once the NVR container is placed on the NVR network on the VLAN ID 100 it won’t be reachable directly by the proxy. docker network create --driver bridge \ --opt com.docker.network.bridge.name=br-docker-proxy \ --ipv4 --subnet=172.23.1.0/24 --gateway=172.23.1.1 \ proxy-bridge Next, in the NVR container compose, join both proxy-bridge and nvr-lan: services: nvr: networks: nvr-vlan: proxy-bridge: hostname: nvr networks: nvr-vlan: external: true proxy-bridge: external: true Also in the proxy container compose you will want to join the proxy-bridge network. Remove the ports: directive from the NVR container, it doesn’t serve any purpose now. Containers on ipvlan/macvlan are reachable by their native port assignments on the networks they’ve joined. Please note the hostname: nvr in the NVR compose, that’s the name you will have to use in the proxy configuration to reach the NVR. Docker will supply a DNS resolve for this automatically. The proxy doesn’t need to be on nvr-vlan. I mean you can, but you need to keep the proxy accessible from the main network so it will keep using ports: as usual. Bibliography: docs.docker.com/engine/network/drivers/ipvlan/#ma… openwrt.org/docs/…/switch_configuration openwrt.org/docs/guide-user/…/converting-to-dsa openwrt.org/docs/guide-user/…/dsa-mini-tutorial forum.openwrt.org/t/openwrt-vlan-tagging/208098 computingforgeeks.com/how-to-configure-vlan-inter… wiki.debian.org/NetworkConfiguration#Howto_use_vl… manpages.debian.org/…/interfaces.5.en.html deepwiki.com/openwrt/…/6.1-zone-configuration deepwiki.com/openwrt/firewall4/7-rules-and-nat

It supports it on the iOS client as well but last time I tried it would always lose the mTLS setting on its own after a while. I had to resort to the other method they offer, secret key in a custom HTTP header.

I can give you an indefinite, unrestricted license to do whatever but I still own the copyright. Isn’t this distinction academic?

You may be right about liability, I don’t know. But public domain is a thing in the EU and it applies to expired copyright, things that cannot be copyrighted, explicit attribution etc. Besides, the MIT license does not renounce copyright, on the contrary.

I would second this. They key as a beginner I think is to choose a distro with a reasonable release cycle, give yourself some room to breathe. Debian is too slow, their release cycle is basically 2 years. You could use Testing or Unstable instead of Stable but they’re not officially meant for public consumption and come with no guarantees. It’s great as a minimalist, rock-solid foundation for a server where stability is paramount but not great for any purpose with a faster pace of technology. Arch-based distros on the other hand are extremely fast (“rolling distro”). Most of them sit in the range between “drinking from the firehose” (release packages as fast as they come in) to something like 2 weeks for a “slow” distro like Manjaro. Distros like Mint, Fedora, Ubuntu, PopOS have ~6 month release cycles so you end up with reasonably recent packages but not too recent to catch all the new bugs.

Is the cleaning lady also a company founder?

Graphene choosing to die on the hardware MTE hill has always seemed weird to me. It’s one feature but it excludes 99% of the phones except the Pixel. GrapheneOS has so much to offer besides it, and nowadays they could use Rust as a workaround anyway.

They’re already using Alma. There are more complaints not just the compile flag.

If those individuals want to distance themselves from a Nazi movement, they can do so. They can put out statements clarifying their association. RMS battling cancer is an extreme case.

I mean, it wasn’t, but X11 also took like 20 years to get to where Xorg took over, and then Xorg has been puttering for another 15. Dunno what it is with Linux graphics that lends itself to such long development cycles. …I mean I do know, it’s some of the worst possible stacks that benefits the least from the bazaar approach.

There are models that will try out unencrypted wifi AP just to phone home. No extra equipment needed and unfortunately the chances of finding an open AP are pretty good in the middle of the city.

Tagged VLANs would be needed regardless, because I have only one server with one physical connection and I wanted to have processes on it on 2 different networks. Docker is neither here nor there, you’re right it’s not needed for the solution. I was using it anyway, I know lots of selfhosters do, and it does make it easy to create an ipvlan and put an app on it. Docker is not the only way to achieve containerization but I do appreciate and use containerization (and virtualization). It lets the host OS stay simpler and cleaner and prevents the various apps from messing with it. It makes it easy to control each app’s environment. You can do app containers, system containers or VMs as needed. It makes it easy to back up, restore and reproduce an app and its state, independently of the host OS or any other app. Abstractions help… they empower you to do more. You invest some time into learning, sure, but it pays off later in time saved managing and the ability to do more complex stuff faster. Troubleshooting is what it is. Nothing’s perfect, you’re going to end up troubleshooting something sometime not matter what you use.

I did initially do it with the firewall alone. I created a “br-nvr” device, moved lan1 from br-lan to it, and used br-nvr as the device for the NVR interface and firewall zone, then selectively let my phone and the NVR app from the LAN zone access the camera ports with traffic rules. Everything else about the interface and zone stayed the same as they are now. (That’s what’s great about the OpenWRT abstractions. ) The one major issue with that approach was that the NVR app is outside the NVR zone and I wanted it in there. It makes broadcasting a non-issue, (I I really don’t want to have to learn how to do cross-network broadcasts and I understand they’re fraught with problems anyway). Better security with less complexity. A single camera can have like 3 ports that need to be made accessible, and different cameras will have different ports. Making and maintaining traffic rules for multiple cameras would rapidly turn into a nightmare. With the NVR app in the same isolated network as the cameras they can do whatever they want in there without needing explicit rules. But I couldn’t put the NVR docker container into the NVR network, because it lives on a machine on the LAN network, and you can’t have the host machine on one network and a app on it in another network, with a single physical cable… unless you use tagged VLANs. There are also some potential annoyances in the future if I ever want to move cables around the ports or make more complex setups, the VLAN abstraction makes things easier.

What are they getting for their money? It’s a marketing campaign to devalue Linux in the public eye. If they can state that AI came up with a “good enough” distro you know what non-savvy people will think about it: that making a distro is “easy”, and “anybody can do it”, and that anybody involved with making distros “manually” is redundant and giving themselves airs etc. It has already happened to many other fields.

I’m not an expert so take this with a grain of salt, but it seemed to me that the driver approach is the more useful abstraction and also the more modern, and that the old one will get eventually phased out (or stay there under the hood, out of the way).

Don’t all the games have to be uploaded to Steam by their rightful developer?

Ok to clarify, I mean if Occulus devs want to publish their games to Steam, they can. But Valve won’t add anybody’s games for them to Steam.

It’s not you (an informed user) that they’re after, it’s about public perception of Linux. I would go as far as to say Omarchy is an attack on all Linux distros. It’s the notion that you can just “dial up some tech” that has been doing widespread harm to all branches of IT, shaking up the public trust in technology and confusing what “reliable” means for IT. If Omarchy succeeds in having AI create a usable Linux distro it would fundamentally alter the optics of “manually” created distros and the public’s trust in them. And it probably can, given massive amounts of money and resources. Hence all the millions being poured into it. It’s the old “embrace, extend, extinguish” strategy in a new form.

Not for lack of trying, mind you. Previous attempts were eventually thwarted after decade-long efforts, which is also how this one looks like it’s shaping up. It’s also worth pointing out that in previous cases there were champions of the industry that stood up for Linux and countered with equal amounts of money into things like lawsuits and marketing on the supporting side. Furthermore this attack is of the FUD variety (fear, uncertainty and doubt) which is harder to counter.

They’re saying Graphene without MTE is less secure, which isn’t something they want. Well they’re inevitably backing into a dead-end. MTE is obviously off the table now which means eventually they’ll have no hardware fitting to their super-exacting demands. Motorola might come through, or not. I hate being a conspiracy theorist but honestly sometimes the way Graphene clings to Pixels feels like a Google scheme to boost their pathetic Pixel market share.

I think Wayland deserves some blame for taking the hard line on security. Every other security policy software lets you move the slider between max security or no security at all. But not Wayland, mommy knows best. Honestly, Wayland and Gnome deserver each other, both projects have the same insufferable approach where they think their users are idiots.

In this particular case it wasn’t Docker that gave me the headaches, it was OpenWRT and wrapping my head around tagged VLANs. Once you have the VLANs working on the router and the tagged interfaces up on the server, pointing a Docker network or an LXC at the eth0.100 interface is equally easy. Now, when I first got the camera I was considering adding a secondary network card to the server and plugging the camera into that, so it would be directly hardwired into the machine running the NVR. If I had done that I was given to understand that taking ownership of a physical NIC would have been much easier with LXC than with Docker. (We’ll never know because I couldn’t find the PCI network card.)