Вероятнее всего 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-сервер.
Проблема похожа на хорошо известную проблему 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