4

У меня есть сервер SSH за маршрутизатором NAT. Машины в той же (NAT) сети, что и SSH-сервер, могут подключаться к SSH-серверу только через IP-адрес локальной сети, а не WAN-IP. Зачем?

Моя сеть выглядит так:

(the Internet, via Comcast)
      |
      | (cable line)
  comcast modem. ← External IP of a.b.c.d,
      |            internal IP of 10.1.10.1 on 10.1.10.0/24
      |
      |
   box running sshd  (10.1.10.201)

Я запускаю службу SSH за маршрутизатором Comcast, выполняющим NAT. Используя IP-адрес, полученный выше, я могу запустить ssh me@«that IP» из любого места в Интернете, и я получу услугу SSH. Если я выполню ту же команду из сети 10.1.10.0/24 прямо внутри маршрутизатора, время соединения истечет.

Маршрутизатор Comcast настроен для переадресации портов на машину SSH через стандартный порт.

  • Маршрутизатор comcast отвечает на эхо-запросы как на внутренние, так и на внешние IP-адреса.
  • Коробка с запущенным sshd отвечает на пинги

Устройство представляет собой кусок нежелательной SMC Networks SMCD3G.

Выполнение wireshark на машине sshd при попытке ssh 10.1.10.201 дает нормальный вид трафика. Попытка ssh a.b.c.d дает следующее:

Source       Destination  Info
10.1.10.11   10.1.10.201  39946 > ssh [SYN] Seq=0 Win=14600 Len=0 MSS=1460
10.1.10.201  10.1.10.11   ssh > 39946 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0
10.1.10.11   10.1.10.201  39946 > ssh [RST] Seq=1 Win=0 Len=0

10.1.10.11     10.1.10.201  39946 > ssh [SYN] Seq=0 Win=14600 Len=0 MSS=1460
10.1.10.201  10.1.10.11   [TCP Previous segment lost] ssh > 39946 [SYN, ACK] Seq=46941561
10.1.10.11   10.1.10.201  39946 > ssh [RST] Seq=1 Win=0 Len=0

(the last three lines repeat)

Похоже, пакеты туда попадают, но подключающийся компьютер отправляет RST. Зачем?

Со стороны клиента (машина с SSH) более поздняя попытка выглядела так:

Source       Destination  Info
10.1.10.11   a.b.c.d      40212 > ssh [SYN] Seq=0 Win=14600 Len=0 MSS=1460
10.1.10.201  10.1.10.11   ssh > 40212 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1460
10.1.10.11   10.1.10.201  40212 > ssh [RST] Seq=1 Win=0 Len=0

10.1.10.11   a.b.c.d      [TCP Retransmission] 40212 > ssh [SYN] Seq=0 Win=14600 Len=0 MSS=1460
10.1.10.201  10.1.10.11   [TCP Previous segment not captured] ssh > 40212 [SYN, ACK] Seq=15635206
10.1.10.11   10.1.10.201  40212 > ssh [RST] Seq=1 Win=0 Len = 0

(the last three lines repeat)

Единственное, что выделяется, это то, что я постоянно получаю "Предыдущий сегмент не захвачен" (не так ли? Кажется, прямо здесь), и что порядковые номера от клиента действительно детерминированы. (Разве они не должны начинаться со случайной точки и увеличиваться оттуда?)

|источник

3 ответа3

2

Как я сказал в своем комментарии. Чтобы иметь возможность использовать общедоступный IP-адрес в локальной сети, вам потребуется нечто, называемое NAT Loopback также известное как NAT hairpinning NAT reflection или отражение NAT .

Вы можете прочитать об этом здесь

Насколько я могу найти в Интернете ваш кусок ... уууу ... "SMC Networks SMCD3G" не поддерживает "NAT Loopback".

У вас есть два варианта:

  1. Вы можете добавить строку 10.1.10.201 fake_or_real_hostname в ваш файл hosts.
    Вы можете подключиться как ssh me@fake_or_real_hostname .

  2. Вы можете запустить свой собственный локальный DNS-сервер. Вот некоторые объяснения.

Я решил ту же проблему, что и у вас, запустив свой собственный локальный DNS-сервер, который использует OpenDNS для нелокальных доменов, и создав зоны с локальными записями DNS A и PTR, которые разрешают мое внешнее имя хоста в IP-адресе локальной сети этого хоста.

В обоих случаях лучше использовать имя хоста вместо ip. Вы можете использовать службу динамических имен хостов, чтобы получить имя хоста (например, myname.dyndns.org), если ваш публичный ip сильно меняется. Это также легче запомнить. И если вы выберете вариант 1, вы можете добавить это имя в файл hosts.

Вот некоторые из них:
DynDNS
своего Free DNS
ZoneEdit
Нет-Ip

Мой модем имеет возможность автоматически регистрировать изменения ip в этих сервисах. Существуют также настольные утилиты, которые могут обновлять его, когда вы публикуете изменения в ip.

|источник
0

То, что вы хотите, иногда называют шпилькой роутера

Поддерживает ли ваш маршрутизатор это, как он называется и как настроен, зависит от марки и модели маршрутизатора (какой информации в данный момент нет в вашем вопросе)

Другим решением той же проблемы является использование DNS с разделенным горизонтом и обращение к серверу по имени. Однако это нелегко настроить, если вы в настоящее время полагаетесь на типичный маршрутизатор SOHO для выполнения всех ваших DHCP+DNS.

|источник
0

Чтобы добавить к ответу Рика: моя личность виновата здесь: он только частично делает правильные вещи, и, в конце концов, портит NAT.

10.1.10.11   a.b.c.d      40212 > ssh [SYN] Seq=0 Win=14600 Len=0 MSS=1460
10.1.10.201  10.1.10.11   ssh > 40212 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1460
10.1.10.11   10.1.10.201  40212 > ssh [RST] Seq=1 Win=0 Len=0

Обратите внимание на связи здесь. Во-первых, мы видим SYN (ожидаемый) с 10.1.10.11 (клиент ssh, это нормально) до abcd (также нормально). Сервер, однако, получает это как 10.1.10.11 → 10.1.10.201 . IP-адрес назначения был заменен маршрутизатором, NAT fashion, правильный. IP-адрес источника, однако, не был заменен. Здесь у нас должно быть соединение (10.1.10.201 & a.b.c.d), но вместо этого у нас есть (10.1.10.201 & 10.1.10.11). Маршрутизатор выполнил только половину требуемой работы.

Соединение с сервером: (10.1.10.201 и 10.1.10.11). Для клиента это (10.1.10.201 & a.b.c.d) ¹. Когда клиент получает SYN/ACK для (10.1.10.201 и 10.1.10.11), ОС (по праву) отправляет RST - она не знает об этом соединении.

Ote Обратите внимание, что номера портов имеют значение при определении соединений, но для простоты я их не учел.

|источник

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