Тайм-аут соединения для сервера ssh

Я пытаюсь настроить openssh-сервер, но у меня возникают некоторые проблемы с подключением. Я изменил порт на нестандартный (57757), а затем настроил мой маршрутизатор для переадресации на этот порт. В моей локальной сети я могу нормально подключиться к моей машине через порт 57757, но не могу сделать это в глобальной сети.

Если я нахожусь за пределами локальной сети и пытаюсь получить доступ к своей машине по неверному порту, я немедленно получаю сообщение «Отказано в соединении». Однако с правильным портом он просто зависает и затем таймауты.

Что можно попробовать отладить? Я попробовал traceroute, но он не сказал мне ничего полезного.

РЕДАКТИРОВАТЬ: я понял, что моя проблема была в том, что мой маршрутизатор не поддерживает доступ к нему через WAN IP внутри. Я ssh'd на другой сервер и обратно, и он работал нормально.

11
задан 13 January 2013 в 09:07

2 ответа

Обычно это означает передачу порта неправильному IP-адресу на LAN.

Ваш маршрутизатор NAT получает входящий трафик на порте 57757 и отправляет его в конкретный IP-адрес и порт на LAN.

По умолчанию Ubuntu не фильтрует попытки входящего соединения с брандмауэром. Таким образом, если Вы не изменили настройки брандмауэра в Ubuntu, попытка открыть соединение с любым портом TCP, 1 - 65 535, будет также:

  • примите соединение, если порт открыт
  • отклоните попытку подключения, если порт закрывается

Если бы порты были фильтрованы брандмауэром, то Вы получили бы то, что Вы видите - никакой ответ на попытку подключения. Но:

  • если Вы не изменили настройки брандмауэра (например, ufw, iptables), никакие порты не фильтрованы, и
  • в любом случае можно соединиться с портом 22 на LAN, таким образом, это открыто.

При передаче порта несуществующей машине с маршрутизатором NAT это отправляет входящий трафик на том порте к несуществующей машине, которая должна сказать, что это отправляет его в черную дыру; это эффективно отбрасывается.

Это вызывает точно ситуацию, которую Вы описали. Таким образом, можно, скорее всего, зафиксировать это путем проверки, что порт передается корректному IP-адресу на LAN.

Если это, оказывается, не было проблемой...

