Проблемы с файерволом PF в FreeBSD

Вопрос или проблема

У меня есть выделенный сервер OVH, на который я установил Proxmox. Я создал 2 виртуальные машины: одну FreeBSD в качестве фаервола / NAT-шлюза и сервер Debian в одной и той же локальной сети с фаерволом, используя FreeBSD как шлюз.

На виртуальной машине FreeBSD есть две сетевые карточки: одна для WAN, другая для LAN.

С FreeBSD у меня есть доступ в интернет, я могу выполнять ping, telnet и т.д. – все работает с фаервола / шлюза.

С сервера Debian я могу пинговать интернет, я могу пинговать 8.8.8.8.

У меня несколько проблем:

  • С сервера Debian команда telnet 1.1.1.1 53, но telnet 8.8.8.8 53 не работает (поэтому я настроил /etc/resolv.conf на 1.1.1.1, чтобы иметь возможность использовать домены, но эта проблема довольно странная)
  • С сервера Debian команда telnet google.com 80 не работает (она работает с фаервола FreeBSD)
  • Когда я пытаюсь подключиться к своему ПК через SSH или telnet с IP 2223 на сервере Debian, я вижу пакеты с помощью tcpdump (на сервере Debian), но я получаю таймаут на команде

Вот что я вижу в своих логах, когда выполняю команду doas tcpdump -n -e -ttt -i pflog0:

(telnet 8.8.8.8 53)  00:00:00.000010 правило 19/0(совпадение): пропуск в vtnet1: 91.121.40.45.52818 > 8.8.8.8.53: Флаги [S], seq 688104303, win 64240, options [mss 1460,sackOK,TS val 3854927016 ecr 0,nop,wscale 7], длина 0
(telnet 1.1.1.1 53)  00:00:00.000010 правило 19/0(совпадение): пропуск в vtnet1: 91.121.40.45.53578 > 1.1.1.1.53: Флаги [S], seq 537632035, win 64240, options [mss 1460,sackOK,TS val 3337238453 ecr 0,nop,wscale 7], длина 0
(telnet google.com 80)  00:00:00.000004 правило 19/0(совпадение): пропуск в vtnet1: 91.121.40.45.60204 > 142.250.178.14.80: Флаги [S], seq 556080316, win 64240, options [mss 1460,sackOK,TS val 2506116294 ecr 0,nop,wscale 7], длина 0
(когда я подключаюсь с клиента к серверу debian по ssh)  

00:00:01.249859 правило 18/0(совпадение): пропуск в vtnet1: мой ip.63990 > 192.168.10.10.2223: Флаги [S], seq 2851206258, win 64240, options [mss 1460,sackOK,TS val 3746771 ecr 0,nop,wscale 7], длина 0
 00:00:00.000005 правило 17/0(совпадение): пропуск в vtnet0: мой ip.63990 > 192.168.10.10.2223: Флаги [S], seq 2851206258, win 64240, options [mss 1460,sackOK,TS val 3746771 ecr 0,nop,wscale 7], длина 0

Вот мои правила:

## Макросы
ext_if = "vtnet1"     # Внешний интерфейс (WAN)
int_if = "vtnet0"     # Внутренний интерфейс (LAN)

ext_ip = "91.121.40.45"
int_ip = "192.168.10.1"

# Определите IP внутреннего сервера
internal_server = "192.168.10.10"
int_network = "192.168.10.0/24"

# Услуги, разрешенные для исходящего трафика
tcp_pass_out = "{ bootpc, bootps, dhcpv6-client, dhcpv6-server, domain, https, ipp, nicname, ntp, ssh, www, 6667, 6697 }"
udp_pass_out = "{ bootpc, bootps, dhcpv6-client, dhcpv6-server, domain, nicname, ntp }"
icmp_ok_types = "{ echoreq, unreach }"

# Таблицы для разрешенных IP для доступа по SSH и FTP
table <allowed_ssh> persist file "/etc/hh.d/acls/hh_home.txt"
table <allowed_ftp> persist file "/etc/hh.d/acls/hh_home.txt"

table <private> const { 10/8, 172.16/12, 192.168/16 }

## Разрешите свободный трафик на интерфейсе обратной связи lo0
set skip on lo0

## Нормализация и сборка пакетов
scrub in all

## Преобразование (NAT для внутренней сети)
nat on $ext_if from $int_network to any -> ($ext_if)
## Перенаправление портов (для доступа по SSH и FTP)
rdr on $ext_if proto tcp from <allowed_ssh> to $ext_if port 2223 -> $internal_server
rdr on $ext_if proto tcp from <allowed_ftp> to $ext_if port {20, 21, 10000:19999} -> $internal_server

