Я настраиваю несколько камер для удаленного просмотра. Каждая камера подключена к Raspberry Pi (работает последняя версия raspian). У меня есть одна камера в моем доме ("Сайт А") и одна в доме моих родителей ("Сайт Б"). У меня также есть третий сайт ("Сайт C"), который имеет статический IP-адрес и устройство VPN, которое я использую в качестве концентратора. Конкретные соединения:

  • Сайт A <=> Сайт C через туннель IPsec. На сайте A работает VPN-сервер StrongSwan на виртуальной машине lubuntu, которая размещена на машине с Windows 10. На сайте B есть VPN-маршрутизатор. Здесь работают два туннеля: один соединяет подсеть сайта A с локальной подсетью сайта C. Второй соединяет подсеть сайта А с подсетью, которую сайт С определяет для любых вызывающих участников Road Road Warriors.
  • Сайт B <=> Сайт C через IPsec/L2TP в конфигурации "Road Warrior". Это означает, что только один Raspberry Pi с камерой находится на VPN с сайта B.
  • Нет прямой связи между сайтом А и сайтом Б.

Каждый сайт имеет свою собственную подсеть: Сайт A - это 192.168.1.0/24, Сайт B (один компьютер, как видно из VPN) - 192.168.2.1/32, а Сайт C - 192.168.3.0/24. Таблицы маршрутизации устанавливаются по мере необходимости на машинах, участвующих в передаче через VPN.

Оба Raspberry Pis подключены по беспроводной сети. Один на сайте B показывает высокое качество сигнала (68/70), а другой на сайте A показывает качество от среднего до низкого (40/70).

С компьютера с Windows 10 в подсети Site A (проводное соединение) я могу подключиться к обоим Pis с помощью программы установки. Это прекрасно работает на обеих машинах - там действительно нет заметного отставания. С того же компьютера с Windows 10 с помощью Internet Explorer я могу получить доступ к веб-странице, размещенной на любом компьютере. (На B у меня есть собственная настройка веб-страницы. На А пока у меня есть тестовая страница Apache.) Это загружает немного медленно, где есть изображения, но хорошо, учитывая беспроводное соединение и производительность пи.

Сейчас я пытаюсь настроить зеркало сайта на сайте B на Pi на сайте A. Я начал с того, что попытался скопировать конфигурационные файлы напрямую из B в A, и это зависало. Затем я попробовал несколько экспериментов, чтобы увидеть, что не так:

  1. Пинг от Пи от А до Б. Это обычно работает на первом пакете, который выходит и терпит неудачу на всех последующих пакетах. Если я остановлю эхо-запрос и сразу же начну снова, все пакеты со второй попытки потерпят неудачу. Если я немного подожду между попытками, то вернусь к исходному поведению, когда первый пакет делает это, а последующие пакеты теряются.
  2. Пинг Б к Пи на А. Так же, как # 1.
  3. Запустите трассировку от Пи на А до Б. Это проходит через разумное количество прыжков и идентифицированных прыжков (т.е. не отображаются как *.*.*.*) смотреть прямо.
  4. Запустите трассировку от B до Pi на A. Так же, как № 3.
  5. Запустите wget на Pi на A, чтобы получить веб-страницу, размещенную на B. Это висит долго, иногда не удается, но если я позволю этому бежать достаточно долго (я пошел спать и вернулся), это, очевидно, получит это в конечном счете.
  6. Запустите wget на B, чтобы получить веб-страницу, размещенную на Pi на A. То же, что и № 5. (На данный момент Pi на A просто показывает стартовую страницу Apache.)
  7. Я искал дублированные IP-адреса, и я не вижу ни в одной из подсетей.
  8. Запустите wget для каждого Pi, чтобы получить домашнюю страницу с главного сайта новостей. Оба Пис могут выполнить эту задачу практически мгновенно.
  9. Пинг с компьютера с Windows 10 на сайте A на оба Pis. Это работает для обоих Pis, то есть пакеты не теряются.

Когда я увидел плохое беспроводное соединение с Pi на сайте A, я подумал, что это могло бы объяснить все, но теперь я совсем не убежден. Плохая связь может объяснять 5-6 выше и соответствовать 3-4, но я не думаю, что это объясняет 1-2 или 9. Это также не объясняет, почему все это работает так хорошо на проводных машинах Windows в подсети A, и не объясняет, как быстро завершается # 8.

Я нашел несколько тем на SE и других сайтах, описывающих поведение, например, 1-2, но, как я могу судить, выявленные там причины не относятся к моей ситуации. В частности, у меня определенно есть маршрут между компьютерами, и у меня нет конфликтов IP-адресов.

Я могу придумать несколько способов обойти эту проблему, но я бы хотел понять, как здесь работает. У кого-нибудь есть представление о том, что здесь может быть не так? Это просто плохое беспроводное соединение с одной машиной? Если так, то как это сочетается с тем, что работает? Если не сила беспроводного соединения, что еще может вызвать это?

ОБНОВИТЬ

Я переместил Pi на сайте A в проводное соединение. Это должно устранить любые проблемы из-за плохого соединения WiFi. Это, кажется, не меняет поведение.

Я также оставил пинг от А до Б довольно долгое время. Я получаю странное поведение, что каждый 300-й пакет работает, а все остальные отбрасываются. Например, пакеты 1, 301, 601 и т.д. Я позволил этому идти до 1201. Такое поведение, по-видимому, повторяется.

1 ответ1

0

Я наконец решил эту проблему, изменив настройки на (виртуальной) машине Linux, на которой размещен VPN-сервер на сайте А. Мне пришлось изменить один из параметров системы:

echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects

Хотя это работает и, следовательно, решает проблему (пока!), Я не понимаю, почему все работает с использованием клиентов Windows и не работает с клиентами Linux. Если кто-нибудь придет с таким более широким ответом, я хотел бы увидеть его!

Для полноты, вам также нужны эти, я считаю:

echo 1 > /proc/sys/net/ipv4/ip_forward
echo 0 > /proc/sys/net/ipv4/conf/all/accept_redirects

В моем случае эти значения уже были установлены как таковые. Вы также можете сделать их постоянными, отредактировав /etc/sysctl.conf чтобы отразить те же значения, что и выше для net.ipv4.ip_forward , net.ipv4.conf.all.accept_redirects и net.ipv4.conf.all.send_redirects .

Примечание. Указанные выше изменения необходимо выполнить с правами root.

Сначала я выполнил версию командной строки с помощью echo а затем перегрузил все, что означало, что я выполнил sudo sysctl --system , затем sudo IPsec restart , а затем команды для инициализации моих конкретных соединений. Я не уверен, что все эти "перезапуски" были необходимы, хотя.

Я нашел большую часть этой информации на этом сайте, который также содержит дополнительную информацию, которая может помочь кому-то еще в решении другой проблемы.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .