### на базе Red Hat

- `firewall-cmd --zone=public --add-masquerade --permanent`
- `firewall-cmd --reload`

### На базе Debian
#### firewall Ubuntu - ufw

```
# Установка UFW
sudo apt update
sudo apt install ufw

# Открываем порт, используемый для SSH (по умолчанию 22)
sudo ufw allow <ssh-port>/tcp

# Закрываем все входные
sudo ufw default deny incoming
sudo ufw default allow outgoing

# Включаем фаерволл
sudo ufw enable
# Перезагрузить
ufw reload

# Показать состояние ufw и активные правила
sudo ufw status verbose
ufw status numbered
```
```
# Отключить фаерволл
sudo ufw disable

# Удалить правило (будут применены настройки по умолчанию)
sudo ufw delete allow <port>/<protocol> # удалить разрешение
sudo ufw delete deny <port>/<protocol> # удалить запрет

# Сброс всех правил
sudo ufw reset

# Вывести логи ufw
sudo tail -f -n 100 /var/log/ufw.log

# Изменить уровень логирования
sudo ufw logging <low/medium/high>

# Разрешить доступ ко всем портам с определённого IP-адреса
sudo ufw allow from <IPv4>

# Разрешить доступ к порту с определённого IP-адреса
sudo ufw allow from <IPv4> to any port <port>
```
```
# Пресеты
# Вывести список пресетов
sudo ufw app list

# Открыть все соединения, которые нужны Nginx
sudo ufw allow "Nginx Full"

# Удалить правило для пресета
sudo ufw delete allow "Nginx Full"
```
```
# Интерфейсы
sudo ufw allow in on wg0
sudo ufw allow out on wg0
```


Да, все данные в конечном счёте передаются в бинарном виде, потому что сеть работает с битами и байтами.
Но разница в том, как и где происходит эта "бинаризация" данных.

⚡ HTTP/1.1: Текстовый протокол с бинарной передачей на сетевом уровне
Формат данных: человекочитаемый текст (например, заголовки GET / HTTP/1.1 и тело в формате JSON).
Процесс передачи:
Сервер создаёт текстовый HTTP-запрос.
Когда данные отправляются через сетевой стек (TCP/IP), они преобразуются в биты и байты для физической передачи.
Важно: серверу и клиенту нужно "читать" эти текстовые данные, что добавляет накладные расходы на парсинг и обработку.
🚀 HTTP/2: Бинарный протокол уже на уровне приложения
Формат данных: заголовки и служебные данные сразу преобразуются в бинарные фреймы ещё до того, как они попадут в сетевой стек.

Процесс передачи:

Сервер упаковывает запросы в бинарные фреймы (например, HEADERS, DATA), ещё на уровне приложения.
Эти бинарные фреймы напрямую передаются по TCP, без дополнительной текстовой обработки.
Преимущества:

Меньше накладных расходов на парсинг.
Эффективнее сжатие заголовков (HPACK).
Возможность мультиплексирования (несколько запросов в одном соединении).
🤖 gRPC (на HTTP/2): Максимальная бинаризация
Здесь бинаризация идёт ещё глубже:
Сами данные (не только заголовки) сериализуются в бинарный формат с помощью Protobuf.
Это даёт ещё большую производительность по сравнению с текстовыми форматами (например, JSON).
🎯 Краткий вывод:
HTTP/1.1: текстовый формат на уровне приложения → преобразование в биты на уровне сети.
HTTP/2: бинарный формат уже на уровне приложения → передача в сеть без дополнительного преобразования.
gRPC: данные бинаризуются ещё глубже (через Protobuf) и передаются поверх HTTP/2.
Если нужно, могу показать примеры пакетов в Wireshark для наглядности. 🚀