Здравствуйте форумчане.Не хочется изобретать велосипед и тратить вагон времени на его написание, возможно уже есть что-то подобное и написанное более умными людьми.
Необходимо разделить исходящий трафик на 6 потоков отправить его на разные порты, с другой стороны принять его, собрать воедино и отправить по назначению.
Это не обязательно должен быть прокси но приведу пример на нем:
включаем сокс прокси, он слушает локально на 5555 порту, все что принимает он делит на 6 частей и отправляет на 10.20.30.40 на порты 1111 2222 3333 4444 5555 6666.
на 10.20.30.40 работает такой-же прокси, который слушает 1111 2222 3333 4444 5555 6666 и из пришедших пакетов формирует один поток отправляя его дальше.Известно ли что-то с таким функционалом?
> Необходимо разделить исходящий трафик на 6 потоков отправить его на разные порты,
> с другой стороны принять его, собрать воедино и отправить по назначению.Один вопрос: зачем?
> Один вопрос: зачем?скорость передачи данных по ssh в i2pd увеличить за счет увеличения количества каналов приема-передачи между источником и приемником.
по умолчанию канал один, настройками не решается, все дополнительно открытые используются поочередно после смерти текущего.
>на 6 потоковПочему на 6, а не на 6000?
>на разные портыПочему не на разные IP? Могут прослушиваться на одной машине.
Я бы строил все это на iptables/nftables. Если пакет идет на особенный хост, он попадает в цепочку, где хост и порт заменяется на "синонимы" из списка/диапазона портов. На хосте получателе пакетов все это обратно переправляется, пакеты принимаются и обрабатываются.
Для UDP должно работать.Но все это на самом деле не решает проблему наблюдения, если весь трафик сохраняется и анализируется. Отправитель у всех пакетов будет один и тот же, сопоставить не проблема. В том числе автоматически (простенький специализированный ИИ встроить в систему DPI сейчас не проблема).
Более или менее соответствует https://www.multipath-tcp.org/ поверх нескольких физических интерфейсов.
Благодарю за ответ!> Почему на 6, а не на 6000?
нужно ускорить ssh в i2p, 6000 излишне.
> Почему не на разные IP? Могут прослушиваться на одной машине.
изучаю i2pd в свободное время, думал можно настройками добится нескольких соединений с нужным хостом, оказалось нельзя, можно построить один исходящий и один входящий туннель длинной до 8 точек.
все остальные туннели являются запасными на случай обрыва основного.
получается передача данных между усточником и приемником всегда идет по одной(количествено) цепочке.
это медленно если сидишь за натом а я за ним.
мне интересно увеличить количество цепочек и посмотреть на прирост скорости.i2pd позволяет соединять 2 компа через туннели так что порт удаленной машины будет доступен локально.
например по ssh к удаленному компу можно подключится так ssh user@127.0.0.1 -p 9022
где локальный 9022 это проброшенный 22 с удаленного компа.идея проста, приведу пример на двух портах вместо шести:
пробрасываем 1111 2222 с удаленного компа на локальный,
пробрасываем 3333 4444 с локального на удаленный.на локальном запускаем сокс прокси который слушает на 5555, все что придет разделяет на два потока и отправляет на 1111 2222 и слушает ответ на 3333 4444.
на удаленном запускаем что-то вроде сокс прокси которое слушает 1111 2222 и соединяет пришедшее в один поток, который направляет или на выход с интерфейса на котором запущен или например в какой-то сокс5 прокси который уже направляет трафик к цели.
ответ цели отправляем на 3333 4444.получается достичь обмена с целевым компом не по одной цепочке а по двум что должно повысить скорость вдвое.
> Я бы строил все это на iptables/nftables. Если пакет идет на особенный
> хост, он попадает в цепочку, где хост и порт заменяется на
> "синонимы" из списка/диапазона портов. На хосте получателе пакетов все это обратно
> переправляется, пакеты принимаются и обрабатываются.
> Для UDP должно работать.интересно, если можно организовать ротацию может получится, например весь трафик на локальный порт 1111 раскидывать попакетно на список портов пока он не закончится..
на удаленном потом принимать с портов и собирать обратно..сейчас совместно с дипсиком пытаюсь это сделать в формате прокси, пока неудачно.
попробую на iptables, может получится, жаль только времени 2 часа после работы на все про все.> Но все это на самом деле не решает проблему наблюдения, если весь
i2pd возможно решает, не разобрался до конца в нем
> трафик сохраняется и анализируется. Отправитель у всех пакетов будет один и
> тот же, сопоставить не проблема. В том числе автоматически (простенький специализированный
> ИИ встроить в систему DPI сейчас не проблема).тут чуть другая задача, у меня нет квалификации чтобы от DPI спрятаться, просто хочу скорость работы в сети увеличить без ущерба анонимности.
> Более или менее соответствует https://www.multipath-tcp.org/ поверх нескольких физических интерфейсов.Спасибо, буду ознакамливаться, вдруг подойдет!
для одного соединения простой ответ - нет, нельзя.
Представьте от вашего ссш улетают 6 пакетов в разные порты, в силу разных причин в точну назначения они прибывают в случайном порядке а не в том в каком их отправил источник ssh клиент. Вопрос - что делать получателю? Варианты:
- взять только один нужный, остальные считать потерянными/ошибочными и ждать пока придет переотправка
- буферизовать их все и собирать вместе пока не будут полученые все кусочкиИ это только одна возможная проблема.
Вывод: в любом случае результирующая скорость для одного потока не будет выше.