Стек протоколов TCP/IP является обязательным требованием при трудоустройстве на роль инженера или пресейл-инженера в нашу компанию не просто так. Знание, чем TCP отличается от IP, а также как IP превращается в MAC адрес и вообще что это такое - это база, которой должен обладать сотрудник, чтобы разбираться с проблемами.
Покажем отличие на простом примере - отладке стенда ESX у нас в офисе, когда потребовалось выполнить быструю настройку на его веб консоли для переноса виртуальной машины в новый VLAN (что это такое сейчас не разбираем - это тоже одно из "обязательных" знаний для инженера).
Работа должна была занять несколько минут и ничто не предвещало беды до тех пор, пока при попытки подключиться на консоль мы не увидели ошибку:
Работа должна была занять несколько минут и ничто не предвещало беды до тех пор, пока при попытки подключиться на консоль мы не увидели ошибку:
Веб-сервер ESX должен был "висеть" на 192.168.2.2, при этом он успешно пинговался (ping), однако при попытке подключения браузером с компьютера выдавал указанную выше ошибку... бррр!
Очевидно, что что-то блокирует соединение. Начался траблшутинг (здесь работал начальник отдела, поэтому все это заняло считанные минуты и дольше писать, чем фактически выполнять эти операции, но у новичка это заняло бы часы или дни, поэтому приводим полностью алгоритм ниже, включая логику рассуждений - это может быть важно).
- Проблема могла быть связана с локально установленным на компьютере антивирусом Касперского, который контролирует сетевые подключение и мог бы ругаться на самоподписанный сертификат ESX, мы его отключили и вообще выгрузили из памяти (благо административные права у нас были - это вообще хорошо, когда специалист имеет администратора на системе, чтобы не затягивать траблшутинг - ну по крайней мере, когда он знает, что делает). Это не помогло.
- Мы также отключили локальный МСЭ, так как он тоже мог влиять на соединения и надо было быстро разобраться - копать в эту сторону (и разбирать политики МСЭ) или проблема в другом. Поскольку это предсказуемо не помогло, то мы пошли дальше.
- было предположение, что проблема могла быть в изоляции хостов на беспроводной точке доступа, которая используется в офисе, но проверка показала, что режим "AP / host isolation" отключен
4) Напомню, что Ping до сервера проходил, и мы также верифицировали адрес самой ESX консоли, так как у нас был локальный доступ до ее интерфейса : 192.168.2.2. Но само подключение не работало по какой-то причине.
5) Следующий логичный шаг проверить, куда же мы на самом деле подключаемся - благо компьютер уже был в одной сети с ESX консолью, мы "видели" его IP адрес, но почему-то не могли подключиться к запущенному и ожидающему подключения веб серверу. Решили проверить MAC адрес, который компьютер получает в ответ на свой ARP запрос при формировании Ethernet кадра на канальном уровне. Для этого мы проверили локальную ARP таблицу
5) Следующий логичный шаг проверить, куда же мы на самом деле подключаемся - благо компьютер уже был в одной сети с ESX консолью, мы "видели" его IP адрес, но почему-то не могли подключиться к запущенному и ожидающему подключения веб серверу. Решили проверить MAC адрес, который компьютер получает в ответ на свой ARP запрос при формировании Ethernet кадра на канальном уровне. Для этого мы проверили локальную ARP таблицу
Адрес сервера мы помнили - это 192.168.2.2, но вот интуиция подсказала, что надо проверить и MAC адрес, чтобы понять, куда двигаться дальше.
Интуиция не подвела и внимательный взор сразу показал, что консоль ESX должна отвечать MAC адресом 00:1e:67:29:39:64, тогда как на самом деле компьютер получает МАС адрес 00:1e:67:29:39:66.
Кажется, что разница небольшая, но важная - это совершенно другой адрес с точки зрения сети и, соответственно, другой сервер (виртуальная машина).
Предположение, что это виртуальная машина ESX, вытекает из последовательной нумерации МАС адресов, которую можно увидеть на самом сервере ESX.
Предположение, что это виртуальная машина ESX, вытекает из последовательной нумерации МАС адресов, которую можно увидеть на самом сервере ESX.
Напрашивался очевидный вывод: неверно задана IP адресация для демо-стенда и происходит перехлест IP адресов, из-за чего нам отвечает не консоль ESX, какой-то другой виртуальный сервер (раз MAC адрес из пула ESX), но на котором не запущен веб.сервер!
Поскольку в этот момент нам было важно выполнить настройки на консоли ESX, у нас были доступные адреса в сети 192.168.2.0/24, мы не стали выявлять "виновника" в перехлесте адресов (виртуальную машину с дубликатом адреса) и отложили этот вопрос на потом.
Проблема решилась заменой IP адреса консоли ESX через ее локальный интерфейс на свободный адрес (для нас это был 192.168.2.20 - см.скриншот выше) - после чего мы тут же получили нужный отклик на ARP запрос и, предсказуемо, подключились к серверу.
Это очень важный нюанс. Как уже отмечали, у специалиста траблшутинг и определение проблемы занимает несколько минут (дольше было писать эту заметку), а вот для неподготовленного специалиста могло уйти дни или недели на то, чтобы отловить ошибку, о возможном существовании которой он и не знает! Есть даже такая шутка: "Особенно тяжело, когда не знал, а потом забыл!" - это как раз было бы про этот случай.
Удачи в сетевых настройках, чтобы у вас никогда не было перехлеста (overlapping) IP адресов.
Обращайтесь к нам, если нужна помощь с обслуживанием или настройкой.
Обращайтесь к нам, если нужна помощь с обслуживанием или настройкой.