Вопрос по conntrackd

где уже ожидается приход пакета без предварительного syn/ack.

так просто не получится, все эти коннтраки являются внешними приблудами для сетевого стэка ОС (что, кстати, жирный минус линуха). Синхронизация состояния фаервола не создаст живые соединения.

То что ты хочешь делается через лоад бэлансер.

Не, ну я видел где-то transparent tcp connection failover, но не помню где и это скорее создаёт проблемы чем решает потому что чтобы подхватить сессию посередине оба сервера должны быть синхронизированы.

вот живой пример проблемы: я сижу на одном сервере по ssh. Внезапно сервак дохнет, tcp-сессия перекидывается на другой, а толку? Программы которые я запустил на старом сервере не восстановятся (это помимо 100500 других проблем, то что ssh так не заработает из-за шифрования понятно). Подумай над этим.

Ну SSH я точно не хочу прокидывать, а вот HTTP надеюсь можно. Т.е. если на web2 создать фейковое ESTABLISHED соединение идентичное web1, то при переключении направления с web1 на web2 оно должно хоть как-то заработать.

В качестве примера: - клиент подключается к серверу и ничего не делает, висит keepalive соединение. - в это время на web0 (gateway) меняется направление трафика с web1 на web2 - клиент обновляет страницу и видит контент уже с web2

гугли, было такое. Только зачем это? Нормальный балансер сам перевыполнит запрос на здоровом сервере.

клиент обновляет страницу и видит контент уже с web2

пффф, это типичная ситуация с фронтэндом и несколькими бэкендами.

мне без балансера надо, чтобы соединение не резетилось и на web2 уже ожидалось соединение (с якобы прошедшим SYN/ACK), которого там никогда в помине не было.

если гуглить, то по каким ключевым словам? я лишь conntrackd нашел, но судя по мануалу он больше подходит для gateway'ев, а не конечных серверов.

И кстати, обычный балансер работает именно с соединением. А мне соединение нужно на куски порвать (SYN/ACK в web1, GET HTTP/1.1 в web2) и чтобы клиент не заметил.

мне без балансера надо

а web0 это, по-твоему, что? У тебя по-любому будет какая-то общая точка потому что tcp это end-to-end соединение, оно по определению без костылей не умеет резервироваться.

Гуглить по словам tcp transparent failover

обычный балансер работает именно с соединением. А мне соединение нужно на куски порвать (SYN/ACK в web1, GET HTTP/1.1 в web2) и чтобы клиент не заметил.

почитай как работает nginx: http://nginx.org/ru/docs/http/ngx_http_upstream_module.html

Ты сразу скажи что ты по этой теме знаешь, а что нет. А то может ты тут сидишь и теоретизируешь на тему «а вот если», а я тут пыжусь....

Собираюсь использовать NFQUEUE + RAWDNAT в raw таблице PREROUTING, т.е. трафик в userspace будет попадать исключительно через NFQUEUE для анализа и маркировки, а после анализа и маркировки inject'ится в ту же таблицу через nf_verdict repeat. Большая часть трафика будет ходить в web1, а маркированная в web2.

Никаких nginx и прочих балансеров не будет, поэтому интересуюсь более низкоуровневыми вещами.

На данный момент требуемый пакет благополучно перенаправляется на web2, где судя по conntrack он висит в ESTABLISHED, но тот же nginx его в упор не видит. Предполагаю, что из-за отсутствия SYN/ACK.

почему бы просто траффик не миррорить на два сервера?

Слишком накладно по ресурсам. Да вот собственно миррорить SYN/ACK с помощью conntrackd я и собирался. Мануал у них какой-то мутный и рассчитан на несколько gateway + keepalived. А когда мозги ближе к вечеру начали плавиться, решил поплавить их еще кому-нибудь =) Как оказалось безрезультатно. Завтра продолжу изыскания.

тебе надо миррорить весь трафик потому что у tcp есть sequence numbers который как раз помогает определять потери трафика и очередность пакетов. Т.е. там движется окно передачи. Так вот если эти окошки рассинхронизируются то хрен ты что передашь.

Обязательно потом расскажи, как перекинул динамический контент.

conntrackd, как я и предполагал, работает только на firewall/router/gateway, в моей ситуации не поможет.

ipvs тоже не подходит. Он хоть и умеет работать с маркированными пакетами, но keep-alive соединение пробросить с одного сервера на другой не может.

зеркалирование handshake трафика через TEE тоже не дает результатов, т.к. оба web сервера начинают на них отвечать.

еще один вариант - nginx proxy HTTP/1.0, который поставить до web0, чтобы он не поддерживал keep-alive соединения с backend, но тут опять без syn/ack не обойтись. т.к. идентификация пакета по контенту проходит уже после handshake.

последний вариант - самому реализовать подобный механизм.

т.к. оба web сервера начинают на них отвечать.

естестно. ты перечитай мои последние посты про то что tcp это протокол с состоянием. В это всё и упирается.

А если ты ставишь прокси то не надо городить костыли, nginx из коробки умеет failover.

Не хотел я лишние звенья городить, но выхода нет.

Сделал для маркированного трафика на OUTPUT -j REJECT --reject-with tcp-reset. Как только nginx видит RST, то направляет трафик на web2. теперь для пользователя перенаправление совершенно незаметно.

это противоречит и «мне без балансера надо» и многим другим твоим постам

Балансировки как таковой нет. При специально созданном fail'е (RST) nginx направляет трафик на нужный сервер, а клиент этого и не замечает, т.к. RST только для nginx. Что изначально и требовалось.

Да, я не хотел использовать nginx, но если другого варианта не нашлось?

ня https://lwn.net/Articles/495304/

мерси

Ставишь на web0 какой-нибудь squid, и клиент больше вообще ничего не знает об web1/web2.