Проанализировать поток через proxy сервер

Смотри в сторону tcmdump / wireshark.

Можешь поймать приходящий и исходящий пакеты и сравнить их.

спс, буду читать. Смежный вопрос - Допустим, что некоторый сервер регает юзеров, которые вводят ему свой gmail, может ли этот сервер запросить у gmail’a страну владельца данной почты? Сливает ли gmail такую инфу?

Смежный вопрос - Допустим, что некоторый сервер регает юзеров, которые вводят ему свой gmail, может ли этот сервер запросить у gmail’a страну владельца данного адреса? Сливает ли gmail такую инфу?

Вводят свой емейл с Гугл почты (user@gmail.com) или используется авторизация через Гугл?

Вводят email. Т.е. может ли этот сервис пойти в гугл и спросить give_me_country_of(Vasya_Pupkin@gmail.com)?

Вводят email. Т.е. может ли этот сервис пойти в гугл и спросить give_me_country_of(Vasya_Pupkin@gmail.com)?

Нет.

Понял, благодарю.

Смотри в сторону tcmdump / wireshark.

tcpdump

Fixed

Всякие google’ы и спец сервисы не находят меня за proxy.

Нуууу… У вас совсем уж лапки. Первым делом загляните в tinyproxy.conf.

И, только вторым смотрите, что же на выходе в заголовках, какой IP-адрес.

Надо иметь обратную связь от процесса, пощупать, а не наугад. А так подозреваю

DisableViaHeader
When this is set to yes, Tinyproxy does NOT add the `Via` header to the requests.

Я больше про AddHeader, хотя, в этом случае спец сервисы точно бы нашли.

А, так вполне, что конечная точка по MTU и TTL может предполагать о наличии анонимизатора или тупо по принадлежности IP VPS к пулу хостинг провайдера. Но, в этом случае определить настоящий адрес клиента не предоставляется возможным.

Меня так сайт интела выкупает, говорит, что из РФ.

Upd. 2ip.ru хорошо проверяет анонимность.

А, так вполне, что конечная точка по MTU и TTL может предполагать о наличии анонимизатора

Можете мысль раскрыть, не совсем въехал. По количеству маршрутизаторов между клиентом и сервером можно делать какие-то догадки, правильно понимаю? Ну мало ли как там пакеты идут, через какие зиг-заги, не? Это число ведь можно подкорректировать на стороне poxy сервера?

TShark

А, так вполне, что конечная точка по MTU и TTL может предполагать о наличии анонимизатора

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

Меня так сайт интела выкупает, говорит, что из РФ.

Кукисы в вашем браузере?

Upd. 2ip.ru хорошо проверяет анонимность.

Из всей онанимости есть только IP и резолвинг. Ну и ещё можно совсем погрубому зарезать размер пакетиков, что бы не кратным разным туннелям было.

Кукисы в вашем браузере?

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

Если последнее, то опять технофашизм какой-то.

Вы про размер пакетов? Если да, то эту хню завели уже не помню сколько лет назад в качестве лайтового обнаружения туннелей (один из fingerprint). Копий об это тоже было сломлено не мало. Режем поменьше и спим спокойно.
ЗЫ Есть ещё динозавры которые продолжают это пользовать. Как 20 лет назад настроили, так и пользуют. Вобчем я бы начал с этого. :)

Ребят, я правильно понимаю, что когда я пишу

$ tshark -T json

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

$ tshark -T json

Чем вам tcpdump не угодил в рамках вашей задачи?

tshark первая тулза при помощи которой я вывел что-то похожее на заголовки всех протоколов пакета. Может tcpdump тоже умеет, не знаю. Вообще для меня не важно, мне нужно тупо диффнуть всю метаинфу на входе и выходе, чем - пофиг

В общем я не нашёл какой-то разницы между пакетами идущими на один и тот же сервер от клиента через прокси и без него. Да, разные адреса, суммы, но по сути одно и то же. Никаких следов адреса реального клиент за прокси я не увидел, я даже не передавал никаких дополнительных опций через tinyconfig.

Хз, может тогда действительно VPS регят где-то диапазон своих адресов и они потом банятся сервисами.

Мужчины, один вопрос: когда открываю https://2ip.ru/, то вижу в поле «Имя вашего компьютера» строкук «vm67245.vps.client-server.site», как она туда попадает? Сначала подумал, что где-то в отсылаемых пакетах, грепнул, нет там такой строки с именем, сменил имя VPS хоста на отличное от этого - эффекта все равно нет, как это туда попадает?

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

Точно. Вроде её даже удалось сменить в настройках VPS’a. Ликбез, если не сложно: у кого она хранится, и как условный 2ip понимает куда надо за ней идти, если она хранится у владельца VPS?

А вообще, конечно, спрятаться за VPS - так себе идея. К чему все эти телодвижения, если ipinfo сервис спокойно запрашивает следующую инфу

privacy: Object,
  vpn: false,
  proxy: false,
  tor: false,
  relay: false,
  hosting: true,
  service: "",

hosting: true? Ну и иди на йух.

У тех, кто держит обратную зону, т.е. у провайдера. Провайдер может делегировать PTR записи на твой dns-сервер

Ребята, всем ещё раз спасибо, в общем я вроде пришёл к какому-то логическому завершению.

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

Вопрос, по винде, соррян, но очень надо. Ситуация Венда используется как шлюз в интернет, подключена к нему по вайфаю, своим кабельным сетевым портом даёт доступ другому устройству. Мне нужно настроить так, что входящий поток из проводного входа использовал прокси. Настройки вендовые настраивают прокси только для самой системы, но не для входящего трафика по кабелю. Как сделать? Какая-то софтина?

Вопрос, по винде, соррян, но очень надо

Иконка «Направление на юг»

ok, х с ней.

Может странная хотелка - какая-то смесь Proxy сервера и таблицы маршрутизации. Например, есть некий сетевой интерфейс eth0 и eth1, хочу брать все пакеты из eth0 и отсылать их через eth1 на (внимание) указанный IP и Port_number. Т.е. если я правильно понимаю, таблицы маршрутизации не работают с портами (это не их уровень), а proxy сервера не могут слушать на всех портах одновременно (или могут?). Решаема ли моя хотелка?

Я про linux кончено же)

нат, форвардинг, маскарадинг

спс, но если дадите больше инфы - будет супер. Схему в общих чертах. Всё, что я до сих пор находил - было мимо. Вся особенность в том, что нужно перекинуть весь поток на один порт proxy сервера. Трафик идёт от девайса, и я вполне допускаю, что он может слать что-то на какие-то спец порты, ковырять это и подстраиваться - у меня вообще нет желания, проще всё разом переслать на прокси.

Посмотрите какое-нибудь руководство по iptables в части цепочек таблицы nat, как правило в качестве примера там будет задачка аналогичная вашей.

у кого она хранится

Храниться у владельца сети.

и как условный 2ip понимает куда надо за ней идти

Так же как и за прямой, зона in-addr.arpa.

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

Зачем?

Схему в общих чертах.

https://upload.wikimedia.org/wikipedia/commons/3/37/Netfilter-packet-flow.svg

ковырять это и подстраиваться - у меня вообще нет желания, проще всё разом переслать на прокси.

А прокси об это уже знает?

Ребята, объясните мне одну ерунду, почему на каждом углу пишут, что сделать transparent прокси сервер - пипец сложно? С чего это, ведь никто не предлагает расшифровывать полезную нагрузку пакета, всё что нужно - прочесть нешифрованную инфу ip заголовка и вставить туда другие адреса. Батюшки, да каждый несчастный роутер с NAT’ом это делает. Tinyproxy заявляет, что https - не, squid - аналогично, о чем говорят все эти мужчины?

почему на каждом углу пишут

о чем говорят все эти мужчины

Что пишут? Где пишут? Кто пишут?

Наверное, этот вопрос надо адресовать туда и тем, кто пишет.

Да в доках пишут (или что-то вроде того, хз). Запарился, всё что мне надо - слать на прокси из хоста-клиент полезный пакет упакованный в доп пакет, дойдя до прокси он пакет раскрывает и отправляет полезный пакет получателю. Если без этих пакетов-матрешек, то адрес отправления полезной нагрузки потеряется на прокси (т.к на хосте-клиенте я с делаю iptables … -j DNAT –to …). Мне казалось, готовые прокси сервера решают именно эту задачу, вместо этого читаю какую-то муть про https, да какая им вообще разница, не надо его расшифровывать.

