Как перезапустить службу Java без прерывания работы с помощью брандмауэра / iptables?

Если включить это правило

iptables -t nat -A PREROUTING -p tcp --dport 80  -j REDIRECT --to 8080

Затем соединения, поступающие на порт 80 сервера, перенаправляются на localhost: 8080. Если я хочу перезапустить службу, могу ли я просто запустить службу на другом порту? Скажите порт 8081 и перенаправьте брандмауэр на

iptables -t nat -A PREROUTING -p tcp --dport 80  -j REDIRECT --to 8081 # Apparently -A won't work. I have to replace the rule, not add it. But I don't know how to do it yet

Однако как насчет установленных соединений сокетов TCP на порте 8080 с NAT? Будут ли они удалены сразу после смены брандмауэра? В качестве альтернативы, будут ли они работать до закрытия обычного TCP-сокета?

Если это так, то это работает при перезапуске приложения без сбоев, поскольку старый экземпляр находится на порту 8080 при плавном завершении работы, а новый - на порту 8081 с новыми функциями.

Правильно ли это рассуждение?

Ты спрашивал: "Правильно ли это рассуждение?"

Мой ответ: "Чтобы быть частично правильно, вы должны исправить несколько деталей среди ваших предположений и действий. Не будучи на 100% правильным, это также означает, что ... неправильно подход! ». И такое утверждение я говорю в силу следующих факторов (в более-менее случайном порядке):

IMHO, вы собираетесь решить проблему (перезапустить TCP-сервер / службу без нарушения существующих установленных TCP-соединений), используя неправильный подход. Мне кажется «естественным» подход решить проблему на «уровне приложения». Поскольку вы говорите о приложении TCP / Server, очень высоки шансы, что оно «многопоточное» или «многопроцессорное». В такой среде ничто не мешает вам «перезапустить» неиспользуемые потоки / процессы, ожидая, пока «занятые» потоки / процесс завершат свою деятельность. Конечно, это сложнее, чем установить пару правил iptables, но ... это то, что выглядит "естественным" (для меня). Кстати: это именно подход, который разработчики "apache" реализовали в своем "плавный перезапуск"для демона httpd TCP

Сказав выше, что касается iptables подход, который вас интересует, вот мои комментарии:

как уже упоминалось @iain, вы не можете использовать -A но необходимо заменить существующее правило. Взгляните на страница руководства iptables и искать -R или - если у вас есть проблемы с определением правила замены - пара -D + -A;
iptables является действительно мощный поэтому должно быть возможно соответствие только новый соединения. Другими словами, вы можете переписать свое NAT-правило в соответствии с только новые связи (посмотрите состояния подключения и Conntrack Match). При таком подходе существующее соединение будет придерживаться «старого» ПОРТА, а новые соединения будут перенаправлены на «новый» ПОРТ. К сожалению, "новое" соединение будет "установлено" довольно скоро и ... будет распознано по первому правилу (перенаправлено на СТАРЫЙ порт, поскольку оно имеет дело с "установленными" соединениями). В любом случае, вы сможете решить такую проблему с помощью смеси 1) искажение входящие / исходящие пакеты; 2) правильный выбор диапазона портов; 3) управление пользовательским пространством отслеживания соединений; 4) прочее-то-что-я-конечно-игнорирую. Сказав это, пожалуйста не спрашивайте меня подробностей, я не эксперт по сетевым фильтрам (но я уверен, что это можно сделать);
Ты спрашивал: "как насчет установленных соединений сокетов TCP на порту 8080 с NAT? Будут ли они удалены сразу после смены брандмауэра? В качестве альтернативы, будут ли они работать до закрытия обычного TCP-сокета?"

4,1 "они будут немедленно отброшены": здесь вы неправильно употребляете слово" DROP "в iptables/ netfilter context - это ключевое понятие в паре с термином "REJECT". Видеть Вот как начало личного расследования. В вашем конкретном случае (когда вы меняете базовое правило NAT во время установки соединения) я думаю, что как только первый пакет TCP установленного соединения («установленный» по отношению к «старому» TCP / серверу) будет получен "новый" TCP / сервер из-за обновленного DNAT-правила, "новый" TCP / сервер просто "прекратить"соединение (с флагом" RESET ", я полагаю), поскольку оно не распознает такие пакеты. Я не думаю, что это можно классифицировать как" DROP ", поскольку будет отправлен RST (я предполагаю) .

4,2 "будут ли они работать до тех пор, пока не закроется нормальный сокет TCP": Готов поспорить, что нет! Если вы примените некоторое" насилие "к случайным TCP-пакетам установленного TCP-соединения, не только удалив пакеты, но и отправив их на другой TCP / сервер ... вы можете будьте уверены, что произойдет что-то странное. И, по крайней мере, слова "они продолжают работать"не может применяться!" Кстати: это как раз причина для такого программного обеспечения, как Conntrackd существует, чтобы обеспечить согласование данных отслеживания соединений между двухузловым HA iptables кластер межсетевого экрана.

Как вы используете -A вы добавляете правило, поэтому более ранние правила не затрагиваются.

При использовании iptables первое подходящее правило побеждает, поэтому в соответствии с установленными правилами любое соединение, достигающее порта 80, будет перенаправлено на порт 8080.

Однако если вы решите удалить правило, которое перенаправляет порт 80 на порт 8080, тогда пакеты, предназначенные для порта 80, будут перенаправлены на порт 8081. Это нарушит существующие соединения, поскольку сервер на порту 8081 не будет иметь о них представления.