Превышено время ожидания SSH при попытке подключения к Raspi из-за пределов локальной сети

Вероятнее всего raspberrypi.local сопоставляется с IP-адресом, отличным от 93,36,114,204 . Если вы получили этот адрес из отдельного документа, возможно, они просто перечислили любой IP-адрес, на который он разрешен в их системе. Вы можете попробовать getent hosts raspberrypi.local или gethostip raspberrypi.local - посмотреть, какой адрес он на самом деле соответствует .

-121--174147-

Мне кажется, что LOKI делает именно то, что вы ожидаете. Он получил пакет запроса ping на ue0 и передает его em0 . Если он получил ответ ping на em0 , он передаст его на ue0 .

Проблема заключается в ROUTER. Он получает запрос ping от 192,168,200,3 на стороне локальной сети (но это не имеет значения). При отправке ответа ping на 192,168,200,3 он просматривает таблицу маршрутизации. Сторона LAN - 10,0,0,0/24 (или аналогичная), поэтому ответный пакет отправляется на шлюз по умолчанию МАРШРУТИЗАТОРА, который является стороной WAN в общедоступном Интернете.

ROUTER использует преобразование сетевых адресов (NAT) для подделки сети 10,0,0,0/24 за вашим истинным открытым IP-адресом (назначенным Интернет-провайдером стороне WAN МАРШРУТИЗАТОРА). Адреса RFC1918 являются частными и не могут быть доступны в общедоступном Интернете и всегда будут находиться за NAT.

Можно поместить статический маршрут в ROUTER, чтобы эксперимент ping работал, но он все равно будет изолирован от общедоступного Интернета. Вы можете включить NAT на LOKI, в этом случае у вас есть двойной NAT к Интернету (который работает нормально, но довольно бессмысленно). Если вам нужен только брандмауэр второго уровня, вы можете сделать LOKI мостовым брандмауэром и запустить 10,0,0,0/24 на обеих сетевых платах. Если вы хотите разместить службы, работающие через Интернет, и у вас есть только один открытый IP-адрес, вы вынуждены использовать правила пересылки портов на ROUTER.

-121--166234-

Если используется обычное ftp-соединение, то по умолчанию возникает угроза безопасности, поскольку соединение не шифруется. Вы рискуете представить критические данные сторонней стороне. При запуске ssh-сервера в этой системе можно использовать sftp insted для туннелирования сеанса FTP через ssh-сервер.

0
26.07.2018, 11:07
1 ответ

Проблема похожа на хорошо известную проблему MTU/фрагментации. Замените MTU как для ssh -сервера, так и для ssh -клиентских сетевых интерфейсов на такое же меньшее значение. Предположим, что ваш сетевой интерфейс ssh прослушиваетeth0(и обнаруживает его с помощьюifconfig). Проверить текущее значение MTU для интерфейса:

cat /sys/class/net/eth0/mtu

Временно замените текущий MTU (, который, вероятно, равен 1500 )для интерфейса с меньшим номером, например:

sudo ifconfig eth0 mtu 1496

или

echo 1496 | sudo tee /sys/class/net/eth0/mtu

Если число 1496 не решило проблему, попробуйте MTU 1250 и т. д. Если проблема исчезнет с некоторым значением MTU, сделайте изменения для интерфейса постоянными.

Прочтите это внимательно:http://www.snailbook.com/faq/mtu-mismatch.auto.html

0
28.01.2020, 04:16

Теги

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