2.3 HTTPS
Finally, as far as transparently proxing HTTPS (e.g. secure web pages using SSL, TSL, etc.), you can't do it. Don't even ask. For the explanation, do a search for 'man-in-the-middle attack'. Note that you probably don't really need to transparently proxy HTTPS anyway, since squid can not cache secure pages.

Батюшки, да каждый несчастный роутер с NAT’ом это делает.

Модели «несчастных» в студию.

Может подскажите почему не работает.

iptables -t nat -A PREROUTING -i ${iface} -p tcp -j REDIRECT --to-port 9000
iptables -A FORWARD -i ${iface} -o ${oface} -j DROP # только через локальный прокси
iptables -A FORWARD -i ${oface} -o ${iface} -j ACCEPT # обратно - ок
iptables -t nat -A POSTROUTING -o ${oface} -j MASQUERADE # на всякий случай

есть два интерфейса iface и oface, трафик из первого должен пройти через локальный прокси сервер, который ждет его на 9000 порту, выйти через oface сходить кудать и вернуться обратно oface->iface. В общем родил логичную, по-моему схему, но не работает, локальный прокси на 9000 пакеты получает, дальше хз, надо разбираться.

PS: локальный прокси хотел сконфигурировать для соединения с прокси на VPS’e

О сколько нам открытий чудных
Готовят просвещенья дух,
И опыт, сын ошибок трудных,
И гений, парадоксов друг
(c) Асс Пушкинс.

Браво, бурные аплодисменты.

Вообще-то я говорю дело. Просто софтовые прокси сервера слишком высокоуровневое Г, я даже не очень понимаю зачем они такие нужны, видимо если очень нужно кэширование. Именно из-за необходимости устанавливать для такого прокси-сервера соединения они и заявляют - с хттпс не работаем.

А на самом деле эта задача имеет решение и довольно простое. Нужна небольшая утилита, которая на одной стороне завернет пакет в ещё один пакет, на другой стороне развернёт обратно, всё остальное сделает NAT. Я даже уверен, что такое уже существует, я просто не знаю ключевые слова для поиска. От любителей поэзии толку тоже мало.

Я даже уверен, что такое уже существует, я просто не знаю ключевые слова для поиска.

В общем-то и сомневаться было странно - scapy, senip. Первая доступна и как либа.

я просто не знаю ключевые слова для поиска

Тунель

Нужна небольшая утилита

Есть такая, гуглите утилита-сделай-мне-хорошо.exe
Вру вам же «небольшая»
утилита-сделай-мне-хорошо.com

А е если я настраиваю впн между двумя хостасми, смогу ли я установить шлюзом другой конец впн’а? Т.Е. Достатосно ли это низкоуровневая история, что я смогу форвардить пакеты между интерфейсами через iptables, а дальше он идёт по правилу маршрутизации на впс через впн и ни одного пакета мимо?

Другими словами - после настройки впн, ifconfig будет отображать новый интерфейс?

Всё сделал, заюзал wireguard, хороша софтина, образец простоты и минимализма. OpenVPN же наоборот - его название вводит в заблуждение, ожидаешь чего-то простого и открытого, а по факту - гуястое гуйня с платными лицензиями.

В справочных целях оставлю:

$ cat wg_start_client
#/bin/bash

vps_ip=...
inet_dev=wlp0s29f7u5
inet_gate=192.168.1.1

echo "1" > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -o wg0 -j MASQUERADE

ip link add dev wg0 type wireguard
ip address add dev wg0 192.168.3.2/24
wg setconf wg0 /etc/wireguard/wg0.conf
ip link set up dev wg0

ip route delete default
ip route add default via 192.168.3.2 dev wg0
ip route add ${vps_ip} via ${inet_gate} dev ${inet_dev}


$ cat wg_start_server
#/bin/bash

server_iface=ens3

echo "1" > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -o ${ens3} -j MASQUERADE

ip link add dev wg0 type wireguard
ip address add dev wg0 192.168.3.1/24
wg setconf wg0 /etc/wireguard/wg0.conf
ip link set up dev wg0

Тебя палят твой часовой пояс и язык.

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

Да, разумно. Но в моём случае всё оказалось иначе - в девайсе конфигурируется прокси сервер, так вот эта скотина использует его не всегда, периодически конектится с моего настоящего адреса. А я наивный думал, что раз я proxy указал, то это железно.

С wideguard’ом всё ок, ни одного пакета теперь мимо не проходит, «обмануть» сервер девайса удалось.