- This topic has 9 replies, 2 voices, and was last updated 11 years, 11 months ago by
.
-
Posts
-
Всем привет!
Знаю, что тема неоднократно поднималась, но её логического завершения я так и не увидел.
Необходимо реализовать на базе winpkfilter (пример passthru) редирект на заданный порт локального прокси-сервера. И также в обратную сторону при получении ответа.Друзья, очень прошу помощи! Если есть возможность, приведите пожалуйста подкрепляющий пример на си/си++.
Есть подозрение, что если прокси-сервер будет локальным, то не будет возможности перехватывать приходящие на него ответные пакеты.
В таком случае, пусть прокси будет установлен где-нибудь на стороннем сервере (например, виртуальной машине).
Всё ещё прошу Вашей помощи!Требуется что-то подобное http://www.ntkernel.com/w&p.php?id=36 ?
Прошу прощения за неясность. Вот суть задачи:
Имеем компьютер пользователя А, с которого будет осуществляться работа. Этот пользователь хочет запустить некоторое сетевое приложение (будь то браузер, мессенджер, или какой-нибудь самописный софт с выходом в интернет) через прокси сервер.
Для этого предлагается организовать перехват исходящих (а впоследствии и некоторых входящих) пакетов на компьютере A на базе Winpkfilter и перенаправить данные пакеты на сервер B. На сервере B на порту X работает прокси-сервер Socks5, который полученные от А пакеты направлял бы дальше. Полученный ответный пакет сервер B должен возвращать компьютеру A.Есть желание реализовать решение этой задачи на основе примера PassThru.
P.S. Видимо действительно это можно назвать соксификатором, хотя, насколько мне известно, бОльшая часть представленных в интернете соксификаторов работают совсем по другому принципу и они юзермодные.
Что касается части с редиректом, то ничего сложного нет. Видим исходящий TCP SYN пакет (попадающий под наш критерий, скажем идущий на HTTP порт 80) для этого пакета:
1) Аллокируем структуру в которой запоминаем данные для этой новой TCP сессии (адреса и порты).
2) Подменяем IP адрес назначения на адрес компьютера B, порт назначения на порт на котором слушает SOCKS.
3) Пересчитываем контрольные суммы пакета и отсылаем его в сеть.
4) Для пакета полученного от компьютера B проверяем принадлежит ли он одному из сохраненных в первом пункте.
5) Если да, то меняем адрес и порт порт источника на те что были в исходном TCP SYN пакете и посылаем вверх по стеку.Но все бы хорошо, но каким образом SOCKS узнает IP адрес и порт которому изначально направлялось соединение? Мы то их подменили при редиректе. Каким-то образом эту информацию нужно передать от компьютера A компьютеру B. Это можно сделать по дополнительному каналу или добавить дополнительные данные в TCP пакет. Это уже на выбор. Ну а так в общем должно работать.
Большое спасибо, попробую этот вариант.
Ещё в догонку такой вопрос – если есть желание перенаправлять исходящие с компьютера A пакеты не на B, а на локальный прокси-клиент, работающий на порту X интерфейся 127.0.0.1? Насколько мне известно, NDIS физически не видит loopback, значит нужно каким-то образом приделывать драйвер другого уровня (наверно TDI).
Поэтому конкретизирую вопрос: есть ли у кого-нибудь готовые реализации проектов, шаблоны или хотя бы просто пожелания на тему, как можно надёжно и более-менее просто соединить две реализации: WinpkFilter и некий драйвер, работающий с loopback?Для такого редиректа можно использовать не loopback, а реальный локальный адрес. То есть скажем если компьютер A имеет сетевой интерфейс с IP адресом 192.168.1.2 и пытается соединиться скажем с 64.251.25.36:80, то мы можем поступить следующим образом:
1) Для исходящего от клиента TCP SYN пакета меняем адрес назначения с 64.251.25.36 на 192.168.1.2, порт назначения меняем на тот на котором висит SOCKS. Адрес источника заменяем на некий реально неиспользуемый в LAN fake адрес, например это может быть 10.0.0.10. Пересчитываем контрольные суммы и вместо того чтобы послать пакет в сеть посылаем его вверх по стеку.
2) SOCKS сервер отвечает нам пакетом ACK-SYN c адреса 192.168.1.2:SOCKSPORT на 10.0.0.10. Для этого пакета мы меняем источник на 64.251.25.36:80, назначение на 192.168.1.2 и снова после пересчета контрольных сумм вместо того чтобы отправить пакет в сеть посылаем его вверх по стеку.
3) Клиент нам отвечает пакетом TCP ACK с которым мы поступаем аналогично пункту 1.Проще всего совместить WinpkFilter редиректор в одном приложении с SOCKS сервером, проще будет понять куда какое соединение нужно реально направить.
- You must be logged in to reply to this topic.