add sandbox-iot-network
This commit is contained in:
parent
320202afb7
commit
8ea7d31918
BIN
docs/photos/iot_sandbox_network.png
Normal file
BIN
docs/photos/iot_sandbox_network.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 32 KiB |
112
docs/posts/sandbox-iot-network.md
Normal file
112
docs/posts/sandbox-iot-network.md
Normal file
@ -0,0 +1,112 @@
|
||||
---
|
||||
title: "Sandbox IOT Network"
|
||||
date: 2024-04-27
|
||||
draft: false
|
||||
tags: ["RaspberryPi", "linux", "router", "wireguard", "tasmota"]
|
||||
authors: ["trent"]
|
||||
post: 34
|
||||
---
|
||||
date: 2024-04-27
|
||||
|
||||
|
||||
## Introduction
|
||||
This is a scheme for connecting your smart devices to an sandboxed subnet
|
||||
such that they cannot reach or be reached from anywhere outside of their subnet,
|
||||
with the only exception being that each smart device can reach, and be reached
|
||||
from an application server.
|
||||
|
||||
Using a wireguard tunnel between the application server and (wifi) ap server both enables the
|
||||
flow of traffic between the application server and smart devices on the sandboxed
|
||||
subnet, but also encrypts the mqtt traffic.
|
||||
|
||||
|
||||
<figure>
|
||||
<img src=../../photos/iot_sandbox_network.png width="100%" />
|
||||
<figcaption>iot sandbox network</figcaption>
|
||||
</figure>
|
||||
|
||||
## Hostapd
|
||||
First install `hostapd` on your RaspberryPi. The relevant config file is
|
||||
`/etc/hostapd/hostapd.conf`. And then start/enable hostapd with `systemctl`.
|
||||
|
||||
## Describe Wifi AP interface
|
||||
Without explicitly routing traffic between eth0 and wlan0, no devices connecting
|
||||
to the wifi ap will be able to reach, or be reached from, the internet or your
|
||||
home network.
|
||||
```conf
|
||||
# /etc/network/interfaces.d/wlan0
|
||||
|
||||
auto wlan0
|
||||
iface wlan0 inet static
|
||||
address 10.0.8.1
|
||||
network 10.0.8.0
|
||||
netmask 255.255.255.0
|
||||
broadcast 10.0.8.255
|
||||
```
|
||||
|
||||
## Install and configure dnsmasq (for dhcp)
|
||||
Each device connecting to the wifi ap will need to know its' ip address,
|
||||
therefore you can use dnsmasq for dhcp service.
|
||||
|
||||
Assuming you can figure out how to navigate the tasmota webui of each device
|
||||
well enough to set the hostname and figure out the mac addr,
|
||||
on the RaspberryPi wifi ap install dnsmasq and edit the config file.
|
||||
```conf
|
||||
# /etc/dnsmasq.conf
|
||||
listen-address=10.0.8.1
|
||||
interface=wlan0
|
||||
dhcp-range=10.0.8.150,10.0.8.200
|
||||
dhcp-host=bedroomlight,34:ab:95:c5:27:15,10.0.8.2
|
||||
dhcp-host=kitchenlight,40:f5:20:11:a9:5d,10.0.8.3
|
||||
dhcp-host=bathroomlight,70:03:9F:C5:7C:4C,10.0.8.4
|
||||
|
||||
```
|
||||
|
||||
## Create Wireguard Tunnel Between Application Server and Wifi AP
|
||||
The wireguard tunnel both encrypts traffic between the application
|
||||
server and the wifi ap server, but also enables communication between the
|
||||
dashboard application server and the smart devices. The devil is in the
|
||||
configuration details.
|
||||
|
||||
I think you need to enable forwarding in sysctl on the wifi ap server so
|
||||
that traffic can pass between `wlan0` and `wg0` (but I'm not entirely positive).
|
||||
```conf
|
||||
# /etc/sysctl.conf
|
||||
net.ipv4.ip_forward=1
|
||||
```
|
||||
|
||||
Configure wg-quick@wg0 on the wifi ap server as follows.
|
||||
```conf
|
||||
# /etc/wireguard/wg0.conf
|
||||
[Interface]
|
||||
Address = 10.88.1.1/24
|
||||
PrivateKey = <private key>
|
||||
ListenPort = 4449
|
||||
|
||||
[Peer]
|
||||
PublicKey = <public key>
|
||||
AllowedIPs = 10.88.1.2/32
|
||||
```
|
||||
|
||||
Configure wg-quick@wg0 on the application server as follows.
|
||||
** The magic is in the `AllowedIPs` value. **
|
||||
```conf
|
||||
[Interface]
|
||||
Address = 10.88.1.2/24
|
||||
PrivateKey = <private key>
|
||||
|
||||
[Peer]
|
||||
PublicKey = <public key>
|
||||
AllowedIPs = 10.0.88.0/24,10.0.8.0/24
|
||||
Endpoint = 192.168.1.88:4444
|
||||
PersistentKeepalive = 25
|
||||
```
|
||||
|
||||
## Next Step
|
||||
The next step, not represented in the diagram, is to attach your
|
||||
application server to a second wireguard tunnel such that it can be
|
||||
reached from your client devices.
|
||||
|
||||
Note that you can also double-nat the application server in this scheme, because why not?
|
||||
Everything happens inside wireguard tunnels. In my diagram the application server
|
||||
is an virtual machine that is double-natted on an `libvirt` subnet.
|
@ -24,6 +24,7 @@ markdown_extensions:
|
||||
nav:
|
||||
- Home:
|
||||
- Home: index.md
|
||||
- "Sandbox IOT Network": posts/sandbox-iot-network.md
|
||||
- "QuasselCore on Debian 11": posts/quasselcore-on-debian-11.md
|
||||
- "Forklift Upgrade Arch Linux To A Dell Precision 3561": posts/forklift-upgrade-arch-linux-precision-3561.md
|
||||
- "Ansible KVM Router Lab Part 6": posts/ansible-kvm-router-lab-part-6.md
|
||||
@ -71,6 +72,7 @@ nav:
|
||||
- FreeCodeCampChallenges: https://trentspalmer.github.io/fcc-challenges/
|
||||
- DeviceLayout: https://trentpalmer.work/6a57bbe24d8244289610bf57533d6c6f/
|
||||
- Posts:
|
||||
- "Sandbox IOT Network": posts/sandbox-iot-network.md
|
||||
- "QuasselCore on Debian 11": posts/quasselcore-on-debian-11.md
|
||||
- "Forklift Upgrade Arch Linux To A Dell Precision 3561": posts/forklift-upgrade-arch-linux-precision-3561.md
|
||||
- "Ansible KVM Router Lab Part 6": posts/ansible-kvm-router-lab-part-6.md
|
||||
|
Loading…
Reference in New Issue
Block a user