"Проверочный туннель" для пакетов(пакетфильтр)

[Crystallon]

Уважаемые пользователи форума "клуб программистов", умоляю подскажите способ решения проблемы, я уже что только не придумывал, на каждую мысль найдется но которое убивает ее смысл напрочь...*facepalm*
В общем ситуация такая:
Необходимо сделать программу простейший фильтр пакетов, он должен просматривать все пакеты на определенном порту и сверять их с маской, при соответствии пропускать и в обратном случае соответственно не пропускать. Сегодня меня посетила как мне сначала показалось хорошая мысль что можно на порт той программы пакеты которой я хочу фильтровать повесить свою программу которая бы проверяла пакеты по маске и при соответствии уже отправлять их дальше целевой программе которая переместится на другой порт, но потом до меня дошло что при этом все соединения в целевой программе будут определяться как с IP 127.0.0.1, но это еще ладно подумал я, но потом понял еще одну вещь которая убила всю идею - поскольку у меня конечно нет исходников целевой программы(в обратном случае все это не затевалось бы) и пакеты в ней шифруются я не смогу определить какому пользователю слать ответные пакеты от этой проги...
Весь гугл я уже перерыл, из более менее подходящего нашел только упоминание о исходнике фаерволла на делфи в журнале хакер, но это выпуск 2004 года т.ч. найти я смог только сам журнал а образ DVD приложения или отдельно этот самый исходник не смог. =(
И по сути основная проблема - нужно чтобы этот пакетфильтр работал на линуксовом эмуляторе Wine(тот способ который я описал выше еслиб не проблема с тем куда отправлять ответные пакеты подошел бы идеально т.к. я уже тестил клиент-серверное приложение на wine и все работало без каких либо нареканий).
По сути наверно единственный идеальный вариант был бы еслиб я нормально знал Java, думаю на нем можно было бы без проблем написать кроссплатформенный пакетфильтр...
В принцыпе это все, заранее огромное спасибо за любую помощь, просто уже руки опускаются. =(

[Человек_Борща]

Вообще-то, программы мониторинга трафика называются снифферами. Вот он них и толкай.

http://electro-2006.narod.ru/text/stati/snifer.html
http://articles.org.ru/cn/showdetail.php?cid=5377
http://allcheats.ru/t45177/
http://aftergod.ucoz.ru/publ/1-1-0-4
http://www.delphimaster.ru/cgi-bin/f...1300814099&n=4

Исходники с sourceforge.net: http://sourceforge.net/search/?q=sni...5D=trove%3A265

включай руки, мозги и гугл=)

[Crystallon]

Сниффер не катит, то что делаю я скорее примитивный фаерволл...сниффер работает не на низжем уровне "пути пакетов" и способен только просматривать пакеты а не блокировать их(ну на сколько я уверен...я ошибаюсь?оО).
Вобщем если я ошибаюсь спасибо за инфу, надеюсь твои ссылки мне помогут)
P.S. Мозги включены уже давно и кипят от нагрузки, видать пора новые покупать...

[Crystallon]

Вот же блин, все ссылки выше я уже серфил(не зря же говорю что весь гугл перерыл) >_< и ничего из этого в Wine не работает...там из винсокета реализовано похоже только самое основное...чеж делать то ><
Никак нельзя принять пакет tserversocket'ом в моей проге и отправить его дальше к целевой проге без изменений? т.е. абсолютно такой же пакет с такими же данными о доставке? Тоесть по сути я буду фильтровать только входящие пакеты(от клиента к серверу), а от сервера к клиенту они будут идти напрямую а не через мою прогу, но меня это устраивает, для моих целей достаточно фильтровать пакеты в 1 любую сторону.

[Человек_Борща]

Думаю вам подойдут асинхронные сокеты.
Клиент присылает плохой пакет, сервер определяет это и отправляет клиенту сообщение об этом. В точности до на оборот можно и с клиентом сделать для сервера. С асинхронными сокетами это вполне возможно.
Чтиво

[Crystallon]

Об асинхронных сокетах я в обобщенном виде знаю, но что-то не понимаю как они могут мне помочь решить задачу? Моя задача состоит примерно в этом:

1. Пакет отправляется от клиента к целевому серверу->
2. Вместо целевого сервера на его порту вертится моя программа и читает пакет вместо целевого сервера->
3. Моя программа после прочтения пакета в случае если он удовлетворяет маске отправляет его целевому серверу в неизменном виде(в таком виде в котором он был получен от клиента, с теми же данными отправки итп)->
4. Целевой сервер получает от моей программы этот самый пакет, а ответную реакцию на этот пакет какой бы она не была он отправляет не моей программе а клиенту т.к. в данных доставки пакета были изначальные данные(т.е. данные клиента).
Итог: клиент-серверное соединение осуществляется через мою программу, а сервер-клиент напрямую

Собственно такое вообще возможно? Я себе это вроде представляю но не уверен что это реально... Ну а если реально то как реализовать не представляю т.к. незнаю как отправить пакет в неизменном виде...

По сути это тотже сниффер пакетов только он должен сниффить пакеты сам у себя :D

[Человек_Борща]

Ну тогда можете взять пример с сетевых роутеров или маршрутизаторов.
Нет программы которая снифает весь трафик и анаизирует его. Есть устройство на которое настроены компьютеры, и устройство рулит входящим на него трафиком, без потери скорости передачи данным между тамошним юзером и инетом.

Программа и сервер и клиент подключаются к хабу(третья программа) и общаются друг с другом через этот хаб. Хаб в свою очередь анализирует пакеты и там читает информацию о том куда идёт этот пакет.
Ну всякие там проверки и прочее.

так сказать третья сторона.

[Crystallon]

Да вы меня поняли, это уже радует, значит я не сошел с ума :D вы обьяснили иначе то о чем говорю я, но ни слова ни сказали о том как мне отправить полученный пакет куда-то еще сохранив его в первоначальном, нетронутом состоянии, ведь если я по стандарту приму пакет от клиента с помощью TServerSocket.ReceiveText и отправлю его целевому серверу с помощью TClientSocket.SendText то в данных отправки будет уже совершенно другое, и ответ целевой сервер выкинет моей программе, а моя программа хз че с этим ответом делать т.к. систему идентификаторов я могу сделать только на стороне моей проги, на стороне клиента я ее сделать немогу, соответственно я просто не могу знать для какого клиента предназначается ответ от целевого сервера, т.е. ответ целевой сервер должен дать сразу клиенту, т.е. соответственно от моей проги до целевого сервера пакет должен прийти в томже виде в котором он пришел от клиента до моей проги, чтобы целевой сервер думал что пакет к нему приехал сразу от клиента и знал что отвечать надо тоже клиенту.

Приведенный вами выше рисунок действительно верен, только вот он работает только в том случае если все 3 программы "понимают" друг друга и знают какой пакет куда нужно отправлять, а я немогу управлять этим "процессом" в целевом сервере т.к. исходников нет =)

[Crystallon]

Боже какойже я идиот...мои мозги походу перегрузились конкретно...
Написав кучу постов тут я наконец понял что я заблуждался что не смогу определить кому слать ответ т.к. думал что обрабатывать пакеты от целевого сервера будет 1 клиентсокет, а потом до меня дошло что в 1 клиентсокет это сделать даже невозможно, и после до меня дошло и то что если для каждого соединение 1 клиентсокет то ими легко можно управлять...вобщем ппц истина была куда проще чем я думал xD

[Человек_Борща]

Значит ваша программа так или иначе является сниффером который лезет в активное соединение 2 других программ.

а это значит, что:

Необходимо сделать программу простейший фильтр пакетов, он должен просматривать все пакеты на определенном порту и сверять их с маской, при соответствии пропускать и в обратном случае соответственно не пропускать.

Не буду говорить что это не возможно. Может вам стоит почитать RFC спецификацию протокола на котором "говорят" нужные вам программы. И тогда сможете понять, возможно ли чужой программе не дублировать, а вынимать пакеты из активной сессии двух других программ.

Чтиво RFC-1180
Чтиво от мелкомягких