2

У меня небольшая домашняя сеть, и у меня проблемы с доступом к одному из компьютеров в этой сети. Домашняя сеть настроена на NAT, и я настроил переадресацию портов и динамический DNS.

  • rye сидит в моей домашней сети. Общедоступный порт 2222 моего маршрутизатора перенаправлен на порт 22 rye .
  • sorghum сидит в моей домашней сети. Общественный порт 22 направляется в порт 22 sorghum .
  • teff сидит на внешней сети.

Теперь я представлю следующий странный сценарий:

  1. Я могу SSH от teff к dmwit.duckdns.org:2222 поэтому я считаю , что динамический DNS работает правильно, порт-экспедиторская rye работает правильно, и rye принимает соединения от других компьютеров правильно (т.е. не блокирует вещи на уровне брандмауэра).
  2. Я могу использовать SSH от rye до dmwit.duckdns.org:22 , поэтому я считаю, что переадресация портов в sorghum работает правильно, и sorghum правильно принимает соединения с других компьютеров.
  3. Из rye прося Netcat для подключения к порту sorghum , что заблокированный по результатам sorghum «s брандмауэров в„Нет пути к хосту,“ в то время как от teff просит Netcat для подключения к dmwit.duckdns.org:22 результатов в«Время ожидания подключения истекло out », поэтому я считаю, что брандмауэр sorghum не блокирует это соединение.
  4. Я не могу SSH от teff до sorghum (время ожидания соединения).

Я нахожу это немного странным; факты свидетельствуют о том, что каждая часть в цепочке работает правильно, но вся цепочка сломана. У меня есть два конкретных вопроса, которые несколько не связаны друг с другом:

  1. Как можно отлаживать подобные вещи дальше? Какие инструменты я могу использовать, чтобы узнать больше о том, что идет не так?
  2. Как мне это исправить, чтобы я мог ssh от teff до сорго?

РЕДАКТИРОВАТЬ: я нашел смутно связанный вопрос, который предложил попробовать Traceroute. На teff я вижу существенную разницу между выходами Traceroute для портов 22 и 2222:

% traceroute -p 2222 -T dmwit.duckdns.org
traceroute to dmwit.duckdns.org (75.164.159.92), 30 hops max, 60 byte packets
 1  gw-40.galois.com (192.168.40.1)  13.722 ms  13.723 ms  17.016 ms
 2  66.162.129.25 (66.162.129.25)  17.957 ms  18.106 ms  18.289 ms
 3  64-129-238-66.static.twtelecom.net (64.129.238.66)  18.949 ms sea2-pr2-xe-0-3-0-0.us.twtelecom.net (66.192.243.34)  19.250 ms 64-129-238-66.static.twtelecom.net (64.129.238.66)  19.242 ms
 4  64.132.69.2 (64.132.69.2)  20.052 ms  20.291 ms  20.284 ms
 5  ptld-agw1.inet.qwest.net (67.14.49.2)  22.658 ms  22.942 ms  22.932 ms
 6  207.225.86.146 (207.225.86.146)  22.924 ms  8.583 ms  8.591 ms
 7  * * *
 8  75-164-159-92.ptld.qwest.net (75.164.159.92)  31.056 ms  29.508 ms  29.714 ms
% traceroute -p 22 -T dmwit.duckdns.org -m 60
traceroute to dmwit.duckdns.org (75.164.159.92), 60 hops max, 60 byte packets
 1  gw-40.galois.com (192.168.40.1)  1.660 ms  5.667 ms  5.912 ms
 2  66.162.129.25 (66.162.129.25)  5.901 ms  12.563 ms  12.555 ms
 3  64-129-238-66.static.twtelecom.net (64.129.238.66)  14.227 ms sea2-pr2-xe-0-3-0-0.us.twtelecom.net (66.192.243.34)  12.796 ms  12.787 ms
 4  64.132.69.2 (64.132.69.2)  12.778 ms  12.769 ms  12.762 ms
 5  ptld-agw1.inet.qwest.net (67.14.49.2)  13.955 ms  13.946 ms  13.937 ms
 6  207.225.86.146 (207.225.86.146)  13.931 ms  10.297 ms  10.256 ms
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
<snip>

