Правило PF, использующее return-rst в Mac OS X, не отвечает сбросом TCP

2

Я пытаюсь добавить простое правило PF:

block return-rst out proto tcp from any to any port 33128

чтобы отфильтровать весь исходящий трафик на TCP-порт 33128, и я хотел бы, чтобы он ответил сбросом. Тем не менее, когда я проверяю его nc, он отключается, вместо того, чтобы сразу же вернуться с ошибкой отказа в соединении, которая предполагает, что пакеты, идущие в порт 33128, отбрасываются без отправки сброса TCP:

$ nc -v 172.22.2.2 33128
nc: connectx to 172.22.2.2 port 33128 (tcp) failed: Operation timed out

Способ, которым я включаю PF и добавляю это правило:

$ echo "block return-rst out proto tcp from any to any port 33128" > pf.conf
$ sudo pfctl -f pf.conf
$ sudo pfctl -e

Что не так с этим правилом?

macos networking firewall bsd pf LDX
источник
имея ту же проблему. Я пытаюсь использовать pfctl для симуляции полностью разорванного соединения с конкретным доменом для некоторых тестов, но все, что я получаю, это тайм-аут
Фернандо Маззон
Какую версию MacOS вы используете? Это прекрасно работает для меня 10.10. Я предполагаю, pfctl -eвозвращается без ошибок?
Эрадман
@eradman Бег 10.10 тоже. $ sudo pfctl -e Нет поддержки ALTQ в ядре. Функции, связанные с ALTQ отключены. pfctl: pf уже включен. Другие правила работают просто отлично, просто это правило имеет проблемы, получая таймауты вместо сброса
Фернандо Маззон

Ответы:

0

Я обнаружил, что некоторые правила брандмауэра PF работают неправильно после подключения Thunderbolt Ethernet, но работают правильно, когда WiFi является единственным сетевым адаптером. Например, действие return-rst не возвращает пакеты TCP RST.

Обновление
Я понял, что эта ошибка влияет на любое проводное соединение Ethernet . Даже встроенный адаптер Ethernet iMac против встроенного адаптера WiFi. Проверено на старых и новых iMac.

Шаги для воспроизведения: на первом шаге давайте попробуем исправить поведение. Для этого нам понадобится MacBook / iMac с подключением только по WiFi, без подключения Thunderbolt Ethernet.

  1. Сбросить все правила PF
    sudo pfctl -F all

  2. Создайте простое правило для блокировки TCP-соединения с портом 81, которое должно возвращать TCP-пакет RST, чтобы немедленно прервать соединение.
    echo "block return-rst out proto tcp from any to any port 81" | sudo pfctl -e -f -

  3. Проверьте, правильно ли было добавлено новое правило.
    Здесь мы видим счетчик пакетов, которые соответствуют правилу брандмауэра.
    pfctl -vsr Packets: 0 Bytes: 0

  4. Теперь пытаемся проверить правило брандмауэра с помощью curl, который подключается к порту 81
    curl http://example.com:81 curl: (7) Failed to connect to example.com port 81: Connection refused

Посмотрите, что соединение немедленно отклонено правилом брандмауэра, как и ожидалось. Это правильное поведение.

Теперь проверьте неправильное поведение. Для этого нам нужно подключить подлинный Apple Thunderbolt Ethernet с активным проводным соединением. Соединение WiFi можно отключить или оставить включенным, это не имеет значения, ошибка появится в обоих случаях.

  1. Оставьте правила брандмауэра такими же

  2. Попытка использовать curl снова.
    curl http://example.com:81 .....waiting.... curl: (28) Connection timed out
    Теперь соединение зависает и через некоторое время закрывается по таймауту. Но правило брандмауэра все еще активно и работает.

  3. Мы можем посмотреть на счетчики пакетов pfctl -vsr и убедиться, что правило совпадает и все еще блокирует соединение. Но без TCP RST отвечу.

Мои настройки:
macOS: 10.14.1 (18B75)
MacBook Pro (Retina, 15-дюймовый, середина 2015 г.)
Ethernet-адаптер Apple Thunderbolt 2 (57762)

zhovner
источник