mirror of
https://github.com/mayanayza/netvisor.git
synced 2025-12-10 08:24:08 -06:00
fix: topology auto-reload works for options changes
This commit is contained in:
@@ -229,55 +229,243 @@ netvisor-server:
|
||||
|
||||
## OIDC Setup
|
||||
|
||||
NetVisor supports OpenID Connect (OIDC) for enterprise authentication with providers like Authentik, Keycloak, Auth0, Okta, and others.
|
||||
NetVisor supports OpenID Connect (OIDC) for enterprise authentication with providers like Authentik, Keycloak, Auth0, Okta, PocketID, and others.
|
||||
|
||||
To get started, refer to oidc.toml.example. You can set up multiple OIDC providers by adding entries with a `[[oidc_providers]]` header and the listd fields. Create a copy of the file named oidc.toml and fill the fields for your provider(s).
|
||||
### Quick Start
|
||||
|
||||
### Provider Configuration
|
||||
1. Copy `oidc.toml.example` to `oidc.toml`
|
||||
2. Configure your provider settings (see examples below)
|
||||
3. Mount the file in docker-compose (see [Docker Compose Setup](#oidc-with-docker-compose))
|
||||
4. Restart the server
|
||||
|
||||
**Callback URL**: Configure this in your OIDC provider:
|
||||
### Configuration File Format
|
||||
|
||||
```
|
||||
http://your-netvisor-domain:60072/api/auth/oidc/callback
|
||||
```toml
|
||||
[[oidc_providers]]
|
||||
name = "Provider Name" # Display name in UI
|
||||
slug = "provider-slug" # Used in callback URL (lowercase, no spaces)
|
||||
logo = "https://..." # Optional: logo URL for UI
|
||||
issuer_url = "https://..." # Provider's OIDC issuer URL
|
||||
client_id = "your-client-id"
|
||||
client_secret = "your-client-secret"
|
||||
```
|
||||
|
||||
Or with HTTPS:
|
||||
You can configure multiple providers by adding multiple `[[oidc_providers]]` sections.
|
||||
|
||||
### Callback URL Format
|
||||
|
||||
Configure this URL in your OIDC provider's redirect/callback settings:
|
||||
|
||||
```
|
||||
https://your-netvisor-domain/api/auth/oidc/callback
|
||||
http://your-netvisor-domain:60072/api/auth/oidc/{slug}/callback
|
||||
```
|
||||
|
||||
**Required scopes**:
|
||||
Replace `{slug}` with the slug value from your oidc.toml. For example, if `slug = "authentik"`:
|
||||
|
||||
- `openid` - OIDC standard
|
||||
- `email` - For user email address
|
||||
- `profile` - For user display name (optional)
|
||||
```
|
||||
http://netvisor.local:60072/api/auth/oidc/authentik/callback
|
||||
```
|
||||
|
||||
**Required scopes**: `openid`, `email`, `profile` (profile is optional but recommended)
|
||||
|
||||
### OIDC with Docker Compose
|
||||
|
||||
If you want to use OIDC with NetVisor's docker compose deployment, you'll need to add the following volume mount:
|
||||
Add the following volume mount to your `netvisor-server` service:
|
||||
|
||||
```
|
||||
volumes:
|
||||
- ./oidc.toml:/oidc.toml:ro
|
||||
```yaml
|
||||
services:
|
||||
netvisor-server:
|
||||
image: mayanayza/netvisor-server:latest
|
||||
volumes:
|
||||
- ./oidc.toml:/oidc.toml:ro
|
||||
# ... rest of config
|
||||
```
|
||||
|
||||
### Example: Authentik
|
||||
### Provider-Specific Examples
|
||||
|
||||
1. **Create Application** in Authentik:
|
||||
- Name: NetVisor
|
||||
- Provider: OAuth2/OpenID Provider
|
||||
#### Authentik
|
||||
|
||||
1. **Create Application** in Authentik Admin → Applications → Create:
|
||||
- Name: `NetVisor`
|
||||
- Slug: `netvisor`
|
||||
- Provider: Create a new OAuth2/OpenID Provider
|
||||
|
||||
2. **Configure Provider**:
|
||||
- Redirect URI: `http://netvisor.local:60072/api/auth/oidc/authentik/callback`
|
||||
- Note: the value you use in place of `authentik` in this url for your provider needs to match the `slug` field in oidc.toml.
|
||||
- Scopes: `openid email profile`
|
||||
- Client Type: Confidential
|
||||
- Copy Client ID and Client Secret
|
||||
- Name: `NetVisor OIDC`
|
||||
- Authorization flow: `default-provider-authorization-implicit-consent`
|
||||
- Client type: `Confidential`
|
||||
- Redirect URIs: `http://your-netvisor:60072/api/auth/oidc/authentik/callback`
|
||||
- Copy the Client ID and Client Secret
|
||||
|
||||
3. **Set Variables in oidc.toml**
|
||||
3. **Find your Issuer URL**:
|
||||
- Go to Providers → your provider → OpenID Configuration Issuer
|
||||
- Usually: `https://auth.yourdomain.com/application/o/netvisor/`
|
||||
- **Important**: Remove trailing slash if present (see [Common Issues](#common-oidc-issues))
|
||||
|
||||
4. **Restart server** and test login
|
||||
4. **Configure oidc.toml**:
|
||||
|
||||
```toml
|
||||
[[oidc_providers]]
|
||||
name = "Authentik"
|
||||
slug = "authentik"
|
||||
logo = "https://cdn.jsdelivr.net/gh/homarr-labs/dashboard-icons/svg/authentik.svg"
|
||||
issuer_url = "https://auth.yourdomain.com/application/o/netvisor"
|
||||
client_id = "your-client-id"
|
||||
client_secret = "your-client-secret"
|
||||
```
|
||||
|
||||
#### Keycloak
|
||||
|
||||
1. **Create Client** in Keycloak Admin → Clients → Create:
|
||||
- Client ID: `netvisor`
|
||||
- Client type: `OpenID Connect`
|
||||
- Client authentication: `On`
|
||||
|
||||
2. **Configure Client Settings**:
|
||||
- Valid redirect URIs: `http://your-netvisor:60072/api/auth/oidc/keycloak/callback`
|
||||
- Web origins: `http://your-netvisor:60072`
|
||||
|
||||
3. **Get Credentials**:
|
||||
- Go to Credentials tab
|
||||
- Copy Client Secret
|
||||
|
||||
4. **Configure oidc.toml**:
|
||||
|
||||
```toml
|
||||
[[oidc_providers]]
|
||||
name = "Keycloak"
|
||||
slug = "keycloak"
|
||||
logo = "https://cdn.jsdelivr.net/gh/homarr-labs/dashboard-icons/svg/keycloak.svg"
|
||||
issuer_url = "https://keycloak.yourdomain.com/realms/your-realm"
|
||||
client_id = "netvisor"
|
||||
client_secret = "your-client-secret"
|
||||
```
|
||||
|
||||
#### PocketID
|
||||
|
||||
1. **Create OIDC Client** in PocketID:
|
||||
- Go to OIDC Clients → Add Client
|
||||
- Name: `NetVisor`
|
||||
- Callback URLs: `http://your-netvisor:60072/api/auth/oidc/pocketid/callback`
|
||||
|
||||
2. **Copy Credentials**:
|
||||
- Client ID
|
||||
- Client Secret
|
||||
|
||||
3. **Configure oidc.toml**:
|
||||
|
||||
```toml
|
||||
[[oidc_providers]]
|
||||
name = "PocketID"
|
||||
slug = "pocketid"
|
||||
logo = "https://cdn.jsdelivr.net/gh/homarr-labs/dashboard-icons/svg/pocketid.svg"
|
||||
issuer_url = "https://pocketid.yourdomain.com"
|
||||
client_id = "your-client-id"
|
||||
client_secret = "your-client-secret"
|
||||
```
|
||||
|
||||
#### Auth0
|
||||
|
||||
1. **Create Application** in Auth0 Dashboard → Applications → Create:
|
||||
- Type: `Regular Web Application`
|
||||
- Name: `NetVisor`
|
||||
|
||||
2. **Configure Application Settings**:
|
||||
- Allowed Callback URLs: `http://your-netvisor:60072/api/auth/oidc/auth0/callback`
|
||||
- Allowed Web Origins: `http://your-netvisor:60072`
|
||||
|
||||
3. **Configure oidc.toml**:
|
||||
|
||||
```toml
|
||||
[[oidc_providers]]
|
||||
name = "Auth0"
|
||||
slug = "auth0"
|
||||
logo = "https://cdn.jsdelivr.net/gh/homarr-labs/dashboard-icons/svg/auth0.svg"
|
||||
issuer_url = "https://your-tenant.auth0.com"
|
||||
client_id = "your-client-id"
|
||||
client_secret = "your-client-secret"
|
||||
```
|
||||
|
||||
#### Okta
|
||||
|
||||
1. **Create App Integration** in Okta Admin → Applications → Create:
|
||||
- Sign-in method: `OIDC - OpenID Connect`
|
||||
- Application type: `Web Application`
|
||||
|
||||
2. **Configure Settings**:
|
||||
- Sign-in redirect URIs: `http://your-netvisor:60072/api/auth/oidc/okta/callback`
|
||||
- Sign-out redirect URIs: `http://your-netvisor:60072`
|
||||
|
||||
3. **Configure oidc.toml**:
|
||||
|
||||
```toml
|
||||
[[oidc_providers]]
|
||||
name = "Okta"
|
||||
slug = "okta"
|
||||
logo = "https://cdn.jsdelivr.net/gh/homarr-labs/dashboard-icons/svg/okta.svg"
|
||||
issuer_url = "https://your-org.okta.com"
|
||||
client_id = "your-client-id"
|
||||
client_secret = "your-client-secret"
|
||||
```
|
||||
|
||||
### Common OIDC Issues
|
||||
|
||||
#### "Unexpected issuer URI" error
|
||||
|
||||
```
|
||||
Failed to generate auth URL: Validation error: unexpected issuer URI
|
||||
`https://auth.example.com/app/` (expected `https://auth.example.com/app`)
|
||||
```
|
||||
|
||||
**Cause**: Trailing slash mismatch between your config and what the provider returns.
|
||||
|
||||
**Solution**: Try both with and without trailing slash in `issuer_url`. The value must exactly match what your provider returns in its `.well-known/openid-configuration`.
|
||||
|
||||
To check what your provider expects:
|
||||
```bash
|
||||
curl https://your-provider/.well-known/openid-configuration | jq .issuer
|
||||
```
|
||||
|
||||
#### "Invalid redirect URI" error
|
||||
|
||||
**Cause**: The callback URL in your provider doesn't match what NetVisor sends.
|
||||
|
||||
**Solution**: Ensure the redirect URI in your provider exactly matches:
|
||||
```
|
||||
http://your-netvisor:60072/api/auth/oidc/{slug}/callback
|
||||
```
|
||||
|
||||
Common mistakes:
|
||||
- Wrong protocol (http vs https)
|
||||
- Wrong port
|
||||
- Wrong slug (must match oidc.toml)
|
||||
- Missing `/callback` at the end
|
||||
|
||||
#### OIDC button not appearing in UI
|
||||
|
||||
**Causes**:
|
||||
1. oidc.toml file not mounted in Docker
|
||||
2. oidc.toml has syntax errors
|
||||
3. Server not restarted after adding config
|
||||
|
||||
**Solution**:
|
||||
1. Verify the volume mount exists in docker-compose.yml
|
||||
2. Validate TOML syntax (use a TOML validator)
|
||||
3. Restart with `docker compose restart netvisor-server`
|
||||
4. Check server logs: `docker logs netvisor-server`
|
||||
|
||||
#### "Connection refused" when authenticating
|
||||
|
||||
**Cause**: NetVisor server can't reach your OIDC provider.
|
||||
|
||||
**Solutions**:
|
||||
1. Ensure the provider URL is reachable from the server container
|
||||
2. If provider is internal, ensure Docker can resolve the hostname
|
||||
3. Add provider to Docker's extra_hosts if needed:
|
||||
```yaml
|
||||
extra_hosts:
|
||||
- "auth.internal:192.168.1.100"
|
||||
```
|
||||
|
||||
## Session Security
|
||||
|
||||
|
||||
178
docs/DOCKER_PROXY_GUIDE.md
Normal file
178
docs/DOCKER_PROXY_GUIDE.md
Normal file
@@ -0,0 +1,178 @@
|
||||
# Docker Socket Proxy Guide
|
||||
|
||||
Guide for configuring Docker socket proxies with NetVisor daemons.
|
||||
|
||||
## Table of Contents
|
||||
|
||||
- [Overview](#overview)
|
||||
- [When to Use a Docker Proxy](#when-to-use-a-docker-proxy)
|
||||
- [Supported Proxies](#supported-proxies)
|
||||
- [Configuration](#configuration)
|
||||
|
||||
## Overview
|
||||
|
||||
NetVisor daemons can discover Docker containers by connecting to the Docker API. By default, daemons connect directly to `/var/run/docker.sock`. A Docker socket proxy provides an additional security layer by restricting which Docker API operations are allowed.
|
||||
|
||||
## When to Use a Docker Proxy
|
||||
|
||||
### Direct Socket Access (Default)
|
||||
|
||||
Mount the Docker socket directly:
|
||||
|
||||
```yaml
|
||||
volumes:
|
||||
- /var/run/docker.sock:/var/run/docker.sock:ro
|
||||
```
|
||||
|
||||
**Use when:**
|
||||
- Daemon runs on same host as Docker
|
||||
- You trust the daemon with full Docker API access
|
||||
- Simplest setup
|
||||
|
||||
### Docker Socket Proxy
|
||||
|
||||
Route requests through a proxy:
|
||||
|
||||
```yaml
|
||||
environment:
|
||||
- NETVISOR_DOCKER_PROXY=http://docker-proxy:2375
|
||||
```
|
||||
|
||||
**Use when:**
|
||||
- You want to restrict Docker API operations
|
||||
- Daemon runs in a more restricted security context
|
||||
- Compliance requires limiting Docker access
|
||||
|
||||
## Supported Proxies
|
||||
|
||||
NetVisor has been tested with these Docker socket proxies:
|
||||
|
||||
### Tecnativa docker-socket-proxy
|
||||
|
||||
```yaml
|
||||
services:
|
||||
docker-proxy:
|
||||
image: tecnativa/docker-socket-proxy
|
||||
environment:
|
||||
- CONTAINERS=1 # Required: list and inspect containers
|
||||
- NETWORKS=1 # Required: list networks for subnet discovery
|
||||
- EXEC=1 # Required: exec into containers for endpoint probing
|
||||
- POST=1 # Required: create exec instances
|
||||
- INFO=1 # Optional: system info
|
||||
- BUILD=0
|
||||
- COMMIT=0
|
||||
- CONFIGS=0
|
||||
- DISTRIBUTION=0
|
||||
- GRPC=0
|
||||
- IMAGES=0
|
||||
- NODES=0
|
||||
- PLUGINS=0
|
||||
- SECRETS=0
|
||||
- SERVICES=0
|
||||
- SESSION=0
|
||||
- SWARM=0
|
||||
- SYSTEM=0
|
||||
- TASKS=0
|
||||
- VOLUMES=0
|
||||
volumes:
|
||||
- /var/run/docker.sock:/var/run/docker.sock:ro
|
||||
ports:
|
||||
- "2375:2375"
|
||||
```
|
||||
|
||||
### wollomatic socket-proxy
|
||||
|
||||
```yaml
|
||||
services:
|
||||
docker-proxy:
|
||||
image: wollomatic/socket-proxy
|
||||
environment:
|
||||
- ALLOW_RESTARTS=0
|
||||
- LOG_LEVEL=info
|
||||
volumes:
|
||||
- /var/run/docker.sock:/var/run/docker.sock:ro
|
||||
ports:
|
||||
- "2375:2375"
|
||||
```
|
||||
|
||||
Note: wollomatic's proxy uses allowlists. Refer to their documentation for configuring the required endpoints.
|
||||
|
||||
## Configuration
|
||||
|
||||
### HTTP Proxy (Non-SSL)
|
||||
|
||||
```yaml
|
||||
# Daemon configuration
|
||||
environment:
|
||||
- NETVISOR_DOCKER_PROXY=http://docker-proxy:2375
|
||||
```
|
||||
|
||||
Or via CLI:
|
||||
```bash
|
||||
netvisor-daemon --docker-proxy http://docker-proxy:2375 ...
|
||||
```
|
||||
|
||||
### HTTPS Proxy (SSL)
|
||||
|
||||
For SSL-enabled proxies, provide certificate paths:
|
||||
|
||||
```yaml
|
||||
environment:
|
||||
- NETVISOR_DOCKER_PROXY=https://docker-proxy:2376
|
||||
- NETVISOR_DOCKER_PROXY_SSL_CERT=/certs/client-cert.pem
|
||||
- NETVISOR_DOCKER_PROXY_SSL_KEY=/certs/client-key.pem
|
||||
- NETVISOR_DOCKER_PROXY_SSL_CHAIN=/certs/ca.pem
|
||||
volumes:
|
||||
- ./certs:/certs:ro
|
||||
```
|
||||
|
||||
Or via CLI:
|
||||
```bash
|
||||
netvisor-daemon \
|
||||
--docker-proxy https://docker-proxy:2376 \
|
||||
--docker-proxy-ssl-cert /certs/client-cert.pem \
|
||||
--docker-proxy-ssl-key /certs/client-key.pem \
|
||||
--docker-proxy-ssl-chain /certs/ca.pem \
|
||||
...
|
||||
```
|
||||
|
||||
### Required Docker API Permissions
|
||||
|
||||
NetVisor daemon uses the following Docker API endpoints:
|
||||
|
||||
| Endpoint | Method | Purpose |
|
||||
|----------|--------|---------|
|
||||
| `/containers/json` | GET | List running containers |
|
||||
| `/containers/{id}/json` | GET | Get container details (ports, networks, config) |
|
||||
| `/networks` | GET | List Docker networks for subnet discovery |
|
||||
| `/exec/{id}/json` | GET | Check exec instance status |
|
||||
| `/containers/{id}/exec` | POST | Create exec instance for endpoint probing |
|
||||
| `/exec/{id}/start` | POST | Start exec to probe HTTP endpoints inside containers |
|
||||
|
||||
**Note on exec**: NetVisor uses `exec` to probe HTTP endpoints from inside containers. This enables service detection for containers that don't expose ports to the host. If you disable exec access, containers will still be discovered but service detection accuracy may be reduced.
|
||||
|
||||
### Common Issues
|
||||
|
||||
#### "Connection refused" to proxy
|
||||
|
||||
1. Verify proxy is running: `docker ps | grep proxy`
|
||||
2. Check proxy is listening: `curl http://docker-proxy:2375/version`
|
||||
3. Ensure daemon can reach proxy (same Docker network or exposed port)
|
||||
|
||||
#### "Permission denied" from proxy
|
||||
|
||||
Proxy is blocking required endpoints. For Tecnativa, ensure:
|
||||
- `CONTAINERS=1`
|
||||
- `NETWORKS=1`
|
||||
- `EXEC=1` (for endpoint probing)
|
||||
- `POST=1` (required for exec)
|
||||
|
||||
#### SSL certificate errors
|
||||
|
||||
1. Verify certificate paths are correct and mounted
|
||||
2. Check certificate is valid: `openssl x509 -in /certs/client-cert.pem -text -noout`
|
||||
3. Ensure CA chain is included if using self-signed certs
|
||||
|
||||
---
|
||||
|
||||
For daemon configuration options, see [CONFIGURATION.md - Daemon Configuration](CONFIGURATION.md#daemon-configuration).
|
||||
@@ -231,6 +231,41 @@ netvisor-daemon --concurrent-scans 10 ...
|
||||
|
||||
See [CONFIGURATION.md](CONFIGURATION.md#concurrent-scans) for recommended values.
|
||||
|
||||
### "Too Many Open Files" Error
|
||||
|
||||
**Symptoms**: `Critical error scanning: Too many open files (os error 24)` in daemon logs
|
||||
|
||||
**Causes**: System file descriptor limit is too low for the configured concurrent scans.
|
||||
|
||||
**Solutions**:
|
||||
|
||||
1. **Reduce concurrent scans** (easiest):
|
||||
```yaml
|
||||
environment:
|
||||
- NETVISOR_CONCURRENT_SCANS=10
|
||||
```
|
||||
|
||||
2. **Increase system file descriptor limit**:
|
||||
```bash
|
||||
# Check current limit
|
||||
ulimit -n
|
||||
|
||||
# Increase temporarily
|
||||
ulimit -n 65535
|
||||
|
||||
# Increase permanently (add to /etc/security/limits.conf)
|
||||
* soft nofile 65535
|
||||
* hard nofile 65535
|
||||
```
|
||||
|
||||
3. **For Docker**: Add to your daemon container:
|
||||
```yaml
|
||||
ulimits:
|
||||
nofile:
|
||||
soft: 65535
|
||||
hard: 65535
|
||||
```
|
||||
|
||||
### Port Already in Use
|
||||
|
||||
**Symptoms**: Server fails to start with "address already in use"
|
||||
@@ -255,6 +290,56 @@ newgrp docker
|
||||
|
||||
Log out and back in for changes to take effect.
|
||||
|
||||
### Browser Shows "SSL Protocol Error"
|
||||
|
||||
**Symptoms**: Browser displays "ERR_SSL_PROTOCOL_ERROR" or "SSL protocol is too long" when accessing NetVisor
|
||||
|
||||
**Cause**: Attempting to access the HTTP server using HTTPS.
|
||||
|
||||
**Solution**: Use `http://` (not `https://`) to access NetVisor directly:
|
||||
```
|
||||
http://your-server:60072
|
||||
```
|
||||
|
||||
If you need HTTPS, configure a reverse proxy (Traefik, Nginx, Caddy) in front of NetVisor to handle TLS termination.
|
||||
|
||||
### PostgreSQL "Could not create any Unix-domain sockets" (Proxmox)
|
||||
|
||||
**Symptoms**: PostgreSQL container fails to start on Proxmox host with socket creation error
|
||||
|
||||
**Cause**: AppArmor security policy blocking socket creation.
|
||||
|
||||
**Solution**: Add to both PostgreSQL and NetVisor services in docker-compose.yml:
|
||||
|
||||
```yaml
|
||||
security_opt:
|
||||
- apparmor:unconfined
|
||||
```
|
||||
|
||||
See [issue #87](https://github.com/mayanayza/netvisor/issues/87) for details.
|
||||
|
||||
### Discovery Takes Extremely Long (Hours)
|
||||
|
||||
**Symptoms**: Network discovery takes 10+ hours to complete
|
||||
|
||||
**Causes**:
|
||||
1. Large Docker bridge networks (e.g., /16) being fully scanned
|
||||
2. Multiple large subnets selected for a single discovery
|
||||
|
||||
**Solutions**:
|
||||
|
||||
1. **Check selected subnets**: In your Network Scan discovery, verify you haven't selected large Docker bridge networks (like 172.17.0.0/16)
|
||||
|
||||
2. **Use Docker discovery separately**: Run Docker discovery to discover containers, rather than scanning Docker bridge networks via Network Scan
|
||||
|
||||
3. **Reduce subnet scope**: Only select subnets that contain hosts you want to discover
|
||||
|
||||
### Daemon Stops When Terminal Closes
|
||||
|
||||
**Symptoms**: Daemon runs in foreground and stops when SSH session ends
|
||||
|
||||
**Solution**: Install as a systemd service (see [Systemd Service](#systemd-service-linux) above), or run with a process manager like `screen` or `tmux`.
|
||||
|
||||
## Uninstalling
|
||||
|
||||
### Docker Installation
|
||||
|
||||
144
docs/MULTI_VLAN_GUIDE.md
Normal file
144
docs/MULTI_VLAN_GUIDE.md
Normal file
@@ -0,0 +1,144 @@
|
||||
# Multi-VLAN Deployment Guide
|
||||
|
||||
Guide for deploying NetVisor across multiple VLANs and network segments.
|
||||
|
||||
## Table of Contents
|
||||
|
||||
- [Overview](#overview)
|
||||
- [When You Need Multiple Daemons](#when-you-need-multiple-daemons)
|
||||
- [Deployment Strategies](#deployment-strategies)
|
||||
- [Step-by-Step Setup](#step-by-step-setup)
|
||||
- [Network Requirements](#network-requirements)
|
||||
|
||||
## Overview
|
||||
|
||||
NetVisor uses daemons to discover hosts and services. The integrated daemon can scan networks it has direct access to, but isolated VLANs require additional daemons.
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────────────┐
|
||||
│ NetVisor Server │
|
||||
│ (192.168.1.10:60072) │
|
||||
└─────────────────────────┬───────────────────────────────────┘
|
||||
│
|
||||
┌─────────────────┼─────────────────┐
|
||||
│ │ │
|
||||
▼ ▼ ▼
|
||||
┌───────────────┐ ┌───────────────┐ ┌───────────────┐
|
||||
│ VLAN 1 │ │ VLAN 2 │ │ VLAN 3 │
|
||||
│ Production │ │ IoT │ │ Guest │
|
||||
│ 192.168.1.0/24│ │ 192.168.2.0/24│ │ 192.168.3.0/24│
|
||||
│ [Daemon 1] │ │ [Daemon 2] │ │ [Daemon 3] │
|
||||
└───────────────┘ └───────────────┘ └───────────────┘
|
||||
```
|
||||
|
||||
## When You Need Multiple Daemons
|
||||
|
||||
### Single Daemon is Sufficient When:
|
||||
|
||||
- All hosts are on the same subnet as the daemon
|
||||
- You have a management host with routes to all VLANs
|
||||
- Your firewall allows the daemon to reach all subnets
|
||||
- You don't need MAC addresses from isolated networks
|
||||
|
||||
### Multiple Daemons Required When:
|
||||
|
||||
- VLANs are isolated by firewall rules
|
||||
- You need accurate MAC address collection (requires Layer 2 access)
|
||||
- Different networks have different security requirements
|
||||
|
||||
## Deployment Strategies
|
||||
|
||||
### Strategy 1: Daemon Per VLAN (Recommended)
|
||||
|
||||
Deploy a lightweight daemon on each VLAN.
|
||||
|
||||
**Pros:** Full Layer 2 access (MAC addresses, ARP), no inter-VLAN firewall rules needed, best discovery accuracy
|
||||
|
||||
**Cons:** More daemons to manage, requires a host on each VLAN
|
||||
|
||||
**Best for:** Production environments, security-conscious deployments
|
||||
|
||||
### Strategy 2: Central Daemon with Routing
|
||||
|
||||
Use a single daemon on a host that can route to all VLANs.
|
||||
|
||||
**Pros:** Single daemon to manage
|
||||
|
||||
**Cons:** No MAC address collection for remote subnets, requires firewall rules, Layer 3 only
|
||||
|
||||
**Best for:** Small networks, lab environments, quick setup
|
||||
|
||||
### Strategy 3: Hybrid Approach
|
||||
|
||||
Central daemon for routable networks, dedicated daemons for isolated segments.
|
||||
|
||||
## Step-by-Step Setup
|
||||
|
||||
### Step 1: Plan Your Deployment
|
||||
|
||||
| VLAN | Subnet | Purpose | Daemon Location |
|
||||
|------|--------|---------|-----------------|
|
||||
| 1 | 192.168.1.0/24 | Production | netvisor-server host |
|
||||
| 10 | 192.168.10.0/24 | IoT | IoT management VM |
|
||||
| 20 | 192.168.20.0/24 | Guest | Guest network AP |
|
||||
|
||||
### Step 2: Create Daemon in NetVisor UI
|
||||
|
||||
1. Navigate to **Manage > Daemons**
|
||||
2. Click **"Create Daemon"**
|
||||
3. Select the target network
|
||||
4. Choose daemon mode:
|
||||
- **Push**: Server initiates scans (daemon must be reachable from server)
|
||||
- **Pull**: Daemon polls for work (daemon only needs outbound access to server)
|
||||
5. Click **"Generate Key"**
|
||||
6. Copy the installation command
|
||||
|
||||
### Step 3: Deploy Daemon
|
||||
|
||||
Follow the installation instructions in [INSTALLATION.md - Additional Daemons](INSTALLATION.md#additional-daemons).
|
||||
|
||||
For Docker container discovery on the daemon host, see [DOCKER_PROXY_GUIDE.md](DOCKER_PROXY_GUIDE.md).
|
||||
|
||||
### Step 4: Configure Discovery
|
||||
|
||||
1. Navigate to **Discover > Scheduled**
|
||||
2. Click **"Create Discovery"**
|
||||
3. Select the daemon you deployed
|
||||
4. Choose **Network Scan**
|
||||
5. Select subnets to scan
|
||||
6. Set schedule or run manually
|
||||
|
||||
### Step 5: Verify
|
||||
|
||||
1. Run a manual discovery from **Discover > Sessions**
|
||||
2. Check **Manage > Hosts** for discovered devices
|
||||
3. Verify **Topology** shows hosts from all VLANs
|
||||
|
||||
For consolidating hosts that appear on multiple VLANs, see [USER_GUIDE.md - Consolidating Hosts](USER_GUIDE.md#consolidating-hosts).
|
||||
|
||||
## Network Requirements
|
||||
|
||||
### Firewall Rules for Pull Mode (Recommended)
|
||||
|
||||
Daemon initiates all connections. Minimal firewall changes needed.
|
||||
|
||||
| Source | Destination | Port | Protocol | Purpose |
|
||||
|--------|-------------|------|----------|---------|
|
||||
| Daemon | Server | 60072 | TCP | API communication |
|
||||
| Daemon | Local subnet | * | TCP | Network scanning |
|
||||
|
||||
### Firewall Rules for Push Mode
|
||||
|
||||
Server initiates scan requests. Daemon must be reachable.
|
||||
|
||||
| Source | Destination | Port | Protocol | Purpose |
|
||||
|--------|-------------|------|----------|---------|
|
||||
| Server | Daemon | 60073 | TCP | Push scan requests |
|
||||
| Daemon | Server | 60072 | TCP | Report results |
|
||||
| Daemon | Local subnet | * | TCP | Network scanning |
|
||||
|
||||
---
|
||||
|
||||
For troubleshooting daemon and discovery issues, see [INSTALLATION.md - Troubleshooting](INSTALLATION.md#troubleshooting).
|
||||
|
||||
**Need help?** Join our [Discord](https://discord.gg/b7ffQr8AcZ) or [open an issue](https://github.com/mayanayza/netvisor/issues/new).
|
||||
@@ -21,7 +21,7 @@ class TopologySSEManager extends BaseSSEManager<Topology> {
|
||||
if (get(autoRebuild)) {
|
||||
const currentTopo = get(topology);
|
||||
if (currentTopo && currentTopo.id === update.id && !currentTopo.is_locked) {
|
||||
rebuildTopology(currentTopo);
|
||||
rebuildTopology(update);
|
||||
}
|
||||
return;
|
||||
}
|
||||
|
||||
Reference in New Issue
Block a user