Второй продолжается еще на 20 строк (и продолжается, если вы увеличиваете максимальное количество прыжков). Я не уверен на 100%, как это интерпретировать, поэтому добавлю третий вопрос:

  1. Что означает этот вывод traceroute?
|источник

3 ответа3

1

Попробуйте настроить sshd для прослушивания на другом порту, отличном от порта 22 на сорго (> 1024). Это может быть что-то конкретное для провайдера на стороне исходящих или на стороне ржи / сорго. Некоторые провайдеры блокируют определенные зарезервированные порты, хорошим примером может служить порт 25 smtp, потому что ни одному провайдеру не нравится иметь дело со спамерами, сканирующими свои сети на наличие открытых ретрансляторов. В любом случае, я убежден, что это может быть причиной того, что порт отображается как отфильтрованный в базовом тесте синхронизации, что, вероятно, означает, что он может быть отфильтрован на уровне провайдера на стороне ржи / сорго (вход)

«Фильтрованный» означает, что эти порты были идентифицированы как остановленные чем-то по сетевому пути. Это может быть брандмауэр на цели, но он также может фильтровать правила на любом из промежуточных хостов между аудитом и целевыми машинами ».

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

|источник
1
  1. вы бы использовали такие инструменты, как tcpdump(8) и / или wireshark(1), чтобы увидеть, какие пакеты поступают на проблемные хосты и отправляются с них. Поэтому, если вы видите, что приходит пакет TCP SYN, но ответ не отправляется, это связано с локальным брандмауэром (или маршрутизацией). Но если вы вообще не видите прибытия пакета TCP SYN, это означает, что какой-то брандмауэр отбросил его до того, как он достиг вашего хоста. Например, конфигурация брандмауэра вашего маршрутизатора по умолчанию или ваш интернет-провайдер, который считает, что запущенные сервисы на ваших хостах нарушают его ToS и / или представляют угрозу безопасности.
  2. Я бы предложил изменить общедоступный порт 22 например, на 2223 . Если это работает, это означает, что либо брандмауэр ISP, либо ваш домашний маршрутизатор блокирует порт 22.
  3. это означает, что маршрутизатор в прыжке 6,7 или 8 (это неоднозначно из-за тихого маршрутизатора в 7) отбрасывает пакеты с портом назначения 22 (а не с портом 2222). Опять же, это может быть ваш брандмауэр ISP или брандмауэр домашнего маршрутизатора или локальная конфигурация (например, маршрутизатор может зарезервировать для себя порт 22 для удаленного управления и прекратить подключение к нему с внешних портов). Я бы заподозрил локальный роутер. Опять же, проще всего проверить это изменить порт общего пользования на 2223 для sorghum
|источник
1

Вы проверили, что в конце тефа нет исходящего блока SSH? Вы продемонстрировали, что можете подключиться к домашней системе через порт 2222 через teff, но на порту 22 может быть исходящий блок. Если вы не убедились, что исходящие соединения порта 22 из teff возможны, попробуйте ssh github.com из teff. Вы должны увидеть подсказку относительно ключа для github.com. Проверено ли у вас соответствующее правило брандмауэра в точке разграничения между внешней сетью и внутренней домашней сетью, которое разрешает входящее соединение с IP-адреса teff на порт 22? Я вижу, что dmwit.duckdns.org не открыт для подключения из Интернета через порт 22, и кажется, что вы только что убедились, что сорго доступно по внутреннему адресу домашней сети, что не обязательно означает, что существует соответствующее правило брандмауэра это позволит подключаться к порту 22 из других мест. Посмотрите журнал брандмауэра на сорго; Вы видите что-нибудь в журнале, указывающее на попытку подключения к порту 22 от teff? Вы можете попытаться установить соединение с системой, отличной от teff, с помощью теста подключения к серверу SSH и впоследствии проверить журнал брандмауэра сорго, чтобы узнать, было ли зарегистрировано какое-либо действие, если сорго должно быть по крайней мере доступно на порту 22 из Интернета, даже если брандмауэр блокирует соединение

|источник

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