## Фильтрация

# Политика по умолчанию: блокировать все
#block all

### Фильтры ###
# Разрешить любые пакеты из внутренней сети к любому
pass in on $int_if inet from $int_network to any keep state

## Разрешить входящие соединения SSH от разрешенных IP
## Порт 2222 фаервол freebsd
pass in on $ext_if proto tcp from <allowed_ssh> to $ext_if port 2222 keep state
## Порт 2223 веб-сервер
pass in on $ext_if proto tcp from <allowed_ssh> to $ext_if port 2223 keep state

## Разрешить входящие соединения FTP (порты 20, 21, пассивный диапазон 10000-19999) от разрешенных IP
pass in on $ext_if proto tcp from <allowed_ftp> to $ext_if port {20, 21, 10000:19999} keep state

## Разрешить трафик HTTP (80) и HTTPS (443) для всех
pass in on $ext_if proto tcp from any to $ext_if port { 80 443 } flags S/SA keep state

## Разрешить трафик DNS и NTP
pass in on $ext_if proto { tcp udp } from any to $ext_if port { domain ntp } keep state

pass out on $int_if from any to $int_if:network keep state

pass out on $ext_if proto tcp all modulate state flags S/SA
pass out on $ext_if proto { udp, icmp } all keep state

# Разрешить и логировать все пакеты от клиентов в частной сети через NAT
pass in log on $int_if all
pass out log on $int_if all
pass in log on $ext_if all
pass out log on $ext_if all

Спасибо заранее за ваши советы / помощь!

С уважением,

Максим

Ответ или решение

Привет, Максime!

Давайте разберем ваши проблемы с конфигурацией брандмауэра PF (Packet Filter) на FreeBSD. У вас есть несколько проблем, связанных с передачей TCP и NAT. Мы постараемся решить их по порядку.

Проблемы с telnet и DNS:

  1. Проблемы с telnet 8.8.8.8 53:

    • Вы можете пинговать 8.8.8.8, но соединение через telnet не устанавливается. Это может быть связано с тем, что ваш брандмауэр PF блокирует исходящие подключения к этому порту. Проверьте, что в правилах PF есть разрешение на исходящие соединения по UDP и TCP для порта 53 (DNS).
    • Попробуйте добавить следующее правило перед блокировками, чтобы разрешить DNS:

      pass out on $ext_if proto { tcp, udp } from any to any port 53 keep state
  2. Проблемы с telnet google.com 80:

    • Убедитесь, что порт 80 доступен для внешнего трафика. Вы уже добавили правило для разрешения трафика на порты 80 и 443. Однако для отладки можешь временно отключить другие правила для проверки.
    • Вы можете использовать curl вместо telnet для диагностики HTTP-запросов, так как это даст больше информации о проблеме.

Проблемы с SSH:

  1. Проблемы SSH и timeouts:
    • Вы видите пакеты с помощью tcpdump, но соединение завершилось таймаутом. Это может указывать на блокировку входящих соединений на вашем Debian-сервере или проблеме с конфигурацией NAT.
    • Убедитесь, что на дебиян-сервере установлен и запущен SSH-сервер и что он слушает на порту 2223.
    • Поскольку вы перенаправляете порт 2223 на внутренний сервер, убедитесь, что ваш сервер принимает подключения и не блокирует их с помощью iptables или других средств.

Общие рекомендации:

  • Убедитесь, что у вас есть политика по умолчанию для блокировки всех входящих соединений (block all). Ваша конфигурация должна начинаться с блокировки всех.

  • Возможно, вам стоит перенастроить вашу конфигурацию PF, чтобы упростить тестирование, например:

# Разрешаем все исходящие соединения
pass out on $ext_if all

# Разрешаем входящие соединения для SSH (настраиваем только порт 2223)
pass in on $ext_if proto tcp from <allowed_ssh> to any port 2223 keep state
  • Наконец, убедитесь, что у вас нет других брандмауэров на Debian-сервере, которые могут блокировать входящий трафик или порты.

Логи:

Смотрите логи /var/log/pflog, чтобы получить больше информации о том, какие пакеты блокируются, и на основе этого корректируйте правила.

Если у вас остались вопросы или возникли другие проблемы, пожалуйста, дайте знать. Удачи с настройкой брандмауэра!

С уважением,
[Ваше Имя]

Оцените материал
Добавить комментарий

Капча загружается...