Initial commit: DHCP whitelist service for direct link connections
Features: - Docker-based DHCP server with MAC address whitelisting - Binds to specific ethernet interface only - NO DNS/gateway advertised (direct link only, not a router) - Configurable network parameters (subnet, DHCP range, lease times) - Systemd service integration for Arch/Manjaro - Test environment with isolated network (172.20.0.0/24) - Auto-configuration script to detect network settings - Complete Makefile with management targets Security: - Only responds to whitelisted MAC addresses - deny unknown-clients configuration - Runs in Docker container for isolation Configuration: - Copy .example files to create your config - interface.conf: Network interface to bind to - whitelist.conf: Allowed MAC addresses - network.conf: Network parameters (optional)
This commit is contained in:
@@ -0,0 +1,57 @@
|
||||
# DHCP Direct Link Only Service - Development Notes
|
||||
|
||||
## Project Overview
|
||||
This project creates a DHCP server that only responds to whitelisted MAC addresses on a specific ethernet interface. It's designed for direct link connections where only authorized devices should receive IP addresses, without any routing or DNS services.
|
||||
|
||||
## Configuration Features
|
||||
- Binds to specific ethernet interface (configurable)
|
||||
- MAC address whitelisting (configurable)
|
||||
- NO DNS servers advertised (direct link only)
|
||||
- NO gateway/router advertised (not a NAT setup)
|
||||
- Configurable network parameters (subnet, range, lease times)
|
||||
|
||||
## Architecture Decisions
|
||||
|
||||
### Why Docker?
|
||||
- Isolation from host system
|
||||
- Easy deployment and management
|
||||
- Consistent environment across different systems
|
||||
- Simple cleanup and removal
|
||||
|
||||
### Why ISC DHCP Server?
|
||||
- Mature, stable DHCP implementation
|
||||
- Extensive configuration options
|
||||
- Good documentation
|
||||
- Supports MAC address filtering natively
|
||||
|
||||
### Network Mode: Host
|
||||
The container uses host network mode because:
|
||||
- DHCP requires direct access to the physical network interface
|
||||
- DHCP uses raw sockets that don't work well with Docker's bridge networking
|
||||
- We need to bind to a specific physical interface
|
||||
|
||||
## Implementation Details
|
||||
|
||||
### Whitelist Implementation
|
||||
The whitelist is implemented using ISC DHCP's host declarations with a deny unknown-clients directive. This ensures only explicitly defined MAC addresses receive leases.
|
||||
|
||||
### Configuration Management
|
||||
- Local configs in `config/` for development
|
||||
- System configs in `/etc/dhcp-whitelist/` for production service
|
||||
- Auto-config script detects network settings automatically
|
||||
|
||||
### Testing Strategy
|
||||
- Isolated Docker network for testing
|
||||
- Separate test client containers
|
||||
- Tests both allowed and denied MAC scenarios
|
||||
|
||||
## Known Limitations
|
||||
1. MAC addresses can be spoofed - this is not a security solution by itself
|
||||
2. Requires host network mode which reduces container isolation
|
||||
3. Only one instance can run per interface
|
||||
|
||||
## Future Enhancements
|
||||
- Web UI for managing whitelist
|
||||
- Logging and monitoring
|
||||
- Multiple interface support
|
||||
- Integration with network authentication systems
|
||||
Reference in New Issue
Block a user