Вот моя ситуация:
1) DMZ: у меня есть самозаверяющий сертификат SSL на сервере Apache (наш хост-бастион), настроенный для работы в качестве обратного прокси для 7 других серверов LAN (subversion, ldap, jenkins, confluence, jira, mapi и т. Д.).
2) Брандмауэр: между хостом-бастионом DMZ (который находится в подсети DMZ 192.168.1.X) у меня есть брандмауэр Cisco, настроенный так, чтобы (определенный) трафик происходил со стороны хоста DMZ Bastion на определенные хосты LAN. Подсеть LAN - 192.168.50.X. Маршрутизатор - Cisco RV042.
3) LAN: у меня есть 7 серверов, на которых работают различные приложения на UBuntu с включенным iptables через ufw.
4) Subversion: один из 7 серверов работает под управлением Subversion 1.5.4 и предоставляет HTTP-порт хосту-бастиону. Очень похоже Эта статья обсуждает.
В течение многих лет все работало ужасно, за исключением ОДНОЙ ВЕЩИ, которую я, похоже, не могу решить: все команды HTTPS Subversion, которые проходят через хост-бастион на сервер подрывной деятельности LAN, терпят неудачу, если никто не использовал сервер подрывной деятельности в течение нескольких часов / дней (не совсем конечно).
Это вызывает настоящую проблему, потому что удаленные разработчики вносят кучу локальных изменений, фиксируют ... и затем Eclipse зависает, его приходится вручную убивать, очищать клиентские источники и т. Д ... настоящая проблема. Затем мне звонят ... и я перехожу к хосту-бастиону и пытаюсь просмотреть некоторые источники, которые после нескольких щелчков мышью начинают работать. Тогда следующая попытка разработчика зафиксировать всегда срабатывает.
Вот что я пробовал:
1) Брандмауэр выключен: если я отключу брандмауэр на маршрутизаторе Cisco, он всегда будет работать ... все время, но у нас нет безопасности DMZ / LAN!
2) LAN Subversion: он всегда работает, если вы напрямую попадаете на сервер Subversion LAN.
3) Изменения конфигурации брандмауэра: когда брандмауэр включен, я могу создать правило, позволяющее пропускать ЛЮБОЙ трафик DMZ-> LAN, и проблема все еще возникает. Фактически, брандмауэр включен, но полностью открыт, и проблема все еще возникает. Это как если бы межсетевой экран маршрутизатора между хостом-бастионом и сервером подрывной деятельности в локальной сети требует преобразования с сохранением состояния, происходящего на стороне локальной сети, но я абсолютно проверил, что межсетевой экран открыт (если бы это было не так, он НИКОГДА не работал бы ... как я сказал при частом использовании он может работать несколько дней / недель).
4) Несоответствие MTU: найдено статья что предполагает, что это может быть проблемой, но MTU как на сервере Bastion, так и на сервере Subversion составляет 1500 в соответствии с ifconfig.
5) Разные изменения конфигурации Apache хоста-бастиона ... безрезультатно перепробовали множество вещей. Вот конфигурация Apache от /etc/apache2/sites-enabled/default-ssl на хосте-бастионе (обратный прокси) я запускал последний год:
ProxyPass /svn http://virt-svn-srv.mycomp.int/svn keepalive=on
<Location /svn>
ProxyPassReverse http://virt-svn-srv.mycomp.int/svn
SetEnv force-proxy-request-1.0 1
</Location>
Я действительно в своем уме ... все предложения приветствуются.
Это похоже на проблему с тайм-аутом (брандмауэр удаляет сеансы из таблицы сеансов).
Я не совсем знаком с Subversion и Eclipse, но;
Если он открывает соединение с сервером Subversion при запуске, а затем пытается использовать тот же сеанс для фиксации кода через 60 минут (установленный Cisco) тайм-аут по умолчанию, то он завершится ошибкой.
Ваш брандмауэр сбросит пакеты, заявив, что не нашел подходящего сеанса.
Вы можете попробовать добавить карту классов и карту политик, чтобы соответствовать трафику, идущему на ваш сервер Subversion.
access-list acl-timeout-subv extended permit tcp any host [subversionIP] eq [subversionPort]
затем
class-map cls-timeout-subv
match access-list acl-timeout-subv
exit
затем
policy-map timeout-subv
class cls-timeout-subv
set connection timeout idle 08:00:00
exit
Это установит весь трафик, идущий к вашей подрывной версии на указанный порт, с таймаутом 8 часов.