Наш брандмауэр 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
У меня вопрос: почему? Что заставляет более позднее «быстрое» правило не совпадать и вместо этого позволяет правилам по умолчанию действовать?
Похоже, что есть какая-то неправильная синхронизация состояний, отличная от проблемы логики правил.
Вы можете попытаться ослабить scrub частично или полностью. Для е. грамм., no-df копируется вслепую, но удаление DF может помешать обнаружению Path MTU.
Если я правильно понимаю, у вас есть NAT-маршрутизатор и клиент за ним, которого вы хотите разрешить в Интернет. Я заметил, что почти все мои правила устанавливают интерфейс, к которому они применяются, и не утруждают себя указанием направления. У вас наоборот, тяжелый по направлению, но не указывающий интерфейс.
Глядя на ваши единственные два правила прохождения,
pass in quick from 11.22.33.164 to any
pass out quick from any to 11.22.33.164
Это имеет смысл только тогда, когда применяется к интерфейсу LAN вашего маршрутизатора. Первый позволяет этому конкретному IP-адресу разговаривать с маршрутизатором и всем, к чему он подключен, второй позволяет вещам разговаривать с этим IP-адресом через маршрутизатор. Это хороший первый шаг. Однако я считаю, что пакету не разрешено продвигаться дальше, поскольку отсутствуют соответствующие правила для интерфейса WAN. Хотя я не помню, требует ли это «nat» (и должен ли IP, используемый в правиле, быть pre-nat или post-nat). Быстро можно попробовать удалить ключевые слова "in" и "out" из этих двух правил.
В моей домашней обстановке я уклоняюсь от большей части работы, используя следующие неаккуратные ярлыки:
set skip on { lo0 $lan_if $vpn_if } # trusted interfaces
nat on $wan_if inet from !$wan_if to any -> ($wan_if:0)
pass out quick all # outbound default to allow
block return in quick all no state # inbound default to deny, return icmp(unreachable)