Comments 23
К результатам спидтеста неплохо бы добавить информацию о том, какова скорость канала без VPN и с другими вариантами VPN на том же канале (скажем, OpenVPN без I2P, WG с I2P). По моему ощущению, OpenVPN через TCP - это те ещё тормоза, даже если его ни во что не упаковывать, и чем больше latency до удалённого хоста - тем всё печальнее в геометрической прогрессии. А VPN, в отличие от прокси, подразумевает не только "бытовое использование десктопной системы"...
Спасибо за комментарий. Дополнил скрин замера скорости комментарием "Один из замеров на канале с честными 200Мб/сек (значения всегда прыгают)".
VPN, в отличие от прокси, подразумевает не только "бытовое использование десктопной системы"
не спорю; я описал для чего использую VPN именно я в домашних условиях и в описанном случае; это действительно только "бытовое использование десктопной системы"
Большая проблема при тунелировании через TCP - алгоритм Нагла, особенно в сочетании с отложенным ACK (а обычно это так и получается). Если выставить TCP_NODELAY на сокете, то уже будет сильно лучше. Применительно к openvpn кажется надо tcp-nodelay написать в конфиг.
Я правильно понимаю что i2p запускался с дефолтным конфигом? И при этом такая конструкция дает десятки мегабит скорости? Удивительно! Лично я смотрел на i2p с десяток лет назад, и скорости там были дай бог мегабит... это получается сеть i2p живет и в качестве ее нод выступают ноды на мощных каналах?
Верно, i2pd с дефолтным конфигом. Конфигурируются только туннели (клиентский и серверный).
У I2P два разных клиента сети. Я пишу о том, который на C++ (i2pd). Обычно же люди, гугля, приходят к Java-реализации. На ней я описанное не пробовал, но во многих других тестах "Java-роутер" дает сильные просадки по скорости и по потреблению ресурсов.
в качестве нод I2P выступают ноды на мощных каналах
Узлы I2P практически невозможно модерировать, поэтому сеть полна разношерстными серверами, среди которых хорошие VPS в датацентрах и подкроватные полухромые сервачки на USB-модемах и одноплатниках.
Весьма хорошее качество туннелей во многом обусловлено их "шириной" (quantity). Можно представить туннель как логический канал связи, состоящий из физических нитей. Количество таких нитей - параметр quantity. Трафик делится между всеми нитями, что в некоторой степени нивелирует "хромые" узлы в туннеле, не давая им единолично заткнуть сообщение конечных участников в минимум.
Подробнее про туннели I2P можете почитать тут.
и подкроватные полухромые сервачки на USB-модемах и одноплатниках.
сначала вроде и обидно, а потом.... Вместе мы сила!)
Конечно! Каждый роутер в сети - часть ее общей мощности.
В I2P есть базовые маханизмы для идентификации, чтобы при построении туннелей можно было выбирать узлы, которые наверняка дадут хороший перформанс: флаг доступности (доступен ли извне или сидит за NAT) и лимит скорости для транзитных узлов, установленный оператором в конфиге. Все это не гарантирует хороший физический канал, но дает надежду.
Пока почитаю подробнее - но сразу возник вопрос: если связность и защиту обеспечивает i2p - зачем там вообще OpenVPN?
Простого TCP соединения с PPP в нем недостаточно разве?
Спасибо за комментарий. Я думал про pptp, ведь там данные бегают поверх TCP-сокета, но уперся в необходимость PPP-соединения, то есть линка на канальном уровне, который ниже TCP/UDP. Увы, i2pd не предоставляет туннели канального уровня.
Можете подсказать (или развить) ход вашей мысли?
Канал организуется непосредственно на уровне tcp соединения, вот точно так же как по модемной линии, с помощью pppd и netcat
В канале поднимается PPP ну а дальше все как во времена аналоговых модемов.
Более того, я сам это когда-то делал, и с теми же целями, только задача была в проходе по 443 порту сквозь файрвол. Но конфиг давно утерян, а восстановить сходу вчера у меня не получилось )
В интернетах же, такое впечатление, это знание давно забыто и похоронено. Найденное с использованием pptp это другое, по сути похожее, но другое.
Вот кажется, там на серверной стороне pppd запускался на порту через inetd, a на клиентской уже через netcat. Очень уж давно это было, надо на выходных попробовать)
А то есть ещё SLIP, тоже может, но это не пробовал никогда
Интересная идея... Если получится, напишите статью?
Напишу ))
Пока вот получилось:
На обоих сторонах обнуляем /etc/ppp/options (временно, чтобы не мешало)
На серверной запускаем например так:
pppd nodetach persist 192.168.50.1:192.168.50.2 pty "nc -l 5005"
На локальной так (туннель на 127.0.0.1 утановлен):
pppd nodetach persist pty "nc 127.0.0.1 5005"
И оно работает:
local IP address 192.168.50.2
remote IP address 192.168.50.1
ping 192.168.50.1
PING 192.168.50.1 (192.168.50.1) 56(84) bytes of data.
64 bytes from 192.168.50.1: icmp_seq=1 ttl=64 time=59.2 ms
64 bytes from 192.168.50.1: icmp_seq=2 ttl=64 time=50.4 ms
Только довести до ума, засунув настройки в /etc/ppp/options
В каких случаях это может быть нужно?
Ваш сервер забанен РКНом по IP
Используемый между вами и вашим сервером впн-протокол забанен РКНом по сигнатурам.
И всё. Верно?
Почему сразу РКН и почему именно это вас так заинтересовало? )
У нас сейчас санкций больше чем у Ирана, на некоторые технические сайты отсюда просто больше не пускают. Это важнее РКН или чьих-то опасений.
Ну замените эти три буквы на "провайдер/регулятор". Я в курсе, что в разных странах/у разных провайдеров есть свои, иногда весьма вольные и даже законодательно не подкреплённые особенности и ограничения.
По сути-то есть ответ на мой вопрос?
По сути это "проброс порта", похожий в чем-то на явление квантовой запутанности:
Зная адрес второй точки внутри сети i2p можно пробросить этот порт через пространство сети на любое расстояние, понятия не имея где именно эта вторая точка находится.
А уж как именно использовать этот порт - дело того, кто его пробрасывает.
Можно подключить там к примеру веб-систему, чтобы подключаться к своему любимому домашнему серверу из внешнего мира, не имея белых IP-адресов.
Мне пока что хватает твоего тора, через yggdrasil, даже юпупчик посмотреть можно :-)
В openvpn пару лет уже можно использовать fingerprint вместо центра сертификации.
Вот есть пример на эту тему.
OpenVPN & i2pd: VPN через I2P (часть 2)