FreeBSD-12.0 Правило брандмауэра PF по умолчанию блокирует, когда игнорируется более конкретное разрешающее правило
Наш брандмауэр PF содержит следующее:
. . .
scrub in all fragment reassemble no-df max-mss 1440
### em1 ipv4 = 123.12.3.234
nat log on $ext_if \
from $net_nat \
to any -> ($ext_if)
. . .
antispoof log for $ext_if
block return out log all
block drop in log all
. . .
Далее следует несколько позже:
pass in log quick \
from 11.22.33.164 \
to any
pass out log quick \
from any \
to 11.22.33.164
Однако TCPDUMP показывает, что это происходит:
00:00:00.116888 rule 3/0(match): block in on em1: 11.22.33.164.2148 > 123.12.3.234.59865: Flags [R.], seq 1, ack 1, win 5707, length 0
00:00:00.115632 rule 3/0(match): block in on em1: 11.22.33.164.2148 > 123.12.3.234.62733: Flags [R.], seq 1, ack 1, win 159, length 0
00:00:00.011031 rule 2/0(match): block out on em1: 123.12.3.234.64105 > 11.22.33.164.2148: Flags [P.], seq 2111901423:2111901475, ack 316150303, win 258, length 52
00:00:00.074555 rule 3/0(match): block in on em1: 11.22.33.164.2148 > 123.12.3.234.58208: Flags [.], ack 1, win 159, length 0
00:00:00.065409 rule 3/0(match): block in on em1: 11.22.33.164.2148 > 123.12.3.234.56489: Flags [.], ack 1, win 159, length 0
00:00:00.077103 rule 3/0(match): block in on em1: 11.22.33.164.2148 > 123.12.3.234.62245: Flags [P.], seq 0:36, ack 1, win 136, length 36
00:00:00.040241 rule 3/0(match): block in on em1: 11.22.33.164.2148 > 123.12.3.234.58208: Flags [.], ack 1, win 159, length 0
00:00:00.026616 rule 3/0(match): block in on em1: 11.22.33.164.2148 > 123.12.3.234.56489: Flags [R.], seq 1, ack 1, win 159, length 0
Мой вопрос: Почему? Что заставляет более позднее «быстрое» правило не совпадать и вместо этого позволяет правилам по умолчанию вступить в силу?
Если я правильно прочитал, у вас есть NAT-маршрутизатор и клиент за ним, которому вы хотите разрешить выход в Интернет. Я заметил, что почти все мои правила определяют интерфейс, к которому они применяются, и не утруждают себя указанием направления. Ваши - наоборот, сильно зависят от направления, но не указывают интерфейс.
Глядя на ваши только два правила «прохода»,
быстро переходят от 11.22.33.164 к любому
быстро переходить от любого к 11.22.33.164
Они имеют смысл только тогда, когда они применяются к LAN-интерфейсу вашего маршрутизатора. Первый позволяет этому конкретному IP-адресу разговаривать с маршрутизатором и всем, к чему он подключен, второй позволяет вещам разговаривать с этим IP-адресом через маршрутизатор. Это хороший первый шаг. Тем не менее, я считаю, что пакету не разрешено продвигаться дальше, поскольку соответствующие правила для интерфейса WAN отсутствуют. Хотя я не помню, требует ли это «nat» (и должен ли IP, используемый в правиле, быть pre-nat или post-nat). Быстро можно попробовать удалить ключевые слова «in» и «out» из этих двух правил.
В моей домашней настройке я уклоняюсь от большей части работы, используя такие неаккуратные ярлыки:
set skip на {lo0 $ lan_if $ vpn_if} # доверенных интерфейсов
nat на $ wan_if inet от! $ wan_if до любого -> ($ wan_if: 0)
передать быстро все # исходящее по умолчанию разрешить
блок возврат быстро все нет состояния # входящий по умолчанию для отклонения, возврат icmp (недоступен)
Похоже, что есть какая-то некорректная синхронизация состояний, отличная от проблемы логики правил.
Вы можете попытаться ослабить scrub частично или удалить его полностью. Для е. g., no-df копируется вслепую, но удаление DF может помешать обнаружению Path MTU.