запрос postgresql зависает бесконечно через VPN — новый брандмауэр
У нас есть продукт, в котором локальная Linux-машина «SCANNER» проводит опрос в локальной сети, а затем вставляет информацию в базу данных на нашем облачном сервере через соединение OpenVPN, используя pg_query (сервер работает на PostgreSQL 9.5.5).
В SCANNER есть демон PHP (5.5.9), который проверяет базу данных в цикле while для выполнения работы. Это всегда прекрасно работало и продолжает прекрасно работать во всех наших клиентских сетях, кроме одной, которая недавно развила странную проблему.
После того, как они обновили свой брандмауэр (Checkpoint 5200, и, насколько мы можем судить, все правила верны, чтобы пропускать трафик со SCANNER на наш облачный сервер через VPN), один запрос в одном сценарии зависает на неопределенное время. Вот симптомы, которые мы отметили:
В большинстве случаев запрос работает нормально, и сценарий продолжается. Время от времени жестко, вызов pg_query () блокируется и никогда не возвращается. Дело не в том, что есть ошибка; вызов буквально блокируется навсегда (или много часов, пока мы не перезапустим вручную).
Этот запрос был одним и тем же долгое время, и у нас никогда не было этой проблемы ни на одном из наших клиентов, ни на этом клиенте, пока они не изменили свой брандмауэр.
Наблюдая за таблицей pg_stat_activity на облачном сервере, мы можем сказать, что запрос действительно попадает в облако, а затем навсегда остается в этой таблице. В каждом случае pg_stat_activity.state = ‘idle’ и pg_stat_activity.waiting = false
В течение этого времени мы все еще можем пропинговать облачный сервер из SCANNER через VPN, и мы можем продолжать успешно запрашивать его удаленную базу данных из других сценариев в SCANNER и из командной строки SCANNER.
Этот клиент имеет две разные машины SCANNER, в разных подсетях, но за одним и тем же брандмауэром. Эта проблема может возникнуть в любое время на любом из них, но не обязательно возникает одновременно на обоих (по крайней мере, с какой-либо статистической значимостью).
Если мы перезапустим демон, проблема будет временно решена. Но обычно это повторяется между 2 секундами и несколькими часами позже.
Мы ищем любые входные данные, которые могут решить проблему, независимо от того, связана ли она с нашим приложением или с самим брандмауэром (который нам дали разрешение на изменение по мере необходимости). Не стесняйтесь задавать любые уточняющие вопросы.
Заранее спасибо!
Решение
Межсетевой экран Check Point имеет множество расширенных средств защиты от угроз, в зависимости от приобретенных блейдов, устройство может блокировать связь между вашей базой данных и приложением. Попробуйте использовать инструменты журнала Check Point (Tracker, SmartEvent или NGSE) для фильтрации журналов брандмауэра. Отфильтруйте все события, где источником или назначением являются IP-адреса вашего сканера или сервера базы данных. Если вы получите какой-нибудь выпадающий блок в своих пакетах TCP, это будет показано в журналах.
Если ваша топология брандмауэра использует конфигурации кластера, попробуйте проверить вашу конфигурацию, возможно, она неправильно настроена, и сеанс TCP базы данных активен, но пакеты используют другой сетевой путь.
Если вы используете VPN-клиент Check Point, попробуйте обновить его до последней версии и обновить брандмауэр до последней версии (Take).
Если проблема не устранена, получите доказательства того, что ваше общение без оборудования Check Point не прекращается, и некоторые доказательства вашей проблемы и попросите вашего поставщика решений Check Point открыть дело с Check Point.
Другие решения
Мы решили проблему. Технически, мы никогда не выясняли, почему именно это происходило, но UDP-пакеты принимались VPN-сервером в неправильном порядке, а иногда и вовсе не поступали. Брандмауэр не дал нам никаких указаний на то, что он делал это, так что, насколько мы можем судить, это был незагруженный побочный эффект нескольких уровней защиты от угроз CheckPoint.
Мы перешли на использование OpenVPN через TCP вместо UDP, и это, похоже, решило проблему. Надеемся, что в долгосрочной перспективе мы не пострадаем от этого.
detector