... затем необходимо будет сделать некоторый поиск и устранение неисправностей.

  1. Порт указан для корректной стороны локальной сети? Таким образом, принятие Вас не изменило конфигурацию сервера SSH, порт 57757 на наборе стороны WAN для передачи для портирования 22 на сервере OpenSSH? (Можно хотеть перепроверить это.)

  2. Возможно, существует некоторая проблема с определенным портом, который Вы выбрали (57757). Попробуйте другой и посмотрите, работает ли это лучше.

    (Если это не делает, и Вы возобновляете эти инструкции, или возвращаете его или заменяете "57757" ниже новым числом.)

  3. Попытайтесь перезапустить сервер OpenSSH. Это может помочь, если существует сетевая проблема. Если это не помогает, попытайтесь перезапустить маршрутизатор и cable/DSL/ISDN модем также.

    Если по некоторым причинам Вы не можете перезапустить все три устройства, я рекомендую перезапустить независимо от того, что Вы можете. Если Вы не можете перезапустить услуги OpenSSH, по крайней мере, можно перезапустить сервис, и (более вероятно для фиксации этого) удаляют интерфейс и поднимают его снова.

    Перезапускать сервер OpenSSH:

    sudo restart ssh
    

    Для перевода в нерабочее состояние сетевого интерфейса сначала выясните то, что взаимодействует через интерфейс, он идет:

    ifconfig
    

    Как правило, для машины с единственной платой Ethernet и/или единственной беспроводной картой, Ethernet eth0 и беспроводная связь wlan0.

    Если проводное соединение Ethernet - то, что Вы хотите удалить и перезапустить, выполнить:

    sudo ifdown eth0
    

    Затем выполненный:

    sudo ifup eth0
    

    С другой стороны, можно работать:

    sudo ifconfig eth0 down
    

    Сопровождаемый:

    sudo ifconfig eth0 up
    

    Если машина использует NetworkManager для управления интерфейсом, в котором работает сервер OpenSSH, я все еще рекомендую пробовать вышеупомянутые пути, но можно также попытаться разъединиться и снова соединиться в NetworkManager.

    Для соединения Ethernet также попытайтесь отключить кабель, и включиться он въезжает задним ходом. Для беспроводного соединения попытайтесь выключить его с аппаратным переключателем (если существует один), и назад на снова.

    Что-то странное продолжается здесь, и ни одно из этого не берет очень долго - стоит быть полным прежде, чем предпринять больше кропотливых шагов поиска и устранения неисправностей.

  4. Как Вы пытаетесь получить доступ к нему от стороны WAN? При использовании машины на LAN, чтобы сделать это (просто соединяющийся от LAN до IP WAN маршрутизатора), это только поддерживается для некоторых маршрутизаторов. В конце концов, задание маршрутизатора состоит в том, чтобы направить трафик между сторонами WAN и сторонами локальной сети, для не маршрутизации трафика от одной стороны до себя. Поддержка соединения с переданными портами на IP WAN из LAN является на самом деле исключением, а не правилом, хотя много маршрутизаторов дома/офиса действительно имеют эту функцию.

    Таким образом, если Вы не тестируете порт вперед от хоста на стороне WAN, необходимо сделать так. Ваши опции для этого:

    • Соедините себя от стороны WAN. Это работает, если у Вас есть доступ к машине там, например, доступ SSH к удаленной машине в школе, работе, доме друга, или подобный.

    • Подключите тестовую машину между маршрутизатором и независимо от того, что обеспечивает его Интернет-соединение. Если у Вас есть cable/DSL/ISDN модем с портом Ethernet, и Ваш маршрутизатор включен, что, можно подключить переключатель к модему и подключить маршрутизатор к переключателю. Подключите компьютер к переключателю. Увидьте в первый раз, если та машина просто получает доступ в Интернет - в эти дни, многие, ISP обеспечивает два или больше отдельных IP-адреса. Если это не делает, перейдите к странице установки своего маршрутизатора и проверьте ее IP WAN и маску подсети WAN, то статически присваивают IP-адрес соединенной с переключателем машине, которая является в той же подсети.

      Этот метод имеет некоторые недостатки. Это - боль! Кроме того, для ISP теоретически возможно настроить их сеть неправильно так, чтобы тестовая машина, подключенная к переключателю, могла получить доступ к Интернету. (Если это не намерение Вашего ISP позволить Вам соединиться больше чем с одним IP WAN, и Вы, оказывается, выбрали IP WAN для тестовой машины, которую Ваш ISP присвоил Вам, трафик между ним и истинным хостом WAN должен блокироваться/отбрасываться ISP. Но некоторый ISP имеет странные методы, поэтому кто знает?), Если это происходит, это, вероятно, не вызовет никого серьезные проблемы (и даже если это сделало, у Вас только есть соединенный в течение нескольких минут). Однако это могло потенциально рассматриваться как попытка получить дополнительный доступ вне границ Вашей подписки, и - что еще более важно - если у другого пользователя есть тот же самый IP, это могло бы вмешаться в их соединение. Поэтому, если Вы хотите попробовать этот метод, не попытайтесь получить доступ к Интернету от тестовой машины, остановитесь сразу, если Вы находите, что тестовая машина может получить доступ к Интернету и не делает попытку этого вообще, если это запрещается или рекомендуется против Вашим ISP. (И не используйте это, если сторона WAN Вашего маршрутизатора является офисом LAN, не консультируясь с Вашим администратором сети сначала. Это не ISP и нет никакого предположения, что ресурсы настраиваются к предотвращенному нежелательному доступу.)

      Существует вариация на эту технику, которая является иногда более соответствующей. Ваш маршрутизатор, вероятно, получает свою информацию о соединении - IP-адрес, маска подсети, IP-адрес шлюза (маршрутизатор) в WAN, которую это использует, когда это не знает, куда отправить что-то и информацию о серверах DNS - от Вашего ISP, через DHCP, через cable/DSL/ISDN модем. Поэтому необходимо было включить маршрутизатор модем, чтобы дать ему необходимую конфигурацию для создания результатов стороны WAN, тестирующей значимый. Но маршрутизатор будет обычно помнить эту информацию, пока это на самом деле подключено к сети на стороне WAN. Таким образом, можно подключить маршрутизатор, модем, и протестировать машину, но затем, быстро, и прежде, чем сделать что-либо с тестовой машиной помимо проверки, что переключатель видит его, как соединено, разъедините модем.

    • Используйте бесплатный сервис в Интернете для тестирования портов. Начиная со вставки тестовой машины между интерфейсом глобальной сети Вашего маршрутизатора и Интернетом (выше) высоко включен - и так как это покажет порт как доступный, даже если это будет недоступно из-за того, чтобы быть заблокированным Вашим ISP (который также верен для соединения с IP WAN маршрутизатора от стороны локальной сети) - обычно лучше использовать веб-сервис сканирования портов.

      Существует много услуг по сканированию портов. (Немного щеголяют фразой, "проверяют Ваш брандмауэр" с идеей, что большинство людей пытается заблокировать, а не облегчить доступ.) Это - то. Если Вы принимаете решение использовать тот, нажмите Proceed, тип 57757 в текстовое поле, и нажмите Use Specified Custom Port Probe. В целях заставить сервер работать, Вы хотите, чтобы это было "открыто". "Закрытый" означает, что порт доступен, но сервер не работает (и таким образом попытка подключения была отклонена). "Хитрость" означает, что порт был недоступен - это - как будто никакая машина не была расположена там (или как будто порт был передан, где нет никакой машины).

  5. Хорошо, таким образом, Вы решили, что это действительно не доступно из Интернета. Потенциально можно просканировать его (идеально от стороны WAN) для получения деталей, хотя часто это не будет давать полезную информацию.

    Если Вы хотите сделать это, то на стороне WAN, можно работать:

    sudo nmap -sS -sV -p57757 -vv WAN-IP

    Если порт показывают, как фильтровано, который подтверждает, что пакеты, отправленные там, вероятно, никуда не идут (или блокируются/отбрасываются по пути).

  6. Это стоит проверить, чтобы видеть, является ли проблема результатом порта, подвергнутого WAN, являющейся отличающимся от порта, сервер на самом деле слушает на. Порт пересылки 55757 в WAN для портирования 22 на машине LAN должен разобрать вещи прекрасная работа, но возможно где-нибудь (сервер, клиент) что-то предполагает, что номер порта является тем же с сервера и перспективы клиента.

    По-видимому, Вы не можете порт передачи 22 через маршрутизатор. Возможно, Ваши блоки ISP тот порт. Но если можно сделать это, сделайте это!

    Иначе можно заставить сервер OpenSSH на самом деле послушать на порте 57757.

    Чтобы сделать это, создайте резервную копию конфигурационного файла сервера:

    cd /etc/ssh
    sudo cp sshd_config sshd_config.old
    

    Затем отредактируйте его:

    gksu gedit sshd_config
    

    Или используйте консольный текстовый редактор, если машина не имеет GUI:

    sudo nano -w sshd_config
    

    Около вершины файла появляется этот блок текста:

    # What ports, IPs and protocols we listen for
    Port 22
    # Use these options to restrict which interfaces/protocols sshd will bind to
    #ListenAddress ::
    #ListenAddress 0.0.0.0
    Protocol 2
    # HostKeys for protocol version 2
    HostKey /etc/ssh/ssh_host_rsa_key
    HostKey /etc/ssh/ssh_host_dsa_key
    HostKey /etc/ssh/ssh_host_ecdsa_key
    #Privilege Separation is turned on for security
    UsePrivilegeSeparation yes
    

    Просто изменитесь Port 22 строка наверху, для высказывания Port 57757 вместо этого.

    • Вы могли добавить порт вместо того, чтобы изменить его. Я рекомендую тестировать с самой простой эффективной конфигурацией, все же.

      Посмотрите man sshd_config для получения дополнительной информации о конфигурировании сервера OpenSSH.

    Сохраните файл, выйдите из текстового редактора и перезапустите сервер SSH с:

    sudo restart ssh
    

    Теперь измените порт вперед на маршрутизаторе так порт 57757 вперед, чтобы портировать 57757 (не 22) на сервере OpenSSH и видеть, доступно ли это из Интернета.

  7. Если это все еще не работает, посмотрите, блокирует ли, возможно, брандмауэр Ubuntu на самом деле трафик, происходящий снаружи LAN.

    (Это маловероятно, если Вы не настраивали его этот путь сами, но если все Ваши настройки являются правильными, и ни один из вышеупомянутых шагов ничего не показал о проблеме, это стоит проверить.)

    Выполненный:

    sudo iptables -L
    

    По умолчанию, в Ubuntu, вывод похож:

    Chain INPUT (policy ACCEPT)
    target     prot opt source               destination         
    
    Chain FORWARD (policy ACCEPT)
    target     prot opt source               destination         
    
    Chain OUTPUT (policy ACCEPT)
    target     prot opt source               destination
    

    Это - простая разрешающая политика, чрезвычайно эквивалентная не выполнению брандмауэра. (Действительно, если бы netfilter модуль брандмауэра не был скомпилирован в Ваше ядро, то Ваша система вела бы себя тот же путь как с вышеупомянутыми настройками, хотя iptables команда, которая запрашивает netfilterнастройки, не работал бы, конечно.)

    Если Ваша конфигурация не похожа на это, читать man iptables для выяснения, что они делают и/или редактируют вопрос (или, если Вы - другой человек с подобной проблемой, читая это, отправляют новый вопрос) включать их. Обратите внимание на то, что, потенциально, Ваш iptables правила могли раскрыть уязвимую информацию о Вашей конфигурации. В сущности это обычно - не случай - за возможным исключением из правил об определенных хостах, которые заблокированы, или если Ваша конфигурация очень плоха/небезопасна - обычно, полноценность этой информации взломщику, специально для машины на доме/офисе LAN позади маршрутизатора NAT, минимальна.

11
ответ дан 13 January 2013 в 09:07

Поскольку он работает изнутри вашей локальной сети, ваша настройка сервера кажется правильной. Вы должны указать маршрутизатору переадресацию с порта , который вы хотите использовать на за пределами , на порт 57757 на вашей машине .
traceroute в этом случае будет бесполезен.

0
ответ дан 13 January 2013 в 09:07

Другие вопросы по тегам:

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