На главную

Проблемы с соединением по TCP/IP

В общем случае все выглядит так: вы не можете подключиться к какому-нибудь сетевому сервису. Здесь будет рассматриваться случай, когда и клиент и сервер - ваши. Если какая-то сторона принадлежит не вам (напр. провайдеру), то просто исключите соответствующие пункты из последовательности действий или попросите людей на другой стороне выполнить это. В нашем примере, мы будем считать, что адрес сервера 192.168.0.1 и порт 110 (pop3).

Вообщем-то, последовательность действий может быть и не такой, но в любом случае, каждая из этих манипуляций позволяет отследить сбои на своем уровне, т.о. их использование позволяет локализовать проблему (если проблема со стандартным windows-сервисом, то лучше сразу смотреть системные журналы). Также просто необходимо знать принципы модели OSI и основы TCP/IP. Если вы "не в курсе", то лучше сначала сходить на www.citforum.ru, и уже после этого читать дальше. Если по ходу действия у Вас возникнут вопросы типа "а что это за команда?", то запустите команду с параметром /? (в интерактивных программах, вроде ftp или nslookup можно набрать в программе "help") (под Win) или наберите "man <command>" (под Linux). Также, никто не отменял поисковики.

1. Для начала следует проверить, существует ли связь на уровне IP с нужным хостом. Для этого надо выполнить:

    > ping 192.168.0.1
Если ответ не приходит, то надо попробовать:
    > ping 127.0.0.1
Если последнее действие не получается, то проблема в некорректном функционировании стека TCP/IP на той машине, где вы выполняете эту команду. Если последняя команда работает, то дело скорее всего в канальном или физическом уровне: сбой сетевой карты, драйверов или повреждение кабеля (на стороне клиента или сервера). Если это Ethernet, то в первую очередь проверьте, горит ли вообще светодиод "Link" на сетевом адаптере. Если сервер находится в другой подсети, то надо проверить с помощью tracert (под Win) или traceroute (под Linux), где теряются пакеты - проблемы могут быть в некорректной маршрутизации.

Итак, мы убедились, что ping проходит по нужному адресу. Теперь стоит попробовать сделать это по имени сервера. Если ответ не возвращается или ping сообщает о невозможности разрешить имя узла, то проблема в разрешении имен — nslookup вам в руки.

2. Если ping проходит по имени и адресу, то полезли на транспортный уровень. Пробуем подключиться с помощью telnet:
telnet host port, в нашем случае:

    > telnet 192.168.0.1 110
Если подключение прошло нормально, то мы увидим приглашение pop3-сервера. Для mail.ru это выглядит примерно так:
    +OK mPOP POP3 v1.102+rb2 server ready <1342455986.1057605587@mail.ru>
Если telnet говорит, что невозможно подключиться, то следует проверить, запущен ли вообще нужный сервис и слушает ли он порт на нужном интерфейсе. Запущен или нет процесс, можно узнать из Task Manager или с помощью ProcessExplorer под win, или с помощью pstree под Linux. Убедиться, слушается ли нужный сокет можно с помощью TCPView (win) или lsof -i -n -P или netstat -l -p A inet --numeric (Linux). Если процесс запущен, но порт не слушается, то надо сразу посмотреть, не слушает ли другой процесс этот порт. Затем, если процесс не запущен, надо попробовать его запустить. Если это не получается или порт все равно не прослушивается, надо разбираться с приложением. Обычно помогает журнал ошибок (в win в случае системных сервисов все обычно пишется в системный журнал). Если порт слушается, то причиной может быть то, что некоторые сервисы ограничивают диапазон адресов, с которых к ним можно подключиться. Также очень полезен режим отладки.
Иногда причиной невозможности подключиться может быть firewall на пути между сервером и клиентом. В этом случае можно попытаться подключиться к сервису с той же машины, где он запущен - обычно firewall'ы и сами сервисы не блокируют доступ с localhost.

Все вышеизложенное справедливо для приложений, использующих TCP. Если используется UDP (DNS), то работать нужно только с помощью специального клиента (nslookup, dig). Также, некоторые программы вроде X-Spider позволяют посылать вручную сформированные данные через UDP.

3. Если подключиться удалось, то пробуем выполнить типичный сеанс для данного протокола. Это получится, если его данные передаются в текстовом виде. Обычно большинство распространенных протоколов (http, pop3, smtp) работают через передачу plain text. В случае если это не так, то кроме использования специфичного клиента, подробно отображающего пересылаемую информацию для данного протокола других вариантов нет (например, nslookup для DNS). Использование telnet позволит напрямую работать с сервисом на сервере. В нашем случае это будет что-то вроде:

    > telnet pop.mail.ru 110
    +OK mPOP POP3 v1.102+rb2 server ready <1342455986.1057605587@mail.ru>
    user vasya_pupkin
    +OK Password required for user vasya_pupkin
    pass password
    +OK vasya_pupkin@mail.ru maildrop has 14 messages (50271 octets)
    stat
    +OK 14 50271
    quit
    +OK POP3 server at mail.ru signing off
Для HTTP это выглядит так:
    > telnet 192.168.0.1 80
    GET http://192.168.0.1/ HTTP/1.1
    <Пустая строка>
    <Enter>
    Сервер выдаст начальную страницу.

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

Вообще, следует заметить, что очень полезно знать основные команды наиболее часто используемых протоколов (ftp, http, smtp, pop3). В случае с ftp вы сможете подключить к серверу и пройти аутентификацию, но просмотреть список папок и файлов и получить файл вам не удастся, по крайней мере, без сильных извращений.

Также, еще раз повторюсь, что включенный на сервере режим отладки является незаменимым инструментом. Например, в продуктах Kerio возможно включение отладки по разным категориям событий (разрешение имен, установка соединений, работа с ящикми и пр.) В Unix-like демонах обычно настраивается пути вывода логов работы и степень их детализации. Чтение документации по Syslog тоже очень полезно.

Рейтинг@Mail.ru