У меня есть WatchGuard Firebox, который я недавно настроил. Все политики выглядят нормально, и все соответствующие службы работают правильно.
Тем не менее, один или два (на первый взгляд) случайных узла продолжают блокироваться от отправки HTTP-запросов к хосту с NAT 1: 1, что все остальные делают нормально.
Журнал брандмауэра сообщает мне, что tcp syn checking failed, и эти запросы используют порт назначения 64 для клиентов за устройством и порт 50 для внешних клиентов. Я наконец нашел эту опцию и отключил ее в глобальных настройках (что оставляет неприятный привкус во рту), и, похоже, это помогло.
Однако документация по этой теме очень тонкая. Может ли кто-нибудь объяснить мне, что именно делает / представляет собой проверка синхронизации tcp, и как я могу сделать соответствующую поправку в своих политиках, а не отключать ее глобально (при условии, конечно, что есть является более изящное решение, чем глобальное правило)?
От Watchguard:
Проверка TCP SYN
Глобальная настройка проверки TCP SYN: Включить проверку TCP SYN Эта функция гарантирует, что трехстороннее подтверждение TCP будет выполнено до того, как Firebox разрешит подключение к данным.
Поэтому я полагаю, что сторожевой охранник не видит, как происходит обычная синхронизация / синхронизация / подтверждение, по какой-либо причине и убивает соединение.
Я работаю в WatchGuard. Проверка SYN предназначена только для того, чтобы убедиться, что рукопожатие TCP имело место, прежде чем разрешить другой трафик. Даже если это отключено, мы все равно гарантируем правильное завершение установления связи TCP, которое не влияет на нашу защиту TCP SYN Flood. Отключить безопасно.
Это часто срабатывает из-за того, что таймауты TCP на WatchGuard короче, чем тайм-ауты на соединении сервер / клиент. Когда сервер / клиент снова разговаривают, WatchGuard предположил, что соединение было закрыто, и хотел бы снова увидеть рукопожатие TCP.