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

750
ldx

Я пытаюсь добавить простое правило 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

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

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

1 ответ на вопрос

0
zhovner

Я обнаружил, что некоторые правила брандмауэра 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)

Похожие вопросы