Ремэпинг без подмены IP. Как?

[Pochemuk]

День добрый!

Ситуация такая:
Если делать перехват и перенаправление трафика при помощи TIdMappedPortTCP или TIdTCPServer (в последнем случае для каждого входящего коннекта вручную создавать клиента для переподключения к требуемому серверу), то сервер, на который происходит перенаправление, воспринимает входящее подключение с адреса перехватчика, но не с адреса клиента. Т.е. при ремэпинге происходит подмена не только адреса/порта сервера, но и адреса клиента на адрес перехватчика.

Вопрос такой:
Можно ли перехват сделать прозрачным, чтобы серверу казалось, что к нему коннектится непосредственно клиент? Т.е. сделать так, как это реализовано в перенаправлении портов службы NAT для внешних подключений?

Для чего это нужно:
Нужно анализировать входящий трафик с целью его фильтрации. Этот фильтр должен быть первым в цепочке фильтров сторонних производителей, т.к. они срабатывают не всегда оперативно и не всегда достаточно жестко. К сожалению, следующий в цепочке фильтр, если обнаруживает коннект со стороны той же подсети, где он сам расположен, считает, что этот коннект всегда легитимен и дальнейшие проверки не производит. Жаль - он достаточно мощен. Вдвойне жаль, что не удалось договориться с разработчиками об отмене этой фичи. Они резонно утверждают, что проверка IP коннекта является неотъемлемой частью общей процедуры проверки. И если не удается однозначно определить внешний IP коннекта, то дальнейшие проверки просто теряют смысл и "во избежание" должны быть отключены. Все логично.

Поэтому и встал вопрос о прозрачности - на вторую ступень фильтрации должен поступать коннект как бы от имени внешнего клиента.

Надеюсь, что если уж не сможете мне помочь, то хотя бы объясните, почему это невозможно, чтобы я не ломал голову впустую.

[Квэнди]

На Indy не получится скорей всего ибо там нет возможности вмешиваться напрямую в заголовок TCP. Только если переписывать на WinSock и в каждом уходящем пакете подменять в заголовке source

[Pochemuk]

Сообщение от Квэнди

На Indy не получится скорей всего ...

А на чем получится? С RAW_SOCKET работать попытаться?

[Квэнди]

Вот как раз с raw это скорей всего получится. Ибо там есть возможность манипулирования заголовками.
В вложении небольшой пример, не мой, первое что попалось под руку.

[Pochemuk]

Сообщение от Квэнди

В вложении небольшой пример ...

Спасибо ... буду разбираться.
Только еще такой вопрос:
Если установить такой прокси не на шлюзе (это тогда даже не прокси получится, а просто редиректор), то сервер будет считать, что коннект пришел с другого IP и будет отвечать по этому другому IP напрямую минуя прокси или через шлюз. В результате ответы от сервера клиенту через прокси уже не пойдут и их проанализировать уже не получится. Кроме того, клиент может не понять, кто ему отвечает, т.к. коннектился он к проксе, а отвечает ему кто-то другой ...

Так это, или все не так страшно? Просто с пакетами на уровне IP работать еще не приходилось. Поэтому непонятного пока много.

[Квэнди]

Это будет абсолютно нормально работать если:
используется статическая маршрутизация и любой удаленный хост должен будет упираться маршрутом в ваш шлюз ) а вы уже с шлюза, проанализировав пакеты, рулите их дальше )

[Pochemuk]

Сообщение от Квэнди

Это будет абсолютно нормально работать если:
используется статическая маршрутизация и любой удаленный хост должен будет упираться маршрутом в ваш шлюз ) а вы уже с шлюза, проанализировав пакеты, рулите их дальше )

А если NAT шлюза перебрасывает на некий локальный комп (не конечный сервер), на котором уже и установлен этот "прозрачный фильтр"?

И еще Вы не ответили на вопрос, а будут ли анализироваться ответы с сервера внешнему клиенту, даже в том случае, если "прозрачный фильтр" установлен на самом шлюзе?

[Квэнди]

Вы меня не так поняли:
Ваша задача собственно "заставить" ходить весь трафик через вас, т.е. работать либо как шлюз ( вэтом случае внешний сервер просто не сможет отправить пакет мимо вас, ибо неисбежно пакет сначала попадет к вам, а затем уже от вас как вы захотите) либо поставить прозрачно в цепочку в виде бриджа, в этом случае возникает второй вопрос: ваш сервер (обзовем его так) стоит до или после NAT-а ?

[Pochemuk]

Наверное, действительно "не так понял" ... Или совсем не понял.
Ну насчет случая, если на шлюзе, то ясно (хотя и не совсем), а вот про второй случай:
Цепочка в этом случае будет такая:
Внешний клиент <-> Шлюз (NAT) <-> Фильтр <-> Сервер.
Т.е. и фильтр (который по принципу прозрачного прокси работает) и конечный сервер находятся в локальной подсети.
Но может быть отдельный случай, когда фильтр разместить на самом сервере. Но это вряд ли. Зачем сервер всякой ерундой нагружать, если предварительную фильтрацию можно сделать на отдельной машинке?

[Квэнди]

Так в этом случае пакет, пришедший снаружи, сначала разнатится, потом попадет в твой фильтр, потом уже на сервер, как же он попадет минуя твой фильтр если цепочка прямолинейная ? попасть он минуя фильтр может только с разветвленной цепочкой и динамической маршрутизацией.