n2n VPN - много сетевого трафика на суперузле
Я построил P2P VPN между:
- Raspberry Pi с Джесси (прикрепленной к ключу LTE) и
- Рабочий стол 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-соединения.
Поэтому мои вопросы:
- Я правильно использую n2n?
- Как предотвратить потерю пропускной способности VPS в моей настройке n2n?
- Как сказать, что у меня есть реальное соединение P2P?
- Есть еще какие-нибудь инструменты? Мне нужно, чтобы это был P2P.
1 ответ
Я получил ответ от разработчика n2n, поэтому выкладываю его здесь.
То, что я наблюдаю, является следствием того, что узлы не могут установить соединение P2P. Это связано с тем, что обратное туннелирование UDP заблокировано на некотором этапе. В этом случае трафик возвращается к пути с участием суперузла.
Что касается альтернатив, вот что я нашел (не проверено):