На VPN, пинг работает только для первого пакета и не может ssh между машинами

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

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

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

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

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

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

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

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

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

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

обновление

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

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

26
задан Brick
19.03.2023 4:14 Количество просмотров материала 3676
Распечатать страницу

1 ответ

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

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.

Примечание: изменения выше должны быть сделаны с корневым доступом.

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

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

0
отвечен Brick 2023-03-20 12:02

Постоянная ссылка на данную страницу: [ Скопировать ссылку | Сгенерировать QR-код ]

Ваш ответ

Опубликуйте как Гость или авторизуйтесь

Имя
Вверх