|
|
Регистрация Восстановить пароль |
Повторная активизация e-mail |
Регистрация | Задать вопрос |
Заплачу за решение |
Новые сообщения |
Сообщения за день |
Расширенный поиск |
Правила |
Всё прочитано |
|
|
Опции темы | Поиск в этой теме |
04.04.2008, 13:14 | #1 |
Регистрация: 04.04.2008
Сообщений: 8
|
Ремэпинг без подмены IP. Как?
День добрый!
Ситуация такая: Если делать перехват и перенаправление трафика при помощи TIdMappedPortTCP или TIdTCPServer (в последнем случае для каждого входящего коннекта вручную создавать клиента для переподключения к требуемому серверу), то сервер, на который происходит перенаправление, воспринимает входящее подключение с адреса перехватчика, но не с адреса клиента. Т.е. при ремэпинге происходит подмена не только адреса/порта сервера, но и адреса клиента на адрес перехватчика. Вопрос такой: Можно ли перехват сделать прозрачным, чтобы серверу казалось, что к нему коннектится непосредственно клиент? Т.е. сделать так, как это реализовано в перенаправлении портов службы NAT для внешних подключений? Для чего это нужно: Нужно анализировать входящий трафик с целью его фильтрации. Этот фильтр должен быть первым в цепочке фильтров сторонних производителей, т.к. они срабатывают не всегда оперативно и не всегда достаточно жестко. К сожалению, следующий в цепочке фильтр, если обнаруживает коннект со стороны той же подсети, где он сам расположен, считает, что этот коннект всегда легитимен и дальнейшие проверки не производит. Жаль - он достаточно мощен. Вдвойне жаль, что не удалось договориться с разработчиками об отмене этой фичи. Они резонно утверждают, что проверка IP коннекта является неотъемлемой частью общей процедуры проверки. И если не удается однозначно определить внешний IP коннекта, то дальнейшие проверки просто теряют смысл и "во избежание" должны быть отключены. Все логично. Поэтому и встал вопрос о прозрачности - на вторую ступень фильтрации должен поступать коннект как бы от имени внешнего клиента. Надеюсь, что если уж не сможете мне помочь, то хотя бы объясните, почему это невозможно, чтобы я не ломал голову впустую. |
06.04.2008, 09:55 | #2 |
Старожил
Регистрация: 13.12.2006
Сообщений: 3,859
|
На Indy не получится скорей всего ибо там нет возможности вмешиваться напрямую в заголовок TCP. Только если переписывать на WinSock и в каждом уходящем пакете подменять в заголовке source
ICQ не для вопросов, а для предложений. Для вопросов используйте форум
IRC канал клуба программистов|Мои статьи |
07.04.2008, 09:00 | #3 |
Регистрация: 04.04.2008
Сообщений: 8
|
|
07.04.2008, 09:35 | #4 |
Старожил
Регистрация: 13.12.2006
Сообщений: 3,859
|
Вот как раз с raw это скорей всего получится. Ибо там есть возможность манипулирования заголовками.
В вложении небольшой пример, не мой, первое что попалось под руку.
ICQ не для вопросов, а для предложений. Для вопросов используйте форум
IRC канал клуба программистов|Мои статьи |
07.04.2008, 10:56 | #5 |
Регистрация: 04.04.2008
Сообщений: 8
|
Спасибо ... буду разбираться.
Только еще такой вопрос: Если установить такой прокси не на шлюзе (это тогда даже не прокси получится, а просто редиректор), то сервер будет считать, что коннект пришел с другого IP и будет отвечать по этому другому IP напрямую минуя прокси или через шлюз. В результате ответы от сервера клиенту через прокси уже не пойдут и их проанализировать уже не получится. Кроме того, клиент может не понять, кто ему отвечает, т.к. коннектился он к проксе, а отвечает ему кто-то другой ... Так это, или все не так страшно? Просто с пакетами на уровне IP работать еще не приходилось. Поэтому непонятного пока много. |
07.04.2008, 12:12 | #6 |
Старожил
Регистрация: 13.12.2006
Сообщений: 3,859
|
Это будет абсолютно нормально работать если:
используется статическая маршрутизация и любой удаленный хост должен будет упираться маршрутом в ваш шлюз ) а вы уже с шлюза, проанализировав пакеты, рулите их дальше )
ICQ не для вопросов, а для предложений. Для вопросов используйте форум
IRC канал клуба программистов|Мои статьи |
07.04.2008, 13:39 | #7 | |
Регистрация: 04.04.2008
Сообщений: 8
|
Цитата:
И еще Вы не ответили на вопрос, а будут ли анализироваться ответы с сервера внешнему клиенту, даже в том случае, если "прозрачный фильтр" установлен на самом шлюзе? |
|
07.04.2008, 15:59 | #8 |
Старожил
Регистрация: 13.12.2006
Сообщений: 3,859
|
Вы меня не так поняли:
Ваша задача собственно "заставить" ходить весь трафик через вас, т.е. работать либо как шлюз ( вэтом случае внешний сервер просто не сможет отправить пакет мимо вас, ибо неисбежно пакет сначала попадет к вам, а затем уже от вас как вы захотите) либо поставить прозрачно в цепочку в виде бриджа, в этом случае возникает второй вопрос: ваш сервер (обзовем его так) стоит до или после NAT-а ?
ICQ не для вопросов, а для предложений. Для вопросов используйте форум
IRC канал клуба программистов|Мои статьи |
07.04.2008, 16:29 | #9 |
Регистрация: 04.04.2008
Сообщений: 8
|
Наверное, действительно "не так понял" ... Или совсем не понял.
Ну насчет случая, если на шлюзе, то ясно (хотя и не совсем), а вот про второй случай: Цепочка в этом случае будет такая: Внешний клиент <-> Шлюз (NAT) <-> Фильтр <-> Сервер. Т.е. и фильтр (который по принципу прозрачного прокси работает) и конечный сервер находятся в локальной подсети. Но может быть отдельный случай, когда фильтр разместить на самом сервере. Но это вряд ли. Зачем сервер всякой ерундой нагружать, если предварительную фильтрацию можно сделать на отдельной машинке? |
07.04.2008, 18:21 | #10 |
Старожил
Регистрация: 13.12.2006
Сообщений: 3,859
|
Так в этом случае пакет, пришедший снаружи, сначала разнатится, потом попадет в твой фильтр, потом уже на сервер, как же он попадет минуя твой фильтр если цепочка прямолинейная ? попасть он минуя фильтр может только с разветвленной цепочкой и динамической маршрутизацией.
ICQ не для вопросов, а для предложений. Для вопросов используйте форум
IRC канал клуба программистов|Мои статьи |