I have recently finished a project that involves local DNS and DHCP servers. Basically, I was given a black box IoT device that is configured to connect to a certain server, and I must redirect its connection to my own custom server without being able t…
I have recently finished a project that involves local DNS and DHCP servers. Basically, I was given a black box IoT device that is configured to connect to a certain server, and I must redirect its connection to my own custom server without being able to change the device's configuration.
Nothing nefarious about what I'm doing here. The client wanted everything to be managed by a local control system, but the supplier provided no API to integrate into a local system, they only provided API to interact with their public data server, which then issues MQTT packets to the device. Bypassing the public server wasn't supported.
I think it's a good time to brush up on the Network Engineering lectures I attended a decade ago.
Acquiring an IP address
When a device connects to a network, it does so with a "Network interface". The network interfaces come with their unique "MAC address" that can be attached to an "IP address". A device with two network interfaces, WLAN and Ethernet for example, can connect to two different networks at the same time and possess two different IP addresses at the minimum.
Within the IP protocol suite, there are some one-to-one (unicast) protocols and there are some one-to-all broadcast protocols. A new device to the network will broadcast a message looking for the network's "DHCP" or the authority server responsible for managing IP addresses within the network. All devices within the network will receive this message.
The DHCP server, usually operated by the router, will then offer the new device an IP address and the IP address of a "default gateway". The default gateway is usually also the router itself (192.168.1.1 for most routers).
This tells the new device who the boss of the network is.
Sending packets
There are two ways to address a data packet: with "IP address" and with "domain name".
A "DNS" or "Domain Name System" server is responsible for translating domain names into IP addresses. Every device can decide for itself which DNS server it will use. Those that have no preference will just use the DNS server provided by the default gateway.
If the said router is connected to the internet, the DNS server will, by default, be the ISP's DNS server. This does give the ISP (and governments) power to block certain domain names from resolving, and this is why querying Google DNS or Open DNS can sometimes bypass censorship. That is, of course, if the government doesn't also use the DNS to block IP addresses of these other websites as well.
By configuring the router to direct all clients to a local DNS server, it is possible to assign human-readable domain names that are valid only within the local network.
Hosting local DHCP
On to the project itself...
I don't have a router in the local network, everything was connected using switches, and I cannot manually set the IP address of the IoT device in question, I have to begin by setting up a local DHCP server. The ESP8266 can run a DHCP server for its own wifi networks so I wouldn't need one when I used it as a shell for the IoT device.
But, in the end, I ended up using OpenDHCP on a server machine within the local network after the scope of the project was later expanded.
Hosting local DNS
The local network also did not use a DNS server. Therefore, I hosted one on an ESP8266. Someone on the internet was helpful enough to provide a solution here and it does work with some modifications:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
The ESP8266 has two separate "network interfaces" when it operates in hybrid mode, acting as a router access point (AP) and a station (STA) at the same time. It can attach its DHCP and DNS only to the AP interface for interactions with the IoT device itself while manually setting its own IP address to its STA interface.
This is a sort of a man-in-the-middle attack where the device thought it was talking to a public server, but it was, in fact, talking to the ESP8266 who acted as its container in the local network.
Somewhat intrigued by the work, the client then requested to assign human-readable domain names to other devices in the local network. They helpfully provided some space on their main server machine for a DNS and DHCP server.
Also, they weren't exactly a fan of the cheap-looking ESP8266.
MaraDNS can handle multiple domain names and a lot more lookup requests than ESP8266.
The second scope expansion of this project involved connecting similar local networks using a site-wide wifi network, which has its own DNS and DHCP from the ISP. I have investigated the possibility of using double NAT, as in, putting a second router behind the entire network's first router.
DHCPs are first come, first serve so the DHCP of the second router would be prioritized by the merit of proximity to the client device. In fact, most routers have the option to run their own subnet which must not overlap with its WAN's subnet.
Devices behind the second router (network B) can access devices in the first router's network (network A) but it's not possible to access devices within a third router's network (network C) because there is no valid subnet matching network C within network A. All packets would be dropped while in network A.
A more viable solution I'm considering is virtual LAN (VLAN) but that does require accessing the configuration of the first router, which the site management is hesitant to permit.
In VLAN, all devices operate on the same physical infrastructure, but each has its own "parallel universe" VLAN tag layer.
No comments:
Post a Comment