n2n VPN - много сетевого трафика на суперузле

1208
siege

Я построил P2P VPN между:

  1. Raspberry Pi с Джесси (прикрепленной к ключу LTE) и
  2. Рабочий стол Ubuntu 16.04 (с независимым сетевым подключением)

Как я это сделал: я купил дешевый VPS (для инициации P2P-соединения), apt-get установил n2n на все три машины и настроил виртуальную сеть следующим образом:

VPS («суперузел» на языке n2n):

$> supernode -l 5000

Рабочий стол:

$> sudo edge -d edge0 -a 10.0.0.11 -c mynetwork -u 1000 -g 1000 -k password -l <VPS_IP_ADDR>:5000 -m ae:e0:4f:xx:yy:zz

Raspberry Pi:

$> sudo edge -d edge0 -a 10.0.0.10 -c mynetwork -u 1000 -g 1000 -k password -l <VPS_IP_ADDR>:5000 -m ae:e0:4f:xx:yy:zz

Пока что это работает как шарм. Я проигрывал фильмы через RTSP, SSHed и обратно, копировал файлы, грязные вещи, созданные в Netcat, и многое другое. Но я начал беспокоиться, когда запустил монитор пропускной способности ( bmon ) на VPS. Оказалось, что VPS (суперузел) имеет большой трафик в своей сети iface. Под «много» я ​​имею в виду «столько же, сколько у сверстников». Это не то, что я ожидал бы от P2P-соединения.

Поэтому мои вопросы:

  1. Я правильно использую n2n?
  2. Как предотвратить потерю пропускной способности VPS в моей настройке n2n?
  3. Как сказать, что у меня есть реальное соединение P2P?
  4. Есть еще какие-нибудь инструменты? Мне нужно, чтобы это был P2P.
0

1 ответ на вопрос

0
siege

Я получил ответ от разработчика n2n, поэтому выкладываю его здесь.

То, что я наблюдаю, является следствием того, что узлы не могут установить P2P-соединение. Это связано с тем, что обратное туннелирование UDP заблокировано на некотором этапе. В этом случае трафик возвращается к пути с участием суперузла.

Что касается альтернатив, вот что я нашел (не проверено):

Похожие вопросы