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

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

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

На виртуальной машине с FreeBSD установлены 2 сетевых интерфейса: один для 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], length 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], length 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], length 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], length 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], length 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"

# Услugi, разрешенные для исходящего трафика
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 }

## Позволяем свободный трафик на интерфейсе loopback 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 firewall 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

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

С уважением,

Максим

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

Здравствуйте, Максим.

Проблемы, которые вы описали, могут быть связаны с несколькими аспектами настройки вашего PF (Packet Filter) в FreeBSD. Давайте разберем каждую из них и предложим возможные способы решения.

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

Вы можете успешно пинговать 8.8.8.8 и делать запросы на 1.1.1.1, однако возникает проблема с разрешением DNS, так как вы не можете подключиться к 8.8.8.8 на порт 53. Судя по вашему tcpdump, пакет SYN отправляется, но ответа от 8.8.8.8 нет. Попробуйте следующее:

  1. Проверьте правила PF: Убедитесь, что ваше правило для DNS (port 53) корректно настроено. Проверьте, разрешены ли исходящие DNS-запросы:

    pass out on $ext_if proto { tcp, udp } from $int_network to any port { domain } keep state
  2. Проверьте настройки фаервола на самом Debian: Убедитесь, что на вашем Debian-сервере нет правил фаервола, блокирующих исходящий трафик на порт 53.

  3. Проверьте разрешение имен: Убедитесь, что в файле /etc/resolv.conf указаны корректные DNS-серверы (например, 1.1.1.1 и 8.8.8.8).

2. Проблема с telnet google.com 80

Аналогично предыдущей проблеме, вы можете не получать ответ от google.com на порт 80:

  1. Проверьте, не блокирует ли что-то пакеты: Используйте tcpdump на FreeBSD, чтобы убедиться, что пакеты действительно идут и что вы получаете ответ от сервера. Убедитесь, что ваше правило для HTTP (порт 80) допускает трафик:

    pass out on $ext_if proto tcp from $int_network to any port { 80, 443 } keep state
  2. Проверьте настройки на Debian: Проверьте, нет ли локального фаервола (как ufw или iptables), который может блокировать трафик. Попробуйте временно отключить его:

    sudo ufw disable

3. SSH и telnet на Debian-сервере

Вы упоминаете, что наблюдаете пакеты на Debian-сервере, но соединение не устанавливается:

  1. Проверьте настройки PF: Убедитесь, что разрешены входящие соединения на порт 2223. У вас уже есть правило, но его нужно проверить:

    pass in on $ext_if proto tcp from <allowed_ssh> to $ext_if port 2223 keep state
  2. Проверьте приложение на Debian: Убедитесь, что служба, к которой вы пытаетесь подключиться на порту 2223, запущена и слушает на этом порту. Используйте следующую команду:

    sudo netstat -tuln | grep 2223
  3. Проверка ошибок в логах: Обратите внимание на логи SSH и системные логи, чтобы увидеть, не возникают ли у вас ошибки подключения.

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

  • Убедитесь, что все ваши серверы и маршрутизаторы имеют правильные сетевые настройки, и не забывайте учитывать возможные проблемы с MTU и фрагментацией пакетов в ваших настройках.
  • Используйте простые команды для диагностики на обоих серверах (как ping, traceroute, curl).
  • Если у вас есть другой сервер в той же сети, попробуйте подключиться и к нему, чтобы изолировать проблему.

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

Если проблемы продолжаются, подготовьте дополнительные детализированные логи и укажите, что вы пробовали, чтобы мы могли глубже анализировать вашу конфигурацию.

Удачи!

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

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

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