228 lines
6.6 KiB
Markdown
228 lines
6.6 KiB
Markdown
|
||
|
||
---
|
||
|
||
## 🧩 Цель
|
||
|
||
- Разделить пользователей на **группы**:
|
||
- `public` — публичный доступ ко всем общедоступным сайтам.
|
||
- `internal` — сотрудникам доступны внутренние сервисы (git, jira и т.д.).
|
||
- `client-X` — клиенты с доступом только к своему поддомену (`client1.site.com`, `client2.site.com`).
|
||
|
||
- Каждая группа имеет свои **IP-подсети**.
|
||
- Каждый домен/поддомен имеет список разрешённых групп.
|
||
|
||
---
|
||
|
||
# ✅ Архитектура решения
|
||
|
||
## 1. **Группы как файлы IP-диапазонов**
|
||
|
||
Создаём отдельные файлы для каждой группы, где указываем её IP-разрешения:
|
||
|
||
```
|
||
/etc/angie/groups/public.conf
|
||
/etc/angie/groups/internal.conf
|
||
/etc/angie/groups/client1.conf
|
||
/etc/angie/groups/client2.conf
|
||
...
|
||
```
|
||
|
||
### Пример: `/etc/angie/groups/public.conf`
|
||
```nginx
|
||
allow all;
|
||
```
|
||
|
||
> Или точнее:
|
||
```nginx
|
||
deny all;
|
||
```
|
||
|
||
Но если нужна фильтрация, то:
|
||
|
||
```nginx
|
||
allow 0.0.0.0/0; # все IP
|
||
```
|
||
|
||
### Пример: `/etc/angie/groups/internal.conf`
|
||
```nginx
|
||
allow 192.168.1.0/24;
|
||
allow 10.10.0.0/16;
|
||
deny all;
|
||
```
|
||
|
||
### Пример: `/etc/angie/groups/client1.conf`
|
||
```nginx
|
||
allow 203.0.113.0/24;
|
||
deny all;
|
||
```
|
||
|
||
---
|
||
|
||
## 2. **Конфигурации доменов с подключением групп**
|
||
|
||
Для каждого домена или поддомена создаётся конфиг, который подключает нужные группы через `include`.
|
||
|
||
### Пример: `/etc/angie/conf.d/site1.com.conf`
|
||
```nginx
|
||
server {
|
||
listen 80;
|
||
server_name site1.com www.site1.com;
|
||
|
||
location / {
|
||
# Публичный доступ + сотрудники
|
||
include /etc/angie/groups/public.conf;
|
||
include /etc/angie/groups/internal.conf;
|
||
|
||
proxy_pass http://192.168.10.10:8080;
|
||
proxy_set_header Host $host;
|
||
}
|
||
}
|
||
```
|
||
|
||
### Пример: `/etc/angie/conf.d/git.site1.com.conf`
|
||
```nginx
|
||
server {
|
||
listen 80;
|
||
server_name git.site1.com;
|
||
|
||
location / {
|
||
# Только сотрудники
|
||
include /etc/angie/groups/internal.conf;
|
||
|
||
proxy_pass http://192.168.10.11:3000;
|
||
proxy_set_header Host $host;
|
||
}
|
||
}
|
||
```
|
||
|
||
### Пример: `/etc/angie/conf.d/client1.site.com.conf`
|
||
```nginx
|
||
server {
|
||
listen 80;
|
||
server_name client1.site.com;
|
||
|
||
location / {
|
||
# Только клиент 1
|
||
include /etc/angie/groups/client1.conf;
|
||
|
||
proxy_pass http://192.168.20.10:8000;
|
||
proxy_set_header Host $host;
|
||
}
|
||
}
|
||
```
|
||
|
||
---
|
||
|
||
## 3. **Как управлять динамически?**
|
||
|
||
Ты хочешь, чтобы при добавлении нового клиента или сайта всё происходило автоматически.
|
||
|
||
### 📦 Шаги:
|
||
|
||
1. Получаешь данные о новом клиенте:
|
||
```json
|
||
{
|
||
"name": "client3",
|
||
"domain": "client3.site.com",
|
||
"backend": "192.168.20.30:8080",
|
||
"allowed_ips": ["198.51.100.0/24"]
|
||
}
|
||
```
|
||
|
||
2. Генерируешь файл группы:
|
||
```
|
||
/etc/angie/groups/client3.conf
|
||
```
|
||
|
||
С содержимым:
|
||
```nginx
|
||
allow 198.51.100.0/24;
|
||
deny all;
|
||
```
|
||
|
||
3. Генерируешь конфиг сервера:
|
||
```
|
||
/etc/angie/conf.d/client3.site.com.conf
|
||
```
|
||
|
||
Содержимое:
|
||
```nginx
|
||
server {
|
||
listen 80;
|
||
server_name client3.site.com;
|
||
|
||
location / {
|
||
include /etc/angie/groups/client3.conf;
|
||
|
||
proxy_pass http://192.168.20.30:8080;
|
||
proxy_set_header Host $host;
|
||
}
|
||
}
|
||
```
|
||
|
||
4. Отправляешь обновлённый конфиг в Angie через `/control`:
|
||
```bash
|
||
curl -X POST http://localhost/control/nginx --data-binary @client3.site.com.conf
|
||
```
|
||
|
||
---
|
||
|
||
## 🔄 Автоматизация всего процесса
|
||
|
||
Можно написать небольшой **API-сервис**, который:
|
||
|
||
- Принимает запросы на создание/обновление/удаление групп и сайтов.
|
||
- Генерирует конфиги на основе шаблонов.
|
||
- Обновляет конфиг в Angie через `/control`.
|
||
- Хранит данные в БД (например, PostgreSQL или Redis).
|
||
|
||
Пример структуры такого API:
|
||
|
||
| Метод | URL | Описание |
|
||
|-------|----------------------------|----------------------------------|
|
||
| POST | `/api/group` | Создать группу |
|
||
| POST | `/api/domain` | Создать новый домен |
|
||
| DELETE| `/api/domain/{domain}` | Удалить домен |
|
||
| GET | `/api/status` | Проверить текущие правила |
|
||
|
||
---
|
||
|
||
## 🔐 Как работает проверка доступа?
|
||
|
||
Когда клиент делает запрос:
|
||
|
||
1. Angie проверяет IP по `allow/deny` из файла группы.
|
||
2. Если IP не проходит — возвращает `403 Forbidden`.
|
||
3. Если проходит — проксирует запрос на бэкенд.
|
||
|
||
---
|
||
|
||
## 🧠 Полезные советы
|
||
|
||
- Для тестирования используй `curl -H 'Host: domain.com' http://<proxy-ip>/` чтобы эмулировать хост.
|
||
- Все изменения применяются без перезапуска благодаря `/control`.
|
||
- Логи помогут отладить ACL: `access_log` и `error_log`.
|
||
|
||
---
|
||
|
||
## 🎯 Вывод
|
||
|
||
Ты можешь легко реализовать **гибкую систему контроля доступа по группам** в **Angie**, если:
|
||
|
||
- Хранишь группы как файлы с IP-диапазонами.
|
||
- Подключаешь их через `include` в нужные домены.
|
||
- Генерируешь конфиги автоматически.
|
||
- Используешь `/control` API для динамического обновления.
|
||
|
||
---
|
||
|
||
## 🚀 Нужны примеры кода?
|
||
|
||
Если ты хочешь, могу показать:
|
||
|
||
- Пример Python-скрипта, который создаёт группу и домен.
|
||
- Пример шаблона конфига с Jinja2.
|
||
- Пример работы с `/control`.
|
||
|
||
Напиши, и я подготовлю! |