Соединению SSH отказывают из моей LAN
Кажется, что устройство является удаленным. Принятие Linux...
ssh remote_host 'dd if=/dev/sdb1' | cp --sparse=always /proc/self/fd/0 new-sparse-file
Если локальный...
dd if=/dev/sdb1 | cp --sparse=always /proc/self/fd/0 new-sparse-file
Это дает Вам изображение, которое является монтируемым. Однако при получении по запросу его по сети затем, у Вас было 1,2 ТБ сетевого трафика (обычно узкое место) и загрузка ЦП ssh и sshd.
Если Вы вытягиваете так много через сетевой и сетевой трафик, стоит Вам денег...
ssh remote_host 'dd if=/dev/sdb1 | gzip ' | gunzip | cp --sparse=always /proc/self/fd/0 new-sparse-file
Не возможно соединиться с переданным порту общедоступным IP-адресом из той же LAN. Для объяснения этого мне будет нужен пример.
Давайте предположим, что частный IP Вашего маршрутизатора 192.168.1.1 с общедоступным IP 10.1.1.1. Ваш сервер находится на 192.168.1.2 портах 2222. Вы настраиваете перенаправление портов от 10.1.1.1:1111 до 192.168.1.2:2222.
Если кто-то в Интернете (10.3.3.3) хочет говорить с Вами, они генерируют пакет:
Source: 10.3.3.3 port 33333
Dest: 10.1.1.1 port 1111
Ваш маршрутизатор получает пакет на 10.1.1.1 и переписывает его:
Source: 10.3.3.3 port 33333
Dest: 192.168.1.2 port 2222
Ваш сервер получает тот пакет и отправляет ответ:
Source: 192.168.1.2 port 2222
Dest: 10.3.3.3 port 33333
Ваш маршрутизатор получает тот пакет на 192.168.1.1 и переписывает его:
Source: 10.1.1.1 port 1111
Dest: 10.3.3.3 port 33333
И работы соединения, и все счастливы.
Теперь предположите, что Вы соединяетесь из своей LAN (192.168.1.3). Вы генерируете пакет:
Source: 192.168.1.3 port 33333
Dest: 10.1.1.1 port 1111
Ваш маршрутизатор получает пакет на 10.1.1.1 и переписывает его:
Source: 192.168.1.3 port 33333
Dest: 192.168.1.2 port 2222
Ваш сервер получает тот пакет и отправляет ответ:
Source: 192.168.1.2 port 2222
Dest: 192.168.1.3 port 33333
Вот то, где мы поражаем проблему. Поскольку целевой IP находится на Вашей LAN, Ваш сервер не отправляет тот пакет на маршрутизатор для перезаписи. Вместо этого это отправляет его непосредственно в 192.168.1.3. Но та машина не ожидает ответ от 192.168.1.2 портов 2222. Это ожидает один от 10.1.1.1 портов 1111. И таким образом, это отказывается слушать этот "поддельный" пакет, и вещи не работают.
Путем я двигаюсь, это должно настроить мой маршрутизатор (который также обеспечивает DNS для моей LAN) возвратить частный IP-адрес моего сервера, когда я ищу свое имя хоста DDNS. Тот путь, когда я нахожусь в своей домашней сети, я соединяюсь непосредственно с сервером и пропускаю перенаправление портов. (Это решение только работает, когда Ваш порт вперед не изменяет номер порта, просто IP-адрес. И у Вас может только быть 1 сервер на общедоступное имя хоста.)
Порты 23 и 80 открытый то, потому что для соединения с Вашим маршрутизатором, портом 23 к telnet к Вашему маршрутизатору и порту 80 иметь Ваш WebUI Вашего маршрутизатора. Так как только эти два являются открытым перенаправлением портов, не находится в изображении. Таким образом, перезапуск маршрутизатора и Ваш перезапуск сервера SSH помогут.